The Qualities of Super-Star Software Developers

Find out what software developer qualities it takes to be a superstar.In a recent conversation with my hiring department, I really wanted to drill down to target exactly what qualities are super-star software developer qualities. After all, the faster we can recognize star potential, the faster we can cut to the end of the interview and make offers to top tier talent—which saves both sides of the process time and money.

Everyone’s concept of what is the best differs, but, in my years with the software development team at Patriot Software, I’ve noticed a few key software developer qualities that yield superstar-caliber accounting and payroll software.

Super-star developers deliver superior results when they are:


This is a somewhat elusive quality in analytical types. But developers need to be approachable enough that users feel that they can ask for help or request changes when the software is not delivering value or is broken in some way.

It fascinates me that some developers will go to great lengths to interface with a machine. Especially when that machine forces the developer to bend to all the idiosyncratic rules of its interface. And then those same developers won’t give other humans the time of day. (Maybe someone needs to publish a technical specification on how to interface with humans?)

Knowledge sharing is very important in software development. We can all appreciate the benefits of redundancy in systems. You never want a single developer to have all the knowledge about a key part of the system. A personable developer will be much more likely to let other developers into their world.


The benefits of dependability are hard to underestimate. It is too common in this industry for developers to write shoddy code and then move on to another opportunity or company so they don’t have to support that code. Let’s face it: as developers, the new code we are writing is always (let’s hope) better than code we wrote a year ago. Developers who are willing to stand behind their code are the real deal.

Another aspect of dependability is whether a developer can be counted on to get results in crunch time. When the chips are down, the server is on fire, and you are working long hours, is that person going to be there pulling alongside their teammates?


I fully explore empathy’s role in development in a separate post about software engineer personality traits.


I think curiosity is the initial spark that got most software developers into the field to begin with. Curiosity moves developers from users of technology to creators of technology. Whether it’s modding their favorite video game to give themselves unlimited lives, or spending hours looking at the HTML code behind their favorite website, curious developers have this deep desire to figure out how tech works.

Curiosity is what fuels software developer motivation and keeps them interested in new technologies and drives them to stock their tech toolbox. Through practice, they will keep those tools in good working order. Curiosity is what will nag a great developer when they notice something in the system that does not quite add up. They can’t rest until they understand what’s happening. I can’t count the number of times that I have seen this type of curiosity catch bugs, often before users were affected by them.


Developers who are confident in their code are rarely the best developers. Ignorance is bliss after all. If you feel all nice and fuzzy about your code then you probably are not in touch with reality. The confident coder pushes their code out to production without a care in the world and then leans back in their chair, cracks open another Mountain Dew, and waits for the accolades to roll in. The paranoid coder tests their code, uses test-driven development, writes automated tests to continuously run against their code, and then just as they are about to push the button to release their code, they get this nagging feeling that they should check it one more time.

I’ve heard it said that you need to inspect what you expect. It’s not enough that your code is awesome in your own mind; it’s not enough if your code is awesome when running on your own machine. If you want your code to be awesome in the real world then you need to be a little bit paranoid. Use that feeling of paranoia to put controls in place that will ensure that you are delivering awesome code in the real world.

Another place where paranoia is a good thing is with regard to security. If you ignore the fact that there are smart, persistent, professional hackers out there trying to break everything you create, then you will be victimized. Using encryption or password hashing algorithms is a start, but security is a constantly evolving battle that benefits from a healthy dose of paranoia.

Finding Super-Star Software Developer Qualities During Interviews

It can be difficult to detect the more human qualities in an interview when you only have a short time with the candidate. As much as we developers like to boil things down to formulas, a canned list of questions won’t get the job done. Asking “So, how patient are you?” won’t work because it will obviously clue the candidate in to the type of answer you want to hear. A lot of times, what people say they would do in a particular situation is a lot different from what they actually did in past situations.

I try to move the conversation past platitudes and get people talking about very specific past experiences and then ask more specific questions about those situations. These experiences bring out very human attributes, and how the candidate worked in teams will draw those traits to the surface. I want to know how candidates worked in past team settings. How did the team organize? What role did the candidate play on the team? Did they choose that role or was it assigned to them? How did the team divide the work? Hearing about how they dealt with a deadbeat teammate, for instance, can give a lot of insight. Did the team hold that person accountable? If so, which team member confronted them? If not, how did the team cope? Did they find other tasks that the slacker team member could handle? Did they say nothing and just do the extra work? Things like that.

When people start talking about how they acted in certain situations, it’s easier to see their personality traits manifest themselves. If they were frustrated with non-developers for not inherently understanding them like their machines do, that’s a big tell. If they talk about how they push out code fast, but their teammates can’t do their jobs to support them, they may be over-confident. If they gush about how fascinated they are about a new tech development, even one that doesn’t relate to their current job, it tells you they are curious.


, , , ,

Comments are closed.