- Introduction
- Define speed
- Low quality software is useless
- Quality threshold
- Workflow beats talent
- Discipline is the new talent
Introduction
When hiring software developers, it seems that recently the focus has been on the speed of coding. Many companies give automated 1-1.5 hour coding tests where your code can be of any (=low) quality, as long as it passes all unit tests. Including all hidden tests, and including performance criteria in some cases. Your solution is too slow, or fails on some weird input - you failed an interview. No human is involved until you are able to produce dirty code for dirt cheap. Cannot do it, then you don’t get a job at big tech companies, and all other companies who want to be like them (but pay 2-3x less, go figure the logic).
In one case I was explicitly rejected because I was deemed slow. There was no coding test, and I never spoke to a real person. They just “inferred” it from looking at the profile. Needless to say that, as a former ACM national top 50 (15 years ago), I was a little offended. But let’s put aside the validity of the claim for now.
Define speed
The point of this article is to question the status quo - is speed of producing the initial dirty version of the code actually important in modern software development? Or is speed of the software itself more important? Or the speed of fixing a bug in production that saves tens of thousands/millions of dollars every hour? Or delivering a well tested feature within a tight deadline, based on existing quality code? Saving QA’s time, and saving the back and forth between dev/QA/BA/other folks, perhaps?
As mentioned before, during an interview, no-one is probing the candidate for this. And it’s precisely these and other similar points that make a bigger portion of Software Developer’s wisdom. Notice I did not say “experience”, that’s measured in years. Wisdom is all about the quality of solutions, not quantity of them per time interval. Wisdom is why some software works for years without touching it, and another fails every single day with random issues.
Low quality software is useless
Write the code slowly enables one to create a solution that will stand the test of time. Asking yourself questions, testing various edge cases that are unlikely to happen - is how code becomes perfect. At least, to the extent of what’s humanly possible. If you want quality, you have to invest some time into it. Try cutting a corner and someone will eventually throw your solution to garbage and write another one. It’s a very important point here, making a few mistakes does not just make your solution less useful in long term, it makes it completely useless.
Quality threshold
Which brings me to my next point - for any kind of business requirement, there exists a quality threshold, below which software becomes 100% useless in the foreseeable future. For the purpose of concreteness, let’s say this future is within 2 years, although a lot of software has serious failures within weeks/months of delivery, especially if done by low skill contract labor. Based on my experience, this quality threshold is dynamic based on the nature of business. Some world class cloud hosting software will be less tolerant to silly mistakes than a private site with 100 weekly visitors.
We established that mistakes are bad and should be avoided. So let’s hire only those developers who don’t make mistakes, simple, right? Everyone makes mistakes. Good developers make fewer. Bad developers make a lot. But good developers also write more code on average. It actually might be that good devs and bad devs make the same number of mistakes per time interval (say, a day). Mistakes are part of human nature, they are what makes us human.
Workflow beats talent
After a few years of banging the head against the wall, wisdom suggests that it’s better to use a workflow that eventually produces high quality code. Not from the first time, but eventually. Why is it better? Because if you can create such a workflow, you can guarantee quality to the extent not possible even for the greatest devs out there.
In modern development world, process beats talent - that’s just my opinion. And yes, workflow means you output code at a slower pace, often 10x slower than you would otherwise. But it ends up being cheaper for the company, because mistakes are found and corrected early, before more people spend time on them. One of the companies I worked at during my early career, my manager said that it’s better to spend 10 hours to test and fix all issues we could find, than for QA to spend 1 hour later, return the ticket, fix and assign back to QA. On the same note, at enterprise level it’s actually cheaper to spend 100-1000 dev hours to save 1 customer-hour.
Discipline is the new talent
Alright, workflow is great, everyone can follow it, where’s the catch? Unfortunately, you cannot just tell everyone to do steps 1-100 and expect them to do it. If developers don’t understand why they should do it in a certain way, they will not do it. Or they will make mistakes doing it. Or they will do it for a while, and then forget about it.
Our brain is wired to avoid work. Productive thinking requires discipline. If you have a choice - to watch a Netflix series or study a new algorithm, which one do you pick? Most will choose Netflix. It’s easier, less brain work. So make that into the hiring process.
Give a marshmallow-style choice, observe candidate’s response. Check into how much effort they are putting into making a better self, every day. How long can they go with an idea before giving up or shifting focus to their favorite activity. In short, if you give them everything to succeed, will they succeed? The results of such test will be a lot more fruitful than with pure coding exercise and synthetic puzzles.
