Programming Really Sucks

I recently had the pleasure of reading Peter Welch's Programming Sucks essay, which I felt captured a significant percentage of the delight of being a software developer. I'm pretty sure that most people in tech understand exactly what he's talking about.

I originaly composed a long rant about fundamental misunderstandings of what a "cross-functional team" is, and why hiring purely for "full-stack developers" just means you don't have a clue what you want. It didn't really add much to Peter's essay though, it simply wandered into some of the specifics. Instead, here's a rant about how thankless a lot of software development and systems work is.

I'm not really a "front-end" person, I'm terrible at user interfaces. I don't enjoy fighting with designers about what something should look like, and I'm not the kind of person who likes to spend time faffing with CSS to perfectly position things on a page to match some Photoshoped design that I've been given. It's fun to some people, but I'm not one of them. I'm one of the "all your forms are going to look like this throughout the system, and you will like it" people. I'm happy to produce a UI based on some stuff we drew up on a whiteboard, but the result will probably have creative crying into their keyboards about it not capturing the brand ideals, and how I've failed to create a snowflake page to showcase how the product differentiates itself from the alternatives. Or something. I'm also not a Javascript developer (lack of experience, not lack of will), which the increasing prevalence of rich browser applications is making a bit of a problem for me. Basically, I'm probably best left alone from UI elements that'll be seen by the customers.

I like working on the tools that make it possible for us understand what's happening with our platform, why, and what we can do to make it better. I like pulling apart something that's broken and trying to make sure it doesn't break again. I work on the processes behind the scenes that make it possible for the customer's order to become a real thing and for them to have a high probability of receiving it when we told them they'd get it; Or to at least allow us to tell them it's not going to happen, and why. I like tracking down deadlocks and obscure race conditions. I like beautiful, but above all, practical, software architecture. This is all good, we have lots of this kind of thing! We take orders through a web site, and convert them into real stuff. That's awesome, there's plenty of fun stuff involved aside from the bit the customers see.

The problem? It's mostly the invisible work.

"Hey, we're going to have a chance to demo some stuff to the entire company next week, what do you have?" is a question I dread. What do I have to show? Can I lug an industrial label printer into the meeting room, and show off the new shipping label system? Not really, that's impractical, and they look the same as the old ones anyway. New courier integration? Looks like all I've done is added a new option to a really dull select field. Logging infrastructure? Yawn.

I can spend days tracking down a bug and no one will notice. If I'm really lucky someone in CS might mention, down the pub, that no one has phoned up to complain about X for a while. Or someone in print ops might comment that they haven't told them to print something in the past recently. I love it when this happens, it makes my hard work feel meaningful.

I like to imagine that it's much better for teams that do more customer facing work, but it isn't. After all, the devs just "put on the web site" the thing the designers "made." Few people not in tech look further than the outward appearance of the system. Very few appreciate quite how much is happening behind the scenes. It takes a lot of time and effort to convince people that it's more complicated than they think.

Perhaps this means we're doing a good job? We've managed to hide the inner workings of an incredibly complex piece of software from the user. We did it quietly, in a calm and organised fashion. There was no panic, no mad waving of hands, no working evenings and weekends because we failed to appreciate how big the task was. It all went well. The only time someone's going to notice the developer involvement is when we break something really badly, or when we miss someone's deadline by months (even if the miss is caused by that someone changing fundamental requirements at the last minute, dev were the last ones to touch it.) No one's going to thank the dev team for a job well done when the new system doesn't spam a fatal error or trash your work if you try to interact with it too fast. People will, however, be thanked for spending the week after a disastrously broken product goes live running around trying to fix the mess.

I actually like being there when the world's on fire. I like trying to work out how it started burning, and what we can do to stop it. This is very much the systems admin in me showing through, I fear. Everything stops. People notice. Important people wave their arms around a lot. Then we fix it, and they heap praise on us for our work. This is wrong. It was on fire because we fucked up. We built it out of highly flammable things. We put it on top of a naked flame. Then we failed to notice that anything was wrong until absolutely everything was on fire. Then we couldn't work out where the fire was coming from, or how to stop it being on fire. This is not something to thank us for. We dun goofed. We're doing our jobs well when this does NOT happen.

I guess what I'm saying is that you need to make sure that people give you credit for the right thing. Make a big deal about the silent stuff that goes well, educate people outside of tech on what's involved in doing the software implementation for a project, and don't be tempted to accept the praise for fire-fighting: instead make it clear that the fire should never have been started in the first place.