The worst jobs I had as a software developer had one thing in common
Since becoming a software developer, I had the opportunity to be part of various companies, big and small. I’ve been part of corporations, scale-ups and start-ups, with 6 to 5,000 employees. Looking back at my biggest frustrations, I realized that all the companies at which I had the worst time (mentally, emotionally and professionally) had some things in common, and one thing stood out as being the worst of all. But let me first explain some software development basics to you before revealing what this common thing was.
Why software development is so hard
Fixing your car to change a light bulb
In software development, the complexity of a task and the time it takes for somebody to complete it are not proportional. This is because the successful completion of that task doesn’t always only involve writing code. That code is part of a bigger system, whose elements fit nicely together, or are duct-taped and about to crumble at the lightest breeze like a late-stage jenga tower.
A good analogy for you to understand this is the following scene from Malcolm in the Middle, when Hal tries to fix a light bulb and ends up repairing his car in order to fix said light bulb:
So, it’s no wonder that the most painful thing a software developer has to do in their day-to-day life is to estimate how much time it will take them to complete a task. This pain is increased by a factor of 2 if the developer is new to the code base and the code base is not well documented. (For me, anybody who doesn’t have a full and complete overview of the code base is “new”, and the time for them to become familiar with it is determined by seniority. So, it might take a senior 3 months to get to know the code base, but a junior, 12 months).
Tell me what you want, what you really really want
On top of overall system complexity, there are external factors that influence how long will a task take.
I saw a joke on LinkedIn the other day that in a junior developer’s library, there are books about frameworks and the basics of programming, while in a senior developer’s library, there is only one book: “Applied Psychology”.
This is because people have a hard time knowing what they want. Or they have some general overview of what they want, but they don’t know all the details themselves, so they are waiting for the developer to fill in the gaps. This adds to the delivery time, because the developer has to also play the role of Product Owner/ UX Desinger to complete the task. Then, it may happen that half-way through the implementation, the stakeholder finally decides to change something, that might require the developer to start over the whole process.
Brooks’s law
So, it’s obvious that the first thing a manager would do is to look at workload. “Do we have enough people to deliver everything fast and at a high quality?”
Well, it turns out that adding more people to a software development team doesn’t always help. It can actually make things worse, as Fred Brooks explained in his book “The Mythical Man-Month” (written in 1975, but so actual, it hurts). One of the most anecdotal expressions of this law is: “If it takes a woman 9 months to give birth to a baby, it will take 9 women 1 month to give birth to a baby.”
This law states that the more people are added to a software development project, the more the project will get delayed, because there is a lot of cross-communication that needs to happen for those people to be able to complete the project.
If we extrapolate this law and simply consider the high turnover in the software development domain, then we can understand that people coming and going on a project require the existing people to bring them up to speed with the code base, processes and so on. There is a transfer of knowledge that is necessary for the newcomers to become productive.
So that one thing that pained me the most was…
Being asked to do the impossible and then being the only one blamed for failing.
Impossible means: “Deliver a new feature in 2 months immediately after you joined our company”. “Juggle refactoring core features of the platform with new feature development. If you fail to deliver the new feature, we will cease to allow you to do any refactoring in the future.”
This was often coupled with a feeling that I was just a “hired brain”, a “code monkey” whose only role was to write code. It was of little importance if the code was good or bad, clean or dirty, duct-taped or glue-gunned. They just cared that I add to the pile of sh*t and deliver — fast.
I think this mentality is characteristic of businesses that have no (senior) tech people in management and/or refuse to require management to educate themselves about basic software delivery principles. It’s like you put a simple soldier in charge of leading a battalion to war and expect a victory.
In the end, it’s baffling to me how little these software development companies care about their most valuable asset: their developers. It seemed to me like they considered these people blue-collar and not white-collar, just because they had to sweat and do all the dirty work day after day.
I hope I’ll live to see the day when this profession becomes more understood and all the hard work and mental exhaustion that comes with it are respected and acknowledged.
