Recently I stumbled upon a very cool presentation by Tobias Pfeiffer – the main topic was clean code. Since we are engineers, code quality was always a key factor in our work and probably that is why we found this presentation so compelling.

After reading this intro you may think that this will be very technical, but let me relax you – it won’t. I think that anybody who has a really basic knowledge of engineering principles or any coding experience will easily understand this piece of content. 

I’ll just write the key takeaways that I got from this presentation, and would really like to know your opinion on these matters, so do not hesitate and contact me:)

1. Engineers tend to read code way more often than actually write it.

This may seem like a surprise, but it’s actually 100% real. Whenever you have to implement any new feature you first need to dig into what has been written before. It’s ok if you were the person that wrote it (maybe you still remember it) but it’s way harder when it was written by somebody else. That is why you should always assume that somebody will read your code eventually, and write it as clearly as possible.

2. Write simple code, that is easy to read.

Simple as it sounds – write simple code. What it actually means? The more you feel like documenting the code in order to be understandable, the worse:) The structure should be logical and clear. NEVER try to reinvent the wheel.

3. Nurture your codebase, even if it’s good

Writing a good piece of code is not the end of the story. Every code needs nurturing, updating libraries and making sure that its quality is consistent with the rest of the application.

Try to use tools like CodeClimate to keep the standards up to date. And remember – if you omit this step, there is not much sense in writing it correctly in the first place:)

4. Good code base is way more important than you think

Try not to accept pushes from the client-side. Time to market is, of course, important, but having a codebase that is easily maintainable in the future is even more important:) In the end, writing bad quality code will cost your client twice as much, because of the need to rewrite huge chunks of it in the future. Besides, it will be way harder for you to find future developers if your code will look like spaghetti that can walk on its own.

5. Refactor whenever you have a chance.

Very important, and very often forgotten practice. Whenever you get a chance, try to refactor the part of the code you are touching. This will save you a lot of time in the future. At the time you will be doing you will spend only 10% more time, but if you will try to do it in the future, you will spend twice as much.

At this point, you may ask how all of these points influence your project?

The answer is  – heavily. At HubOfTech we believe in a professional approach that forces us to write code with the assumption that at some point we may give it to another company or internal engineers of the client. In each case, we should push ourselves to limit the number of “WTF” used whenever reading what we have done. What is also important – a good codebase will allow you to scale the product way faster, and attract good talent (because everybody wants to work on well-maintained code). And even if this argument does not seem important at the MVP stage – believe me, it will be crucial in the following phases.

What is also very helpful in this respect is covering your code with as many tests as possible. Maybe the time-to-market will not be that fast, but it will heavily speed up future iterations – so it’s better to spend a bit more time/budget at the beginning, to make the future more efficient.


To sum up – the main idea I would like you to remember after reading this article is the following: If you want your product to grow without problems and you would like to attract good talent to work on its development you definitely need to pay attention to all those little details. 

If you feel like watching the whole presentation, it’s available here: