The internet is a great place for online discussions and other rants about work related problems. I often see posts of people complaining about the field in which they are working, claiming: “Oh, if only I could work on the important problems for humanity and not whatever I am doing right now, then I would really be happy. Besides, the code is probably better designed and well tested in comparison to what we are dealing here.”
As someone who worked on some of those “important problems” for the brighter future of mankind, I can tell you a little secret that is not being told on the street. Working in a different domain that sounds exciting is not going to make you any happier, because the problems of those glamorized projects are essentially the same as the problems that people are facing in less admired domains.
If you stop a random person on the street and ask them about the important problems that this world should be focusing on, they might come up with a similar list to the one below:
- Solving world’s hunger
- Curing cancer
- Exploring the space
- Making infinite amounts of (clean) energy
- Inventing a technology to find the project’s documentation
In the past I was working on a medical software that is used in cancer treatment procedures as well as on the control systems that will be used for finding out the secrets of this universe in the not so far away future. In comparison to working on yet another social network those seem like an admirable projects.
In reality, working on this or that system in one of those restricted domains is not really that much different from working on yet another business application. We are still using the same awful programming languages with the same Lovecraftian build processes and there are still programmers that are blindly cobbling things together without really knowing what is going on. There are still project managers thinking that 9 mothers will give a birth in 1 month and the customers that have no idea what they really want.
The only difference between the two is the unreasonable amounts of documentation that somebody (hint: you) has to write in a more restricted field. Before you can start writing a new feature for a medical software you better have a closet full of documentation, otherwise the rubberstampers won’t give you the right certificates that are necessary for using your software in the real world. You don’t want to harm people with your healing device, do you?
Needless to say, just because you have all the right papers, design documents with thousands of pages, compiler verifications, analysis of 3rd party libraries, automated tests covering the requirements and hordes of people keeping up the documentation according to the ever changing standards, that doesn’t mean your software is actually working or any safer to use. A wild null pointer dereference might still crash your software in the middle of the treatment process and no certification committee is going to prevent such problems from happening (the patient might not die, but they might still suffer some consequences which are promptly swept under the rug). All this work that went into shuffling the papers around is also the work that didn’t go into improving and testing the software 1.
If you have ever seen a medical machine up close, it most likely looked like a nice clean white machine coming from the future. But, behind the shiny white plastic lies the ugly truth. The code that is powering that machine is in fact not any better than any ol’ code that you have written in a hurry and is now rusting on your hard drive. The only difference is that the code has paperwork which makes it very valuable akin to the dog with a pedigree. If you lose the papers, you still have the same dog.
Some codebases that I had to review in the past were downright horrifying. Hundreds of man years were put into the software that ended up being either scrapped or patched by expensive consultants for years due to the clowns getting out of the car with no adult supervision. The software industry is still in the early stages of figuring things out by poking them with a stick and seeing what happens. Most of the time the outcome is a total mess, because of the organizational complexity that a large project brings and the corporate snails whose top priority is to justify the existence of their jobs over doing something useful (see also On navigating a large codebase).
In other words, if you think that you will somehow escape the problems of the software industry by moving into a more restricted field you are in for a treat. Despite hiring only the best, the code is just as bad 2.
Happy is as happy does
There is a great article that goes into a much greater depth describing what makes the engineers happy, so I won’t bother with outyelling the old masters (see The care and feeding of software engineers or why are engineers grumpy). If you are some kind of a manager, you should definitely read the post linked above. Go on, I’ll wait.
All of humanity’s problems stem from the man’s inability to sit quietly in the room alone.
Blaise Pascal
For some reason there is always yearning to achieve more than what you have done before in order to reach for the stars. Once you are starting out your career, you can’t wait to become a senior developer. After that you can’t wait to become the tech lead and later the department’s architect 3.
And then, where does it stop? Chief architect? C-level manager? Owning your own company?
It never stops and it’s never enough, that’s why you see people amassing incredible fortunes but still craving for more. In the same way the honeymoon of changing the job in the new field of work wears out quite soon. There are all these problems that are just repackaged same old problems that you are already familiar with and most of them stem from the fact that people are just not good at working together in large groups.
The average time for a programmer before they switch the job is 2-3 years, irrespective of the company or industry in which they are working for. Often people from the outside of this industry wonder why would someone leave such a great company that is working on all these important problems. Despite the outside bling, there is usually a total shitshow going on inside, so it’s not surprising to find the articles from people who are proud of leaving the software industry in order to become the goat farmers or something similarly silly. The childish attitude of tech corporations where everything is coded with love, full of emoticons and everybody publicly being proud of working on a product that is deeply mediocre simply wears you out.
So no, writing the software used in space exploration is not going to make you drastically happier than what you already are. It sounds impressive to the ones that don’t know how the sausages are being made, but other than that, it’s not that much different from whatever you are already doing.
Wouldn’t it be better to have more people working on the mentioned things at the beginning of this post instead of having the big brains locked up thinking how to trick you into clicking on more ads on yet another social network? Sure it would, but until working on important problems pays as good as working on social networks does, that’s not happening.
But, I want to make this world a better place…
…and all I am doing is working on the yearly rewrites of our company’s website.
You already can. Remove some Javascript from it and the world will thank you.
Notes
That said, there is still be some value in requiring an extensive documentation in place. It keeps the sledge hammer web dudes away since they can’t just use a random library that was released yesterday. Adding a new 3rd party library might be such a painful process, that the programmers will often swing into the opposite direction and rewrite everything from the ground up - even a text editor if that happens to be an easy way out of the bureaucrats’ claws.
The main problem with heavy paperwork processes is that they impose the subpar solutions to the given problem, like writing your own text editor for saving configuration files used by the medical software that may harm the patient. Verifying that off the shelf text editor is not corrupting files is actually more work than just writing your own, since if the software was not entirely written by your team you would have to analyze all the public/known issues of that editor. Checking the issue tracker for any semi popular open source project will reveal thousands of open issues and some poor sap would have to muddle through all of them and verify that those issues are in fact not mentioning any file corruption problems.
Now tell me, which text editor is more likely to have problems with doing something ordinary like saving a file? The one that is on the market for a few decades and used by half of the world or the one that was written yesterday by someone fresh out of school? ↩︎
We hire only the best is such a ridiculous statement. Nobody is actually trying to hire the worst, but somehow most of the people in the generation end up being hired one way or another. I presume they end up at those other companies. ↩︎
Well, you could branch straight into management too, but I picked the technical path since I assume the audience here are mostly engineers. If any manager is reading this babbling: “Hi there, you are welcome here as well.” ↩︎