I Don’t Know How to Explain to You That Being a Developer Means You Have to Care About Users

Last modified December 16, 2022

More and more, I feel like we’re fighting a bizarre wave of apathy in tech. Not apathy towards new technologies, of course – there always seems to be plenty of energy for developers to spend on debating Vue vs. React vs. Angular, web 2 vs. web3, various cryptocurrencies. The flavor of the week as I’m writing this happens to be AI chat and art generators, but the actual technology doesn’t really matter, here. Because I’m talking about a broader apathy towards the human beings who we – at least hypothetically – want to be users of the things we’re building with these technologies. Somehow, they never seem to factor into the equation.

Maybe you’re familiar with “the happy path”, the phrase we use in software and UX to describe the ideal user flow. The happy path is what happens when the user does everything just the way we (the developers) predicted: it’s how our apps would work if they were used by Stepford Wives who live in a world without typos, slow internet connections, last names that include special characters, or human error. We spend a lot of time thinking about, designing, and developing the happy path because the happy path is easy to build, easy to sell, and fast to ship. It’s also heavily biased, because it reflects only our own experiences and assumptions – not the diverse and varied lived experiences of the users that we are (again, hypothetically) doing all of this for. The happy path, of course, isn’t real because our users are humans, not robots (or clones of the developer). What developers neglect, regularly, is the unhappy path.

When we do think about the unhappy path, we prefer to focus on the milder side; the kinds of low-stakes, low-risk “oopsies” that we often catch in QA testing. You know: “A QA tester walks into a bar. They order a beer. They order 2 beers. They order two beers. They order 7348594350 beers. They order -1 beers. They order a deer.” The joke continues, but I’ll spare you. Suffice it to say, we slap a few error messages in there to handle validation errors or mis-clicks, forcefully redirect the user back onto the yellow brick road, and call it a day: unhappy path, handled.

But that’s not really true, is it? Because when we’re doing that, when we’re just paying lip service to the unhappy path, we’re glossing over the very real potential for active abuse and harm caused by our own applications. Social networks launched without blocking or safety features, camera filters developed without testing on darker skinned people, prediction models trained on biased data, AI image generators that spit out portraits with exclusively European features, whole swaths of the web made completely inaccessible if you’re blind, deaf, or cognitively impaired. At the risk of sounding cliché: Your developers were so preoccupied with whether or not they could, they didn't stop to think if they should.”

Most often, I see this complacency and laziness disguised under a nicer name: “MVP”. Calling something the MVP imbues it with some kind of magical sense that we don’t have to do it all right now; we’ll just make the app accessible, inclusive, and safe…later. Because those things, of course, are not part of the minimum requirements of software development. But the users we subject to those inaccessible, noninclusive, dangerous MVPs are real people, with thoughts, feelings, and experiences that I’m whole-body tired of watching developers disregard in their quest to be the first one to ship The Next Big Thing. When you “move fast and break things”, what you’re breaking are other human beings.

I also see a lot of developers who are quick to dismiss this because they don’t think they’re building anything big or important. “Hey, I’m not a FAANG dev. I don’t work in healthcare or anything. What impact will my little app have?” But again, you’re thinking in percentages – you’ve reduced real human lives to statistics. When you say that, what you’re really saying is: “It’s okay since my app will only hurt some people. I’ve looked at the numbers and decided that is an acceptable amount of harm for me to inflict.” It’s the developer’s trolley problem, only there’s an option where nobody gets run over, but it takes a few more weeks. I’m continually shocked how many developers look at that situation and pull the lever for the faster release date.

Users are more than a number – they’re not logins per day, page views per month, or engagement metrics to measure against our OKRs. They’re not even the persona that we’ve created in the hopes of lumping them into some easily digestible demographic: Kelly, the middle-aged secretary and single mother who uses our application to meal plan for her busy family (or whatever’s been slapped on the page, next to the first stock photo result for “40 year old woman”). Users are real people, dammit.

And personally, I’m tired of trying to convince folks in tech to care about user experience design, or safety features, or hiring diverse teams, or testing, or any one of the numerous things you can do to at least attempt to minimize the harm you’re creating. I’m sick to my core of writing accessibility talks that spend the first 10 minutes justifying the investment of time in terms of ROI – you should build accessible apps because the people using your app matter. I don’t know how to explain to you that being a developer means you have to care about other people. If you can’t care about your users, then maybe this isn’t the job for you.

And yeah, we’ll fuck it up sometimes, because developers are human, too. It’s inevitable. But does that really mean we shouldn’t even try?

If we don’t start and finish every single project thinking about how the human on the other end will be impacted by it…why are we even doing this? Who the hell are we building for? It’s fine to build things for ourselves, for fun – that’s why we have code challenges, tutorials, hackathons, or side projects. But when we’re coding real things for real people, those users need to be centered throughout the entire process. When I see developers, teams, or whole companies who lose sight of this, it absolutely blows me away.

Software exists for humans, humans don’t exist for software.

*Title inspired by this article