High-Quality Software: Start with the Right Team
Creating quality software is a challenging endeavor, while producing poor software, unfortunately, is easy. Over the last 25 years, I've realized one clear truth: good developers produce good software, while poor developers, despite any intervention, deliver horrible results.
Good developers make good software, bad developers build horrible software
To build software that fulfills business needs today, and can be easily and inexpensively evolve for the foreseeable future, you need a good team. It’s that simple.
Side Note: You can’t force quality from poor developers
I've made numerous attempts—some monumental in effort—to have weaker developers achieve strong results, and failed miserably. I have also tried to find tasks for those developers, perhaps less critical items, and found even those result in unacceptable quality.
How to create a team of good developers?
:: Building a Team of Good Developers: A 3-Step Process
There is a hidden step #0 - "Hire constantly" but it is just a natural result of the 3 step process
:: Step 1 : Interview For Character, Not Just Skill
This is actually the hardest step to get right, but fortunately, the least important one to nail perfectly. Even if you make a few missteps, the overall system will still work. Just continuously refining your interview approach over time.
Basically, when interviewing, focus on these essential qualities of a strong developer:
We don't focus on tech ability
"Technical ability" is intentionally not on this list. While technical skills matter, they’re a natural byproduct of the two main characteristics. During interviews, I test for technical skills mainly to gauge a candidate's current experience and the time needed to onboard them. However, character is our main focus.
:: :: Interest and Passion For The Field
For someone to be a high-quality developer, they must be genuinely interested in technology. I typically ask about their interests, what they learned recently, what news they follow, what personal projects they did or want to do, are they involved in any open-source projects, etc. I will NOT hire a person who does not convince me, in at least some small way, they are really interested in what they do. I have not always followed this rule but I learned the hard way that it was always a mistake.
:: :: Programmer or Software Engineer?
Then I test for love of programming and software development. Those are actually not synonyms. I find that the most brilliant programmers, love programming but hate building software. They love solving puzzles, optimizing algorithms, writing code for its own sake, but writing software that solves some business need, is typically beneath them. They will do great at Google or Microsoft or alike. They do not fit well in a typical IT department. On the other hand, there are those who love solving business needs through software solutions, but hate programming. Those will make great business analysist, not developers. I look for those who enjoy both writing code and crafting solutions that satisfy users. This comes through when discussing past jobs, favorite projects, and even workplace challenges.
:: :: Eager and Willing to Learn?
Besides that fact that any technical job requires one to learn non-stop, and therefore we want people who actually enjoy it, understand it, and commits the time needed to do it, it is in fact just another indicator that the person loves what they do. It is another way of determining if they love technology and solving business needs using it. I test for it, by asking what the person learned recently, and how. While rare these days, I prefer a person who takes deep dives and really learns the technology they are about to use. I ask what are their educational plan and how they plan to accomplish them. "I use stackoverflow, I search the web for answers, or ChatGPT" are typically warning signs. Good signs are: "I took a course, I followed a learning path X, I read a book". Frankly, it is getting harder and harder to find young developers who understand the benefit (and necessity) of taking deep dives. I verify their willingness to learn when they join the team, but more on that later.
In my experience only about 10% of interviewees meet my standards.
:: Step 2: Test New Hires Early
Within probation period (typically 3 months) I need to determine if my interview intuition were correct. My approach for this:
New hires receive a detailed, automated introduction covering our systems in depth, typically through video modules, most of which are produced ad hock via my documentation process. This minimizes disruption to the team, ensures the new hire has everything needed to understand the work, and is necessary for the whole process to run smoothly. They are allowed sufficient time to review everything at a comfortable pace.
I make myself accessible for any questions the new hire may have. The types and frequency of their questions can reveal a lot about their confidence and initiative, but mainly it is to make sure they have all the means of succeeding at the next step:
After orientation, new hires are throw into the deep end, so to speak, and asked to work on real, critical features, based on the technical knowledge they claimed to know at the interview. They are encouraged to ask questions anytime. This is the pivotal moment. I watch them carefully to see how they swim, how they get help, how they deal with fear and frustration of being in the deep end. I typically involve one more trusted person, to work with them closely, to be there to help answer questions. This is to help in the evaluation that is soon to come.
If I find that a hire has exaggerated their skills, we have a straightforward discussion. If they can’t convincingly explain themselves, they’re let go promptly.
Create a learning curriculum, covertly monitor progress
If the new hire manages to swim, they are introduced to the team's self-paced-education curriculum. It is a curriculum that I compile, based on courses, videos, books, exercises tuned to kind of work we do and beyond. A motivated person will do this on their own time, but I also allow them min 1 hour paid-time per day to study, during normal work hours. Progress on this, will help me determine if I was correct in my interview-time intuitions and conclusions. I do not force but encourage the study, as forced study would defeat the main purpose of the exercise. I ask for rating and small comment for each course / step of the study, as a means of covertly "tracking" progress.
It is a very significant warning sign if a person is not learning. If a person is doing well, and are focused on and draw a lot of satisfaction from success, I tend to overlook the lack of continuing education as they seem to know what it takes, but I will have a conversation about it with them.
If they are not doing well, and are not learning, they sometimes feel they need to work extra hours just to get their job done and put away learning for better days. I will encourage them to slow down and take the time to learn. If they still do not, this is usually a ticket home.
:: :: Evaluation
I am very lenient for the duration of the probation period. I try to steer a person if I feel they are on a wrong path, assuming for the time being that it is due to my misunderstanding or a miscommunication. I start to informally analyze successes and failures of the new hire with that other person I assigned to them. Why? To make sure I make fewer mistakes, misjudgments, keep my prejudices, if any, at bay, etc.
I work closely with the new hire helping them deal with any issues external or internal they maybe experiencing and for the first little while, give them a heck of a lot of the benefit of doubt. Why? because early on, it is very easy to misread a mistake as incompetence, misread intentions etc. Also, because iIt is so hard and expensive to find good developers, I rather take more risk on my best choices for the first few months, then lose a good one due to my own misjudgment.
:: #3 Quickly fire bad hires
Then, ideally before probably time is over, I make my final decision. Too often however, I did not trust my instinct to sever the relationship early. I kept the person longer that it was good for everyone. What I have learned - one of the worse things you can do for the team, the company, and the person in question, is to not let such a new hire go when you knew it was time. Usually, 3-6 months is when I know for sure.
It is not cruel to let bad people go, but it is cruel to everyone else, if you don't
No doubt this will sound crewel to some. I get why. Sounds like a soulless, capitalistic evil corporation. However, it is actually the right thing to do, for everyone. A corporation is not a charity, it is not day care, or social service center. A corporation needs to make money to survive and a lot more people depend on its survival then the one person who is not pulling their weight. Their failures will directly and negatively effect everyone else in the corporation if you do not let them go. Keeping someone who does not contribute will effect morale, will increase tension, will encourage good people to leave and will have a direct impact on bottom line, from which all bonuses and raises and security originates.
Lastly, it is good for the person being let go. It does not help a person to pretend that they are contributing at the right level. Letting them go, is either a wake up call they need, or a needed prompt to look for the kind of job, where they can fit well. Either way, the feelings of that person, unfortunately, has to be the last aspect in your decision. In fact, the biggest mistakes I have made, is where I did not let go of a person for exactly this reason. You are not a charity, keep that in mind. Unless ... you are a charity... but then ... recall who it is you are helping, or you might find that you are a charity for the relief workers themselves. One caveat. I will not let go a person who is in a dangerous psychological state, before I try to get them some help. But the inevitable would be just a matter of time.
In my experience, as much as I tried to improve my interviewing skills, I still find my self keeping just 1 out of 4 people I hire, for more than 1 year. About 30% of new hires don't make it past 3 months.
:: #0 Hire constantly
But what if you need this person, however inefficient they are?
That takes me to a hidden point #0 - hire constantly. Always have more people than you need, therefore you will pretty much have to be willing to hire constantly for a little while, as you build your time. Once the team stabilizes, it is good to always keep a larger staff than you really need, to be able to make difficult adjustments.