What makes a good developer?

"What makes a good developer?" This is a question that I was once asked in an interview. It is a pretty open-ended question, and I gave an answer that ticked off various software development best practises, but it made me wonder whether there was one basic characteristic that I could have identified. The thought interested me because the answer could be used to inform the larger development process, as in 'is this characteristic helped or hindered by this particular development practise?'

In my opinion, the primary characteristic that makes a good developer is that they add value. A developer can contribute to the team and the product in multiple ways. It could be obvious, such as being productive and implementing features in a timely manner and with minimal defects, or it could be a less tangible contribution. The contribution of some developers can be less about new features and bug fixes but rather more about improving the overall productivity of the team through code refactoring, mentoring, and improving the team's tooling and process automation. They might also be very good at avoiding coding at all, in that they are knowledgeable about services and tools that can be used instead of writing code from scratch.

Productivity is an important part of adding value. Ultimately, developers create; we work in a creative industry. We create new software, we create new features, we create fixes for bugs, and we create refactored versions of existing code. However, I would never encourage blind productivity by individual developers, nor the assessment of developers by the number of lines of code they write. In my opinion productivity needs to be: robust, sustainable, and about the team as well as the individual. Ultimately it is about the environment and processes around the whole team, and how those help or hinder the team's individual and collective productivity.

Robustness comes from various development processes, such as automated testing, CI, CD, code reviews, and refactoring to improve the codebase over time. It is also about effective planning before and during development.

Sustainability is important for the long-term health of the development team. Working many long days is a fast-track to burnout. The team also need to feel involved in the decision-making process, and that their work is valued.

Regarding the productivity of the team as a whole, developers being productive on their own without regard to others might result in short-term gains but it is unlikely to be successful in the long term.

It is worth noting that some companies only value naked productivity; management has no interest in how development proceeds, just that there is software to ship. I briefly worked in such an environment, on a large and complex Web app that had zero automated testing. The software would be hacked on up to a point near the delivery date, and then management would throw contractors at it to do manual testing and fix as many bugs as possible in the time left.

Ultimately, management and the teams themselves need to ensure that the processes and practises adopted enhance rather than limit the ability of their staff to add value. Developers, designers, analysts and testers are all roles that are expensive to hire for and it makes sense to help them be as productive as they can be.