On a winter day back in 2003, I stepped off the bus near my apartment in Brooklyn and noticed a woman, a woman in a wheelchair. She was trying and failing to roll across the snowy sidewalk. I offered to help push her, and she explained that she needed to get down to the subway station around the corner.
When we arrived at the elevator there was a sign saying it was inoperable. I asked an NYPD officer who was standing there if she could help me get to the woman in the wheelchair down the stairs. The officer said she couldn’t, saying something about rules involving liability, and suggested we go find the firefighters who had been by a few minutes earlier. (I was new to the city, so I hadn’t yet realized out how horrible the NYPD is.)
There were no firefighters to be found, so I started asking random passersby if they’d help me get the woman down the stairs. In no time a handful of people cheerfully volunteered.
As we carried the visibly nervous woman and wheelchair down the stairs—a pretty cumbersome task—one of the volunteers chatted with the woman, asking her name, where she was going, and that sort of thing. And as he did so, I realized what I’d done, and I felt awful.
At some point during this process I’d stopped treating this woman as a person. I hadn’t stopped to ask her how she felt about being carried down the stairs, or even had a conversation with her.
Instead, I’d treated her situation as a problem to be solved. She needed to get down to the station, and I needed to figure out how.
In focusing on her problem I’d forgotten what made the problem worth solving: that it was a person’s problem, her problem.
–
Our job as software engineers is to solve (or better yet, identify) problems. But in doing so we risk forgetting what makes those problems important, the people behind the problem. This makes our solutions less effective.
We don’t get enough feedback, we don’t learn enough about why something needs solving, we don’t take people’s needs into account. So we come up with a solution that isn’t as good as it could be.
That’s the best case.
The worst case happens when we solve problems that actively hurt people: because we’re paid to do so, or because they’re interesting problems. When we write software that hurts people, we’re creating an anti-solution; every success is really a failure. These anti-solutions might arbitrarily ruin workers’ livelihoods, or help an organization tasked with separating children from their parents.
Don’t make my mistake: always remember that problems are only worth solving because of the people they help.
-Itamar
Every week I write an email explaining one of my mistakes—as a programmer, as an employee, sometimes just as a person—and what you can learn from it. I’ve been writing software for more than 20 years, so there’s plenty of past mistakes, and of course I keep making new ones.
This is my 88th Software Clown email, but if you subscribe you’ll start from the very beginning so you can learn from all my mistakes, not just recent ones.
Want to avoid more of my mistakes? Sign up today!