The code

The code

Thoughts about the 0’s and 1’s

Table of contents

No heading

No headings in the article.

Every line of code you don’t write, you don’t have to maintain.

Every single line of code adds complexity to your software. It needs to be developed. It needs to be tested. It needs to be deployed. It requires maintenance. It can break. It can affect other parts of your software. Whenever you feel the urge to add code, think again. Does it justify the work that’s required? Not only to write it but also to keep it intact.

The real 10x engineers are the ones who delete code instead of adding it.

10x engineers are overrated. I’m not even sure if they’re a real thing. The most valuable engineers are the ones who make software less complex. Either by removing code instead of adding even more or not adding any code at all.

Good code reads like a book.

If you’re reading code in an unknown project and you quickly know and understand what’s going on, then you know you’re dealing with good code. Great code should explain itself — even without comments. Comments can add value at times, but generally speaking, code should also be readable without plenty of comments.

Don’t add code unless deemed necessary.

Writing software is fun. But in real-world projects and products, code should only be added if it’s necessary. Don’t add code just for the sake of it. As stated earlier, every piece of code comes at a cost. If you don’t need it right now, don’t add it. Because if you don’t need it right now, you probably never will.

Coding is thinking.

Coding is thinking — executed. Essentially, a piece of code is just thoughts, written in a form computers can understand. When you sit down to solve a problem, you should already have a rough solution in mind. Great code can’t be produced without thinking clearly and thoroughly. Think, then code.

Good code is as complex as necessary, but as simple as possible.

Building a feature in the most complex way is a red flag. Some programming languages can do fancy things — things that make it especially hard to understand what’s going on. Try to strive for the simplest solution possible. Code gets more complex over time automatically. No need to make it extra complicated in the first place just to show off exotic skills.

The code is the truth.

Computers are great at doing precisely what we tell them to. If something doesn’t work as expected, you have given the computer the wrong instructions by writing false or faulty code. Don’t expect the problem elsewhere. Technically speaking, your code always behaves correctly. It just doesn’t do the right thing (correctly).

The code is the only real documentation.

No matter how well you maintain any kind of documentation of your code, it’s almost guaranteed to be outdated. The actual code is the only real documentation of what’s going on in your software and why/how a feature behaves a certain way. Documentation is good, documentation is necessary. But the code is the single source of truth.

8 hours of thinking, 1 hour of coding > 1 hour of thinking, 8 hours of coding.

It’s stupid to measure the output of a software engineer by hours spent writing actual code. Coding is the final piece of the puzzle. It’s way more important to sit down, think, and come up with the best possible solution for the problem at hand. Focus on solving the problem first, then sit down and write code. Not the other way around.

A programming language is just a tool.

Every programming language has its specialties — it has its strengths, it has its weaknesses. And it has certain areas of application. Different programming languages are suitable for different kinds of platforms and problems. But a programming language can always be learned. It’s most important to master the foundations. If you’re a problem solver and if you’re good at abstract and logical thinking, you can code in any language.

The best code is no code at all.

If you’ve read this far, then this point needs no further explanation. If you skipped everything, go to the top.

To be continued.

Thanks for reading. If you enjoyed this post, feel free to follow me on Twitter.

Did you find this article valuable?

Support Ronald Blüthl by becoming a sponsor. Any amount is appreciated!