A lot of people think that the best developer is the brilliant person who can crank out tons of bug free code. That person who can sit by themselves, come up with amazing algorithms and solutions to problems, and then get all that code deployed and working.

In a lot of cases this is correct, and it definitely makes sense when you talk about a startup.  When I worked at a startup the idea was to just get as much product in front of the customer as possible, to have rapid iterations of feedback to get things working. If you talk to a lot of entrepreneurs you’ll see a lot of times the same concept, that it’s not who does it in the most brilliant and amazing way, but it’s about who can actually get things done and delivered.

But having worked in a couple of teams now, when you’re working with a typical two-pizza team of 5 to 7 people, that’s not necessarily the recipe for success. There’s a lot of soft factors at play, like how well does a person have culture fit, how well do they interact with other people, are they humble and accept criticism and ideas, are they a mentor other people, and so on and so forth.

If you look at all the soft skills I’ve listed above, you’ll notice something.

Being a good developer means being a good communicator.

What does this mean?

• Does your code have good comments?
• Does your code have nice clean interfaces defined that other systems can interact and integrate with?
• Is the code designed in a way that somebody else can read it and understand it?  To add functionality or fix a bug without too much trouble?

This is a whole different different aspect of the skills and experiences when looking for a good developer.  These are the kind of things you can ascertain by asking them to do some design work on the whiteboard. Can they describe their code with high-level block diagrams with defined interfaces?  Can they explain it well on the whiteboard, like a teacher? If they can’t explain a design or architecture on the whiteboard with boxes and lines, how will they ever be able to explain it to somebody else in written documentation or as part of a architecture design meeting?

I was thinking about this the other day, and I realized another important aspect that’s a lot simpler than that. It has nothing to do with raw technical ability, it has to do with discipline.  It has to do with attention to detail.

Being a good developer means attention to detail, even when it’s boring or not fun.

Let’s look at an example.

In a well-functioning software shop you’ve probably got a lot of cool things in place to make sure your code is high-quality. You’ve got an automated unit test suite, you’ve got a CI pipeline, you’ve got automated Doxygen documentation and architecture diagrams based upon all your comments, you’ve probably got a ticketing system like Jira or bugzilla that is managing your workflow and managing your sprints. Now, in order to integrate and work with all this process and framework, for the developer it really has very little to do with actually writing code. In fact, the process is there to ensure the code that is written is correct and high quality, i.e. tested for bugs and all that stuff.

But, all this only works if the developers are actually using the tools and processes.  They have to be working in the framework correctly. So it’s in a way it’s almost more important, not that they’re writing a brilliant solution to a problem, but they are writing automated unit tests, they’ve inserted good comments, their code is integrated into the CI pipeline so it is tested and automatically built and integrated.

I’ve found that this is where the big hassle comes into play. It’s people who, for whatever reason, maybe a lack of discipline, don’t do all this.  Instead they just slam together a bunch of code without any comments or without any automated unit tests.

It doesn’t matter how brilliant your code is, and it doesn’t matter how amazing your CI pipeline is, if none of it is actually working with it. So next time you’re looking for hiring a developer, make sure you are assessing a team member to see what their quality outfit and productivity is. Maybe focus less on whether they can think of a brilliant algorithm to some challenging problems, and instead see whether they seem to have the mindset to be able to have attention to detail, the discipline to work with and all those rules and processes, and the capacity to work well with your teammates.