What Coding Is Really Like

Technology is moving fast, and how it’s built is still a mystery to most people. Developers command huge salaries, not only because they build the platforms on which most businesses stand, but because most of the people running those companies have no idea how they do what they do.

The practicalities of how a person inserts words into a text box, types a command and makes something work, eludes most people. And yet, despite their high wages, a lot of developers face challenges in the workplace. Orders come from en high to add features that aren’t properly scoped, the reasons given as to why these changes aren't a good idea are rarely taken on board, and they’re almost never given the opportunity to go back and create the appropriate structure to support them.

As a result, the salary isn’t so much a sign of respect, as compensation for the fact that they’re doing a job that requires a high level of skill, but does not command a whole lot of respect.

This problem is almost always created by a fundamental misunderstanding of the coding process.

My husband is a developer and I am a writer. In essence, what we do is very similar; we both write language in a logical format that conveys an idea. The main difference between our jobs is that while no one thinks they can do what he does, everyone thinks they can do what I do.

However, his job is made more complicated by the fact that different teams are brought on board to build different parts of the project.

Imagine you’re writing a book and one team is working on chapter 1, another is working on chapter 2 and another is working on chapter 3. The chapters need to meet in a coherent way, and while the teams are concentrating on chapters 1-3 there’s hope that with the right management the story set-up will be coherent and successfully support the rest of the plot.

Then imagine that an editor runs in and says:

“We need chapter 6 right now!”

The teams look at each other and say that they’ve not got to chapter 6 yet. That chapters 1-3 are almost done and are going into QA next week. Chapters 4-6 will be in the next round of code.

Then the editor says:

“Just stick some bullet-points down to indicate the story in chapters 4 and 5 so that we get the general idea, but we need the key plot-point in chapter 6 right now. Oh, and kill-off Dave. We don’t like Dave.”

The teams look at each other. Dave is the main supporting character but there are ways in which he can be cut, even if it will alter plans further down the line. Then someone asks if they’ll get the chance to go back and write chapters 4 and 5 straight after writing chapter 6, to avoid instability in the story. The editor agrees and flaps out of the room to report back to the board.

The teams do what they can to patch-through to chapter 6, killing-off Dave and producing the feature the editor wants. In the next meeting the editor says:

“Well done, we’re well on track and we can move straight on to chapters 7-9.”

The teams look at each other and ask what happened to chapters 4 and 5. The editor scratches their head and blinks a few times, pulls at their collar and does some mental calculations. Then reasserts the vital importance of chapters 7-9.

Two weeks later the editor comes running into the room and demands work on chapter 7 be completed in an impossible amount of time, and that chapter 8 needs to be finished stat. In the meantime the remainder of chapter 7 can be outlined with bullet-points.

You get the idea. Developers are constantly required to cut corners and patch their builds in order to reach ever tighter deadlines. Bugs proliferate at an unsustainable rate, and someone in upper management gets a promotion while the teams frantically try to assign people to tape-over the gaps left by the demands of progress at the cost of stability.

In the meantime the rest of the company departments laugh at the general feeling of pessimism and cynicism amongst the developers. After all, on their wages they should be skipping for joy!

At some point something has to give. Normally it’s a good developer leaving their job in the hopes of finding somewhere, anywhere, where they might get to finish chapter 1 before moving onto chapter 2. The only ones left are those who don’t care much about story structure and would rather do what they’re told than fight to create something of substance.

Soon after the good dev leaves, it’s decided that Dave is vital to the plot. He always has been vital to the plot. They can’t believe previous devs left him out and neglected his story arc. The new devs go back through the code, writing him back in and grumbling.