Write bad code and don’t be ashamed of it

I can write good code. This usually involves spending a little more time here and now in the name of some better world order in the future. But here we start from the premise that we know what to expect from the future. And in development, the future is usually difficult to predict.

Uncertainty can be generated by the fact that we do not know everything about the technology, about the business, about the user, the amount of data in the system, the lifespan of the code, as well as other unknowns that we are not even aware of (for an extended list of examples, refer to 2020).

In a situation where the future is uncertain, the duration of the cycle comes to the fore. Speed ​​allows me to extract value from my own code: I learn new skills faster, the harm from bad code or individual errors in good code is minimized, and the product gets to market faster.

Any obstacles have a bad effect on the duration of the cycle. They deprive me of the ability to turn uncertainty into certainty – and this is the essence of learning. Fast learning forms the most sustainable value, it acts as a kind of coefficient by which the quality of the code and architecture is subsequently multiplied. There is a saying “To write is to rewrite”, and if you translate it to code, you can say: “Writing code means refactoring”.

With that in mind, here are a few reasons why you shouldn’t be afraid to write lousy code. More precisely, why you should not be afraid to write more lousy code.

It improves coding skills

If you want to learn how to program, the best way to do it is to practice. As I have established for myself, you can read as much as you like, but until you type the code with your own fingers, the information will not be retained. Writing code is not something that can be learned in a day, it is a certain way of thinking and approach to solving problems, as well as a set of knowledge about tools and computing environments. The only way to deepen the necessary knowledge is to work with these tools and environments. Every time I write something, I set the stage so that next time it will be easier and the result will be better.

It helps to re-experience the joy of creation.

When you write lousy code, the main goal is to get something out of it as quickly as possible. And that means a direct path to that satisfaction and sense of success that comes when something—anything—begins to work. I wrote the first line of code thirty years ago, and yet I’m still thrilled every time I can get another piece of code up and running.

This allows you to study non-working code or a non-working system.

Sometimes systems don’t work. As I could see, this is what provides rich opportunities to learn something. I learned the most valuable lessons not from some pre-calculated code quality compromise, but from those cases where the behavior of the system did not fit into my expectations at all.

In addition, when you give all the best, trying to write flawless code, there is an emotional involvement in its correct work. If, upon completion, some errors occur, the first thing you do is start looking for an external cause. Well, the soul does not hurt about the functioning of the lousy code. If something goes wrong, then you simply proceed from the fact that the code is the “weakest link”, and immediately begin to disassemble it and the system piece by piece, learning a lot of new things along the way. This approach stimulates curiosity and does not spoil the mood.

The code is never closed in itself. Any unexpected failure by default suggests that there is something about the operation of the system that I don’t understand. This means that any mistake is a perfectly designed individual lesson, adapted for the maximum return on learning.

It teaches you how to fix bugs

When I write code, I have several standard feedback channels. When I write lousy code, these channels start to run at a higher frequency. Naturally, I am faced with an urgent need to figure out what and how to look at in order to evaluate the functioning of the code. Each attempt to write code leads to a deeper understanding of the tools – sometimes you learn some keyboard shortcuts for the editor, sometimes you write a script to automate that stage of testing that you previously did manually. The bottom line is that when writing code, both the tools themselves and my ability to work with them are improved.

It helps to explore the design field

When I write code that implements some functions unfamiliar to me (that is, almost always, otherwise this is already refactoring), I have no idea about the design field. I don’t know what is possible in principle, due to lack of information.

Those who are learning to draw are sometimes given the following task: they need to make 5-10 rough sketches on a given topic, and then complete 5-10 options for each sketch. This is the study of the design field. Sometimes I find myself comparing two possible architectures, but this greatly narrows the scope of what is actually possible – there are probably dozens of hypothetical architectures. When you write a lot of lousy code, you have access to more options. It leads to a certain point from which a new, more complete overview of the possibilities opens up.

Reduced expectations free thought and untie hands

I know I’ve talked about this in the previous paragraphs, but the change in state of mind when I turn off the egotistical desire to have “everything right” in the code is enormous. Instead of annoyance and irritation, I feel curiosity, the joy of discovery and satisfaction from the result achieved. Even if all other arguments were wrong, lousy code should be written more often just for the sake of your own psychological health.

Finally

Experienced senior developers love to talk about how code “should be”. Often these are descriptions of some inaccessible promised land, where they themselves have never been. Some of these “shoulds” add up to frameworks that help prioritize system design. The very best explicitly indicate the need to understand when the rule should not be applied. But in the end, all of them are useful as long as they guide you, and they cease to be useful if they start to slow you down.

In other words: don’t lose direction, but with peace of mind, allow yourself to write crappy code here and now.