How to Become a Bad Developer

The great mathematician Carl Jacobi once said "Invert, always invert". He advocated that, by analyzing a problem backward, one could uncover the best solution to it.

With that in mind, Berkshire Hathway's legendary partner Charles Munger gave a terrific speech to the Harvard School on how to not be successful (I originally read this and other Charles' speeches in the amazing Poor Charlie's Almanack: The Wit and Wisdom of Charles T. Munger). That made me think – what is the easiest way to become a bad developer?

What you will see next is a highly subjective, non-exhaustive unordered list of principles that, if you follow, I can guarantee will lead you to become a bad developer. I say "principles" because I am not interested in technicalities (e.g. choose bad variable names, never comment on your code, etc), once they are a sub-product of the guidelines you follow.

If your goal, fellow reader, is to become a good developer instead, don't worry. Remember that via negativa is way more powerful than via positiva. That means that knowing what not to do is safer and easier to figure out than exactly what to do. So pay attention to the following topics and decide which type of developer you want to be.

Never assume there is a bug in your code

“Vanity, definitely my favorite sin.” - Al Pacino, Devil's Advocate

Software Development is one of the few areas where you have a free pass to make mistakes frequently. This is a very good spot to be if the impact of the mistakes is minimal.

Yet, it is easy to forget that. You can be the best developer in your company and comparatively make fewer mistakes than the others. But the absolute number of mistakes you make will still be high, there's no escape from it. The good news is that's fine – machines need a lot of precision when communicating and one bad sentence is enough to blow up a 10,000 LOC codebase.

But because you consider yourself better than the other developers, which might very well be true, you start to think that you don't make mistakes. Or that if some issue arose, you have nothing to do with it.

The problem is that many times you will have responsibility. Doesn't matter if you were the author of the bad code, overlooked it in your review process or didn't anticipate it when planning. There are just too many ways of making mistakes.

So if you never assume that you might have blown things up, you will start blaming other things – your peers, the stupid framework you are using, an outdated browser or a pre-historic OS. Anything will be responsible but you. And if you never admit your mistakes, you are cursed to never evolve. And not evolving as a developer is fatal.

Write code without reasoning

The truth can be perceived only through thinking. - Thomas Aquinas

One of the first things that we learn as humans belonging to societies is that we need to measure the consequences of our acts. The same applies to programming. Ultimately, your job is to create value for people through lines of code. If you lose track of this, you have become a bureaucrat. And well, it's pretty hard for a bureaucrat to be a good developer.

If you act without thinking, you are wasting the very edge that you have over machines. You are a candidate to be replaced in the near future (either by a thoughtful human or by a cheaper dumb machine). Always try to understand what's the purpose of the task you've been assigned to. Unless, of course, you want to become a bad developer.

Lack assertiveness

Control your own destiny or someone else will. - Jack Welch

I am yet to find a good developer who is unable to report the issues he or she is facing with clarity of mind. This happens because computers are very obedient entities which only function when given precise instructions. If you are assertive when debugging your code, chances are you will figure out the problem by yourself. But even if you don't, you are halfway through the solution and a fresh pair of eyes will be much more effective in the process of helping you.

Remember that machines are very dumb and need to be correctly told what to do. And that you give them too many instructions during your work. Eventually, you will give the wrong instructions. If you can't effectively walk through your code and identify the misplaced directives, you will be a bad developer.

Take pleasure in writing more code

“Until we have begun to go without them, we fail to realise how unnecessary many things are. We've been using them not because we needed them but because we had them.” - Seneca

It is very common, especially among novice developers, to be proud of the number of lines of code their application has. This is, indeed, a very strong sign that you are in good shape to become a bad developer.

Every line of code is an instruction to a machine. The greater the number of instructions, the greater the number of mistakes are there to be made. It also means that you will need more knowledge if you ever want to change how your code behaves. By writing as many lines as possible, you are shielding people from your work. A code that nobody wants to read and many fear touching is a bad code.

I've mentioned via negativa before. Simply put, it means "the less, the better". The reasoning is as follows: there are many more ways to screw things up than to improve them. Someone who wants no trouble will focus on minimizing the probability of screwing the codebase, whereas a bad developer will actively look for more additions.

Recall that every line of code will eventually be read, tested, changed, incremented or even deleted. It's pretty clear that your workload is proportional to the amount of code. Someone who increases his or her workload unnecessarily is just a bad developer.

Write for machines, not humans

“It has become appallingly obvious that our technology has exceeded our humanity.” - Albert Einstein.

Finally, this is the most efficient way to achieve your goal of being a bad developer. I say that because writing code for machines instead of humans is the easiest of all the bad things you can do. It's terribly simple to write undocumented code, use inaccurate variable names, be inconsistent, forget about indentation, and so on.

You need to recall that machines understand machine code. All other things that are not 1's and 0's are just ornament to make code more readable to humans. If you don't pay attention to this, you are making humans' lives harder – thus, a perfect way to be a bad developer.

Think about what makes a text enjoyable to you. It is usually concise, clear, direct, meaningful and consistent. You won't enjoy reading when you can't understand the author, the narrative doesn't make sense, it's poorly written or weirdly formatted. Likewise, code that does not make sense and that you need to strive to grasp is an excellent form of discouraging the reader. And the same way an author who discourages their readers is a bad author, a developer who discourages their readers is a bad developer.

---

I hope that you find the above rules useful in your quest of becoming a bad developer. But if you ever change your mind and decide to grow into a good one instead, well, you now know what you need to avoid.