Because we are getting ready to do our annual Comps (capstone) Topics Reveal to our junior CS majors, and my headspace and time have been focused on planning my projects for next year, meeting with community partners, working out the project details, etc, I’ve spent a lot of time reflecting on working with community and campus partners. This morning I realized that I’ve been doing this in some form or another since our dyad adventure in 2011. 2011! I guess I am not as new at this as I sometimes think.
I’ve spent this year in somewhat of a bubble, immersing myself (somewhat) in academic civic engagement: attending two POSSE workshops, interacting with people virtually and face to face about academic civic engagement and working with “real end users”, and meeting with our civic engagement people on campus and potential partners. These people all “get it” — the challenges, the opportunities, the joys, the headaches — and I’ve enjoyed and treasured these conversations. But this bubble makes it easy to forget that academic civic engagement — working with community or campus partners in a classroom situation — is not something that people understand. I was reminded recently, based on conversations I’ve had with people outside of this bubble, that there are a lot of myths out there about what it means to work with community and campus partners within the confines of a class or a capstone project.
So I’m going to attempt to address a few of those myths in this post. This is not an exhaustive list, of course, and I’d love for people to chime in in the comments with your own myths and realities* about working with community partners.
Myth: Academic civic engagement projects are not intellectually or technically rigorous.
Reality: This is probably the #1 myth that I hear, implicitly or explicitly, regarding such projects. I think this myth comes from a misunderstanding of what my students are building and of the process it takes them to get there. If you haven’t worked with a community or campus partner before on a project, or you’ve only done so in a superficial way, you might have the view that the community partner comes to you with a fully-fledged idea in mind, hands you a sketch (typically of a web page — this is a sub-myth, I guess, that community partners only want web pages) , and then you just implement that. A transactional view, if you will, or a one-time meeting of the minds.
In reality, there is a long and rigorous process involved in meeting repeatedly with the community partner and associated stakeholders, discovering their goals, understanding how they are currently attempting to meet these goals and falling short, understanding in detail the tasks they perform to achieve these goals, observing them in action, etc. This work is not only not trivial, it’s not easy, and rarely do you get it right the first time! It requires good listening skills, good interviewing skills (knowing what questions to ask, how to follow up, etc), understanding how to conduct an effective observation, and then turning these observations and notes and ideas into requirements. (The writing of requirements is something my students find very technically and conceptually challenging, whether we’re doing it on a limited basis in Software Design or as part of a Comps project. I’m still struggling with better ways to have them learn and hone this skill.)
Once you get into the development process, there are often many difficult technical problems to solve. Building effective interfaces requires understanding how we visually process information, our cognitive processes and shortcuts, etc. You need to know some psychology, some cognitive science, and some anatomy, in addition to the interface patterns from CS and the coding libraries and languages and syntax and such. And often the backend required to “make the magic happen” on the front-end is non-trivial and requires what we privilege as classic “technical chops” in our field.
Finally, constructing effective usability tests is challenging, and is not a skill that our students readily possess. (Indeed, why should they? We’ve spent basically their entire undergraduate careers in CS having them completely ignore the end-user as a factor!) Finding the time and energy and resources to conduct these tests repeatedly, with different stakeholders, during the project, is difficult even under the best of circumstances. And identifying appropriate questions, tasks, etc. adds another level of complexity.
Myth: Since you are just doing what the community partner wants, you as a professor do not have control over the outcome or the process.
Reality: There is a teeny kernel of truth in this, in that working with “real live actual people” as I say always involves some amount of unpredictability. But I choose to view this as a feature, not a bug! (Plus it’s a fabulous real world learning experience for my students, since no project is completely predictable or free of ambiguity.)
But again, this points to a misunderstanding of the relationship between the community partner and the students/professor. There’s a reason we call them “community partners”: because we BOTH bring something to the table and we BOTH work TOGETHER to create something. The community partner is the expert of their domain: knowing and articulating their goals, knowing how their current tasks fall short of meeting these goals, understanding how their goals and workflow complement or do not complement each other. Rarely does the community partner know exactly what they want or how to achieve it (that’s why we’re partnering, duh!) — and this is the expertise that my students and I bring to the table.** We take their dreams and attempt to turn them into reality. We work together to figure out how to match the goals with the technology. We listen to each other, revise our ideas as a result of our conversations, and most of all learn from each other. Together, we define the outcome and the process. And together, we make both the outcome and the process much richer than they would be if we worked alone.
Myth: The overhead required for academic civic engagement projects takes away from the time you spend covering the “important” technical topics.
Reality: One of the frequent side threads in the interviews I’ve done so far for my research project is frustration with existing software and systems of various types. It’s hard to use, it’s hard to figure out if it will help you achieve your goals, it doesn’t work and you can’t figure out why, etc. It’s easy to see why. The traditional CS curriculum privileges algorithms and privileges coding proficiency. Students practice coding in nearly every class. Students work with, analyze, tweak, study, and implement algorithms starting in CS 1 (or even CS 0). The traditional curriculum doesn’t privilege the end user. It’s possible to graduate as a CS major with minimal to no exposure to even the basics of user-centered design. Which means we have developers who make products that don’t work, are confusing, don’t meet the goals or needs of real live actual people, etc. So on the one hand, I’d argue that user-centered design IS an important technical topic, and not just “fluffy subjective stuff”.
On the other hand, in my experience I’ve found that taking the time to work with the community partner, engaging them in conversation, understanding their goals, etc., gives my student a DEEPER understanding of the problem they are trying to solve. In turn, they become more thoughtful and critical about the solutions they devise, and their solutions are technically richer and more nuanced than they would otherwise be. The “overhead” informs our discussions and coverage of the technical concepts and skills they need to master.
Hopefully these myths and realities will help you out the next time you find yourself in a conversation with someone who questions the value of academic civic engagement in the computer science curriculum (or whatever your field happens to be). Putting together this post has helped me hone my own “talking points”, and hopefully the next time I find myself faced with a teachable moment like this, I’ll be able to better articulate some of the ideas here. And as I mentioned earlier, I’d love to hear your additions to this list!
*The structure of this post is an homage to a piece I co-authored with colleagues at other liberal arts schools about the myths and realities of working at liberal arts schools.
**Let me point out, too, that I’ve worked with some really technically savvy community/campus partners. Those conversations are fun to have, because we can “talk shop” and in some cases dissect technical solutions that haven’t worked. But just because someone has some technical chops does not mean that they have the time, energy, or inclination to solve their own problems. Also, sometimes you are so close to the technology that you’re working with that you know something is not working, but you lack the proper distance to figure it out. Having an outside perspective can be valuable in these cases.
This is what a computer scientist looks like 