Dear community, how high is the quality of your codebase? This question may come as a surprise, but it could be asked by experienced developers in a job interview or, after reading this blog, will come up more frequently in job interviews. This is because the question is of enormous importance for companies and applicants alike and is a key factor in a key decision: to join or to leave. Let’s take a closer look at this together.
The codebase comes into focus
The codebase can be compared to a garden that an employed developer tends every day for his company. The earnings from this garden (vegetables, fruit and more) are sold, thus securing the company’s revenue and the developer’s income.
For some companies, the codebase is the central product. For other companies, self-written software to individualize their own business processes and thus secure competitive advantages has so far only been an accessory, but that is changing. Advantages through software are becoming increasingly important for these companies, so they also have to develop software much more professionally.
Quality has many aspects
Quality with regard to the codebase has many facets. Can the code be read easily, quickly understood and also checked using unit tests? This immediately brings to mind CleanCode.
What about automation? Unit tests can be carried out automatically every day, for example, as can static code analyses. Both bring incredible added value.
Let’s take one last aspect: documentation. How is documentation done? Is it so anachronistic that you unpack an Underwood No. 5 typewriter (from around 1900) for documentation, or is it done according to modern standards, in which the code documents itself in many ways?
Importance for applicants
The question about the quality of the codebase in the interview is aimed at finding out something about the development culture within a company. Where does the team or company you want to work for in the future stand?
It’s about methodology, software tools, development artifacts, procedures, communication and much more. All of this creates the basis for an experienced, modern developer to contribute confidently with all of their skills.
Security is becoming extremely attractive here. As a developer, would you rather expand or correct a low-quality codebase, all on your own, without being able to understand and test it properly?
Or would you rather choose the codebase that is being further developed by a team with overall responsibility, about which you can exchange ideas, which is largely self-documented and can be tested at any time?
Which of the two options sounds like overtime, hassle, loss of nerves and other unpleasant things?
Importance for companies
Companies need experienced developers to maintain an existing codebase or to build a new one. But you can get experienced developers, above all, if you have a handle on what the developers are interested in: code and coding. In other words, the result and the process that leads to the result.
Of course, I can already hear the many voices saying: no, it’s about salary, vacation and things like that. Sure. That’s what it’s about and it will always be that way.
But very good developers are not very good developers because they have the highest salaries and the most vacation. For them, it’s about gaining experience and doing something special with their skills. There’s a surprising amount of self-fulfillment and personal satisfaction in that.
For companies, the quality of the codebase is also important from a different perspective (let’s leave aside the typical points like lower error rates, better customer loyalty and all that).
It’s about how quickly a new employee can familiarize themselves with the codebase and make a positive contribution. It’s now easier than ever to join a company remotely and leave just as quickly. Gone are the years when employees stayed for 10 years or more. In my estimation, it is now more like 2-3 years.
So the homework for companies is to critically examine their own development culture and the results to date, i.e. the code base. If the verdict is unfavorable, urgent action must be taken.
Closing remarks
You don’t have to be an applicant to think about a company’s development culture. As an employee, you can question it at any time and initiate changes if necessary. The same applies to companies. You don’t have to wait until an employee asks.
With that in mind
Michael