Humanity in Software
Published: 2020-06-23 21:15:13

So I’ve been trying to find better words to describe how I feel about programming lately. I think I’ve found better ways to understand where I’m at mentally and emotionally.

Over the 8+ years of my professional career I’ve worked in at least a dozen different languages, and that code has been or is currently running in production. In my 20+ years of hobby programming I’ve written more than Hello World in probably an additional dozen languages. I’ve used this build tool, and that build tool. I’ve written configurations and I’ve followed conventions. I’ve worked at companies of over 2k developers, down to just 2, and various sizes between. I’ve done games and enterprise apps and startup apps. I’ve done object oriented and functional, and even graphical programming. Dynamic and static typing. It’s taken me all this time to realize the 1 thing I’ve been missing in software development that I got in every other field I've worked in.

Empathy.

When I worked in food service, it was expected that everyone cleaned up after themselves and left the next crew with a clean workspace. You set the tables at the end of the night, you washed and put away all the dishes. You took out all the trash. You maybe even prepped some things for the next shift. When I worked in manufacturing, you cleaned up after yourself. You put your tools away. You swept up and washed down anything that needed it. You left your space organized for the next shift, so they knew exactly where to find what they needed.

In software you get docs, maybe, and if you do odds are they’re outdated. You get comments, maybe. You get code that was slapped together in a rush and shoved out the door. Our tools work most of the time, but when they break they give us error messages usually no easier to understand than a solid colored jigsaw puzzle. There’s little to no empathy from the tooling and there’s little to no empathy from the people. Half of the GitHub issues are demands instead of requests or questions. Instead of discussing a tools accessibility or maintainability we discuss its popularity.

Part of this feeling comes from spending most of my career in other people’s code. That is I’ve only ever worked on 1 completely greenfield app. Additionally, most of the code I have worked on was written by someone that’s no longer at the company so going and asking questions about “what” or “why” usually isn’t an option.

Maybe I’m alone in this feeling. If so then these words are just for me. In the case that I’m not alone, what do we do? Overall I’m not certain, though I do have 2 ideas.

My first idea is to spend more time talking about the how the code we’re writing is going to affect the next developer. If you came into it today, completely new to the general context of why it was written, how likely would you be to succeed. This can be challenging, but isn’t that different of the thought process of “walking a mile in another’s shoes”.  This can sometimes be as simple as writing out a longer variable name. Maybe it’s a little more work, a comment about what’s going on and why. Maybe it’s really complex and requires documentation. If you can keep it in the code itself, that’s usually best as it’s most likely to stay up to date. The further you get from the code, such as documentation, the less likely it is that it will be updated. Stale documentation is about as useful as no documentation.

My second idea is improving tooling. This one took me even longer to come to realize. If I’m new to learning a tool, make the error messages meaningful to a human. Point out where the issue is and maybe even some possible solutions. Only suggest reading documentation as a last resort, because as I pointed out earlier it can get out of date. This doesn’t apply only to language compilers but also to linters and more. If your tool requires a configuration, make sure you error messages explain what’s wrong with my configuration in a way that doesn’t make me want to pull me hair out as a first time user. If your tool prefers “convention over configuration”, make sure it’s still explicit. Your “it’s obvious” or “it’s natural” is another person’s “wtf?” 

A final thought. If your internal, or external, response to a question about code/tooling is anything along the lines of “RTFM” (Read The Fucking Manual), “obviously [..]“, or “naturally [..]” then you’re not walking in that person’s shoes. Similarly if you’re struggling with something, or dislike the approach a tool takes, it’s not empathetic to respond with demands or accusations. It doesn’t matter if it involves Open Source or other “free” work. We’re all in this together, we’re not against each other.

I'm just as much guilty of being a part of this cycle. I'm writing this partly because I want to be better.