How good programmers deal with bad code

Maybe you've never written a bad line of code. It's possible, but unlikely in reality.

The reality is that, like every other programmer on the planet, you will produce code that has security holes, UI elements that move around, etc. This doesn't make you a bad developer. It's just that you're human - a creature that is bound to make mistakes.

It is this "human nature" flaw that every developer has that drives the best developers to take responsibility for the shortcomings of the code and the underlying infrastructure and act with preparation and planning. Here is what they will do.

[[147409]]

Assumptions

A few years ago, Netflix open-sourced Chaos Monkey and the rest of the Simian Army, a suite of tools for managing cloud-based software. Essentially, Chaos Monkey ranges across Amazon Web Services infrastructure, terminating instances at will. It's basically a way to prepare for the worst by creating the worst possible scenario.

As Netflix's Cory Bennett and Ariel Tseitlin wrote in a blog post at the time of the release, "Code will fail, and the less you expect it to fail or the less prepared you are, the more likely it will fail. If your application cannot tolerate instance failures, would you rather be called in at 3 a.m. or stay in the office all night?"

By simulating failures in unpredictable ways, Netflix forces us to focus on the resilience of our infrastructure. Rather than assuming the worst, we can prepare for the worst. That way we can happily move on to the next process.

test

Above we talked about a great way to improve infrastructure, but what about code?

Jeff Atwood, a programmer, has the answer: "You need to tweak your code." He writes:

I believe that a key turning point in every professional programmer's career is when you realize that you are your own worst enemy, and the only way to mitigate that threat is to accept it. Treat yourself as your worst enemy. Break your UI. Break your code. Break your software.

In practice, this means that "programmers need to have at least some understanding of common errors, however, many programmers often do not do so, or even do the opposite." This means that your responsibility as the "God of Programming" also includes becoming the "God of Testing", actively eliminating errors in the code by "tormenting" it.

Andre Medeiros added that we should be "getting better" at debugging because developers need to do more with their code.

“To prevent bugs, you need to write code that is simple for any programmer to understand. To fix bugs, you need to understand your code. To understand your code in detail, you need to enumerate and verify your assumptions, and if necessary, build debugging tools.”

Skyscrapers above slums

Of course, one of the biggest problems with our code is that it inherits from so much other code. Especially in established enterprises, we often build on top of old code, which leads to all kinds of downstream problems.

Here is a great description from Zeynep Tufekci:

Think of it like building a house - you're going to build a second floor on top of the already built ground floor. But the house wasn't built properly in the first place, the foundation wasn't laid, and you don't know which walls are load-bearing. You just guess as best you can, and build a floor - with your fingers. And then you keep doing that. Many old software systems that control critical parts of infrastructure work this way. It works for a while, but each new floor means more vulnerabilities are added. We are building skyscrapers on slums in code - in earthquake zones.

It was clear that there was nothing we could do to improve the situation unless we worked on removing the technical debt.

But maybe, just maybe, in the process of willingly tinkering with your code, you’ll discover how important it is to eliminate technical debt.