Suppose a manager is interviewing two candidates for a developer position. The first is Mike, and his talent is speed. In a mere two hours he can finish coding assignments that would take most people a whole day of work, but his code is messy, relatively inefficient and difficult to read. The other candidate is Jess. Her code is so elegant and clean that it borders on perfection, yet it takes her almost a week to complete a deliverable that most people can finish in a day or two.
Who should the manager hire?
The question is not as straightforward as you may think. On paper, of course, clean code is always preferable to messy code, even if one has to wait longer for it to be delivered.
In the business world, however, time is often a critical asset, and whether a company should hire Mike or Jess will depend on several variables which both candidates would do well to understand.
Let’s look at what these variables are.
When should the company hire Jess?
We will begin with Jess as the reasons to hire her are probably more intuitively grasped. Most smart developers know it’s best not to rush code, because clean code saves time on the long run. Or, more to the point, code requirements change over time: if you wrote an app that lets you plan journeys by bus, one day you might want it to be able to plan journeys by train too, and then you want to return to code that is easy to read, understand, and modify.
Changing code doesn’t necessarily involve adding things to it, however. It may simply be the case that you need to find and remove a bug.
In both of the above example scenarios, you want Jess to be on your team. It doesn’t matter that she extended the project’s running time by three weeks if her code will end up sparing you three months of work further down the line.
Besides profitability, there is also the matter of responsibility. If you are coding a program that helps doctors find the right treatment for their patients, then your margin of error must be absolutely minimal, because for somebody out there it could make the difference between life and death.
Furthermore, even if your code isn’t involved directly in safety procedures of any kind, it’s sufficient for it to be used by a large enough number of people for your level of personal responsibility to rise commensurately. You cannot afford to make hundreds of thousands of people experience the same annoying glitch – that is a lot of tech rage you are putting into the world!
When should the company hire Mike?
There is not much point in saving time in the long run if failing to deliver by a deadline means there won’t be a long run in the first place. This is a problem startups have to deal with all the time, and their response needs to be rapid and agile or else their company may go bankrupt.
The broader principle, however, is not limited to the business model of startups alone. A software company may choose to produce a large number of prototypes in order to test the market, in which case someone like Mike, who can deliver a flourish of such prototypes in a short time, is worth his weight in gold.
An ability to program quickly is essential to confront business emergencies. It is also useful in a company’s day to day. Not all code is built to endure, or to be used by very many people. Perhaps you need something that can generate a report on your software’s performance at a time when you are still in the process of building it. Once you are finished building, you probably won’t need to generate that same report again, which means you won’t need to reuse the code.
In that sort of scenario, it is of no consequence if said code is messy or inelegant. It just has to generate the output you are looking for. Any effort expended on making it do more is a waste, potentially a costly one.
Not all companies are the same, and they do not all require the same type of developer. Being able to write code of excellent quality is, in most cases, the most important skill a developer can have.
But being able to deliver results quickly is also an important talent, and in certain, not infrequent situations, it could make the difference between a company’s life and death.
Which one between Mike and Jess will get the job therefore depends not on their profiles alone but also on those of the companies they are applying to. If your set of skills resembles that of either these fictional characters, make sure you research the companies you apply for, and make sure you’re the type of developer they want, while having confidence that both of the above models – and others besides – are valuable and desirable.