When I first founded Devskiller four years ago, my team’s goal was to help companies find great programmers. Since then I had the opportunity to work with Fortune 500 companies, as well as smaller ones from all over the world. I spoke to technical people like CTOs, IT managers, team leaders, team members, and HR representatives responsible for finding and hiring top tech talent. They were all facing a universal problem: how to hire great programmers. In fact, it all starts with identifying a good developer when you see one, which brings us to the critical question: What are the qualities of a great software developer? There has been much discussion on the subject and as a start, I recommend you to read this amazing Quora thread packed full of insights from some serious industry masterminds.
However, based on our own experience, hundreds of talks and tens of pivots along our way, I feel we should chip in to the discussion. We’ve come up with a list of qualities which make great software developers… great.
Qualities of a great software developer
“Curiosity is, in great and generous minds, the first passion and the last” said Samuel Johnson and that is also true for programmers (and their great and generous minds). Let’s look for a more contemporary reference which develops Johnson’s point of view: Dan Pupius says that “curiosity is important throughout the life of an engineer” because it pushes you to learn new languages, experiment and look for new solutions, which is exactly what you want in an engineer. It also drives you to investigate architectural choices of others, as well as question assumptions. Pupius actually claims that a lot of qualities usually associated with great engineering “stem from a rich sense of curiosity” and I agree with him wholeheartedly.
Another great techie, John Allspaw, Chief Technology Officer at Etsy makes a good point in his post “On being a senior engineer”. He says that top notch developers are inquisitive and they tend to ask themselves and their peers the following questions while they work:
- “What could I be missing?”
- “How will this not work?”
- “Will you please shoot as many holes as possible into my thinking on this?”
- “Even if it’s technically sound, is it understandable enough for the rest of the organization to operate, troubleshoot, and extend it?”
I couldn’t agree more. Although at first glance it may seem that these questions are asked by a serial pessimist, that’s not actually the case. They are asked by an inquisitive individual with a passion to write elegant and self-consistent systems. Don’t mistake thoroughness for a “we’re all doomed” attitude.
Source: Campaign Brief
To quote Rahul Varshneya, Co-Founder of Appreneurship.Academy: “fine art and programing are similar in that great technical skills don’t make for a great artist or programmer”. Greatness doesn’t come from technical skills alone, but It would be unreasonable to expect exceptional results from people who simply don’t have the right skills for the job. You should think of skills as one of the elements of the puzzle which doesn’t really do much in isolation, but can do wonders when accompanied by other qualities. Luckily, the presence (or absence) of this particular puzzle is super easy to verify by means of coding tests.
Remember that knowledge of technical minutia is important, but if you come across a promising candidate exhibits all of the qualities listed in the article but is still learning, consider hiring them for a junior position. You’ll be surprised how far they can go.
Speed & productivity
A 1960s Sackman, Erikson, and Grant study entitled “Exploratory experimental studies comparing online and offline programming performance” discovered a 10-fold difference in productivity between programmers. The research is not without flaws – like other studies on the subject, it doesn’t “control for differences in individual capabilities”, it also combines results from users working in low level and high level programming languages.
Image source: Construx.com
As Steve McConnell argues, because research available on the subject is not free from limitations, it can’t be treated as conclusive but is definitely suggestive, and that’s how you should look at it.
From a practical point of view, in many cases salaries don’t reflect this order-of-magnitude differences between developers, which makes top developers underpaid and least productive of them overpaid. Is there a way to measure developer productivity and should you even attempt to do that?
Sadly, measuring developer productivity has eluded us so far, but we surely know that lines of code (SLOC, or Source Lines of Code) is not a measure which can be treated as synonymous to the value of the developer. As a matter of fact, less is more in the world of code (as long as it’s self-consistent and fully functional). According to Paul Haack, being able to provide concise, maintainable and understandable code is far more superior to punching volumes of code fast. Why? Think about what happens when you want to add new features or updates – it usually takes hours to decipher brittle code and find ways to patch it up, which comes with a steep price tag. Let me put it this way: what you save on a fast but uncareful developer, you end up spending on the QA team.
If you’re interested in productivity in IT, make sure to read “The myth of Developer Productivity” by Dustin Barnes.
Paul Haack says that best developers know when to code and when not to. ‘He argues that in some cases reinventing the wheel puts unnecessary strain on the project because you can use existing libraries to save time. Sounds logical, but doing everything from scratch it’s still one of the biggest time thieves.
Awareness also manifests itself through risk tolerance threshold. This is crucial because often you need to refactor live systems, which is where things can go terribly wrong. Being able to realistically assess the risk without the ego getting in the way is a hallmark of an exceptional programmer.
As Varshneya argues, while some devs struggle to come up with a solution, it comes naturally to others, “as if an epiphany hits them at the moment they sit to create programs or solve a problem”.
Great software developers understand algorithms and architectures intuitively and this ability allows them to learn quickly. Which brings us to the next quality: the love of learning.
Love of learning
According to John Krystynak, “genuine commitment to continuous learning” is one of the essential qualities of a good developer. As Krystynak rightly argues, “you have to love the fundamental practice of going from not knowing to knowing, every single day” otherwise you won’t be good at it.
This holds especially true in the world of IT. While it’s useful to have your way of doing things, it’s essential you venture out of what you know and find new (perhaps faster) ways of getting things done. One of the ways to do that is by noticing patterns and drawing conclusions quickly.
There are great many ways to develop when you’re a developer (pun intended), including:
- Attending industry events, such as conferences and hackathons (which Thomas So of AppLovin calls “job readiness training)”,
- Finding a mentor,
- Working on a side project,
- Asking for peer feedback.
The IT world is changing rapidly and as a developer you need to stay adaptable. For that reason, it’s a safe bet to hire people who are always on the lookout for new tools and ways of doing things, follow industry news and simply care about the craft.
The more you know, also outside of your preferred technology, the more of an asset you are to both your team and the entire organization. As Marius Mazilu, Full Stack Technical Lead at 3Pillar Global claims, “diversity of technology has become so widespread that being a specialist in one particular technology is not necessarily a guaranteed success track.” Mazilu believes being more versatile is critical because mature technologies are more stable and cannot keep up, which means your skillset becomes outdated very quickly. On the other hand, he believes that novel frameworks typically require a massive time investment because they are unstable which means “you may be shocked to discover one day that they do not love you back”.
Mazilu has 7 simple rules you should follow to keep up with the technology:
- Trust gut feeling,
- Always go back to the basics,
- Watch out for the silver bullets (technologies being widely used because they are well-marketed and not because they fit the project),
- Learn to debug,
- Learn to script,
- Don’t get obsessed with what your code looks like,
- Go with the crowd.
A positive attitude
A positive attitude is one of the key qualities of a great software developer. Programmers solve problems day in and day out, but that doesn’t mean they should dwell on them. A “getting sh*t done” attitude is much needed, partially because tasks and tickets tend to pile up. It’s important to decide when it’s time to push a good enough solution out the door and move on to the next thing on the list. The caveat here would be to not flood your developers with more tasks than they can handle and keep things realistic.
In the Quora thread I’ve mentioned before, Damien Filiatrault, Founder of Scalable Path actually puts “positive attitude” on the top of his list of essential qualities possessed by good developers. He says you can test the waters and ask a few seemingly simple “small talk” type questions to see if the responses given focus on the positives or negatives. These questions include:
- “Do you consider yourself lucky? (cocky or humble)
- How was your commute to the interview? (complainer or no worries)”
John Krystynak says that “great programmers don’t become great in isolation“ and I salute him for saying that. One of the reasons why the mentorship model works so well in IT is because some developers learn most efficiently by apprenticeship. It simply takes less time to figure things out if you can watch a more seasoned colleague at work. Another reason why top techies advocate mentorship is because it requires you to expose both your strengths and weaknesses, which in turn teaches you volumes about keeping your ego in check.
One of the best things you can do as an employer to foster that kind of attitude in your organization is to pair seasoned programmers with freshmen. You might think that this will most likely put a strain on the mentor who is already most likely beyond busy, but bear in mind that both the mentee and the mentor learn from that arrangement. If you can’t explain something to your mentee it means you don’t really understand it well enough, or can’t communicate it well enough. This means there are learning opportunities for both parties in this relationship.
In his Quora answer to the already mentioned thread, Damien Filiatrault states that “good communication skills directly correlate with good development skills.” Here’s why:
- You need to know what questions to ask when you don’t understand or need to double-check,
- It’s possible for you to figure things out based on communication with colleagues without having to rely on written specifications,
- Concepts are typically understood and communicated quickly in a team of successful developers,
- It’s possible for great programmers to communicate cogently with both technical and non-technical staff.
It’s becoming increasingly difficult to find excellent programmers because the tech industry is going through a talent scarcity situation. This means we need more developers that we can possibly find, and companies are going out of their ways to attract top tech talent:
My final word of advice is to act fast when you come across a promising candidate because in the scarcity situation recruiters fight over the same candidates.
What are the qualities of a great software developer? Looking forward to hearing your thoughts!