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.
Top comments (5)
It's interesting how you compare development to other "industries" (food service, manufacturing). I think the big difference is that software is abstract and those industries are "tangible".
If you're leaving a big mess at the end of your shift then that mess is immediately visible, so you "just don't do that", even your managers or shift leaders will say "please take the time to clean things up".
But if you leave a mess at the end of your software project then it's nowhere near as visible and obvious, and if you say to your boss "maybe we should take some time to clean this up and document it for the next team" then more often than not your boss will say "Sorry, budget has been spent, functionality is finished, no need to do that".
Am I seeing it right or not?
I concur with this opinion, and unfortunately this also happens in other industries.
Visibility is indeed a key factor here, others being security risks or bad practices that could come back and cost the company dearly.
Over the years, I've worked in various fields and industries, and this is a recurring issue. It is sad, but some companies (people) think they can get away with this, and much, much worse.
If you take this a step further, you may ask, how is the code we're writing going to affect the world? This may take you to entirely reconsider how you're using programming to influence people's lives.
I quit my job recently and have been soul searching since mainly for this reason. Why am I even doing programming? Am I contributing to the improvements I'd like to see in this world? I did some hard thinking and decided, it's not even worth doing it unless it's my tool for empathy, and for solving issues I'm concerned about.
I've just started a new role and it's daunting to be in the newbie state again. The company I've joined has been around for over a decade, but with organisational and product churn over the years there are a lot of confluence pages to read - and I'm always checking the 'last modifed' date. In some cases I'm looking at pages from 2012 and somehow they're still sort of accurate.
We're fortunate in that the company has hired some experience scrum masters who are acutely aware of how much information new hires need in order to get productive.
A really good read Schuster. Ill have to put my hand up and admit that I've been guilty of this. Although not deliberately, I've certainly not given enough empathy, when faced with some of the points you've touched on.