Personality Traits of the Best Software Developers

I come from the world of corporate software development. It may not be the most glamorous side of software (it’s nowhere near as interesting as shrinkwrap startups or those fancy-dancy Web 2.0 companies that show up in your browser every time you mistype a domain name), but it’s stable, pays well, and has its own set of challenges that other types of software development know nothing about.

For example, when was the last time someone working on the next version of Halo spent three weeks trying to gather people from accounting, marketing, product management, and their call center in order to nail down requirements that would likely change in 2 months once they’ve delivered the software?

Or when was the last time someone at 37Signals sat through back to back weeks of JAD sessions?

In this world of corporate development I’ve known a few phenomenal developers. I’m talking about those A+ people whom you would quit your job for to go start a company. And the the more I looked at what makes them so good, the more I realized they all share a handful of personality traits. Well, not exactly a handful, more like four.


Admiral Jim Stockdale was the highest ranking US military officer imprisoned in Vietnam. He was held in the “Hanoi Hilton” and repeatedly tortured over 8 years. Stockdale told Jim Collins, author of Good to Great, “You must never confuse faith that you will prevail in the end, which you can never afford to lose, with the discipline to confront the most brutal facts of your current reality, whatever they might be.”

After his release, Stockdale became the first three-star officer in the history of the navy to wear both aviator wings and the Congressional Medal of Honor.

Stockdale was a pessimist in the short-term because he faced the brutal facts of his reality, but was an optimist in the long-term because of his confidence that he would prevail in the end.

No one anticipates a catastrophic system failure by looking on the bright side. The best developers I know are experts at finding points of failure. You’ll often hear them quipping “What could possibly go wrong?” after someone makes a suggestion to handle a critical data transfer via nightly FTP over a dial-up connection. The best developers anticipate headaches that other developers never think of, and do everything within their power to avoid them.

On the flip side, great developers are optimistic, even downright confident, about their overall success. They know that by being a pessimist in the short-term, their long-term success is ensured. Just like Jim Stockdale, they realize that by confronting the brutal facts of their current reality they will prevail in the end.

Angered By Sloppy Code
Paul Graham nailed it when he said “…people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent.”

The worst nightmare for a great developer is to see someone else’s software gasping for air while bringing the rest of the system to its knees. It’s downright infuriating. And this isn’t limited to code; it can be bad installation packages, sloppy deployments, or a misspelled column name.

Paris Sewers

Due to the life and death nature of their products, NASA designs zero-defect software systems using a process that has nearly eliminated the possibility for human error. They’ve added layer after layer of checks and balances that have resulted from years of finding mistakes and figuring out the best way to eliminate them. NASA is the poster child for discovering the source of a mistake and modifying their process to eliminate the possibility of that mistake ever happening again. And it works. A quote from this Fast Company article on NASA’s development process says

“What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.”

I’m not saying we have to develop to this standard, but NASA knows how to find and fix bugs, and the way they do it is to find the source of every problem.

Someone who fixes a problem but doesn’t take the time to find out what caused it is doomed to never become an expert in their field. Experience is not years on the job, it’s learning to recognize a problem before it occurs, which can only be done by knowing what causes it in the first place.

Developers who don’t take the time to find the source often create sloppy solutions. For hundreds of examples of sloppy solutions visit The Daily WTF. Here are a few I’ve seen in my career:

  • An assembly is deleted from a server each time it’s rebooted. You could create a custom script to re-copy that assembly to the server after each reboot, or find out why the assembly is being deleted in the first place.
  • An image-manipulation script is hogging processor power for minutes at a time when it should run in under 10 seconds. You could make the script run at 2am when no one will notice, or you can take the time to step through the code and figure out where the real problem is.
  • A shared XML file is being locked by a process, causing other processes to fail when they try to open it. You could make several copies of the XML file so each process has its own, or you could troubleshoot the file access code to find out why it’s locking the file.
  • And on and on…

Long Term Life Planners
This one was a little puzzling for the longest time, but I think I’ve finally put it together.


People who think many years down the road in their personal life have the gift to think down the road during development. Being able to see the impacts of present-day decisions is paramount to building great software. The best developers I know have stable family lives, save for retirement, own their own home, and eat an apple a day (ok, maybe not that last one). People who have spastic home-lives and live paycheck to paycheck can certainly be good developers, but what they lack in life they tend to lack in the office: the ability to be disciplined, and to develop and adhere to a long-term plan.

Attention to Detail
I’ve known smart developers who don’t pay attention to detail. The result is misspelled database columns, uncommented code, projects that aren’t checked into source control, software that’s not unit tested, unimplemented features, and so on. All of these can be easily dealt with if you’re building a Google mash-up or a five page website. But in corporate development each of these screw-ups is a death knell.

So I’ll say it very loud, but I promise I’ll only say it once:

I have never, ever, ever seen a great software developer who does not have amazing attention to detail.

I worked with a programmer back in school who forced anyone working with him to indent using two spaces instead of tabs. If you gave him code that didn’t use two spaces he would go through it line-by-line and replace your tabs with his spaces. While the value of tabs is not even a question, (I’ve long-chided him for this anal behavior) his attention to such a small detail has served him well in his many years designing chips at Intel.

So There You Have It
The next time you’re interviewing a potential developer, determine if she has the four personality traits I’ve listed above. Here are a few methods I’ve found useful:

  • Ask if they’re an optimist or a pessimist
  • Ask about a time when they found the source of a problem
  • Find out if they save for retirement (you can work this in during discussions of your company’s retirement plan)
  • Make an obvious misspelling in a short code sample and ask if they see anything wrong

We know from Facts and Fallacies of Software Engineering that the best programmers are up to 28 times better than the worst programmers, making them the best bargains in software. Take these four traits and go find a bargain (or better yet, make yourself into one).

If you liked this article you’ll also like my article Timeline and Risk: How to Piss off Your Software Developers.

Special thanks to Mike Taber for reading drafts of this article.

Start Small, Get Big
Growth Secrets for Self-Funded Startups. It'll Change Your Life.
What you get for signing up:
  • A 170-page ebook collecting my best startup articles from the past 5 years
  • Previously unpublished startup-related screencasts
  • Exclusive revenue-growing techniques I don't publish on this blog
"The ideas and information Rob provides should be required reading for anyone that wants to create a successful business on the web." ~ Jeff Lewis
Startups for the Rest of Us...
If you're trying to grow your startup you've come to the right place. I'm a serial web entrepreneur here to share what I've learned in my 11 years as a self-funded startup founder. Luckily several thousand people have decided to stick around and join the conversation.

For more on why you should read this blog, go here.


#1 ArtVandalay on 08.24.06 at 2:43 am

Thank you for sharing your experience! I personally think that your traits are all different facets of one characteristic: a software developer who isn’t blind to the reality of the problem to be solved. I elaborated on this a (little) bit more over on my blog.

#2 http:// on 08.24.06 at 9:57 am

So… your mate with the tabs certainly draws a lot of heat, doesn’t he? Do you think that “Seeing the real issue” is a trait of good programmers? 😉

#3 http:// on 08.24.06 at 7:56 pm

I understand a good programmer’s fixation with spacing, tabs, and trailing spaces. Programming is mentally taxing. You can really only be “on task” in short (say 20 minute) segments. Then you have to take a mental breath. The best programmers may take their “mental breath” by being fussy for awhile. Fussiness keeps you close to the task, while “off task”. You end up scanning the pattern of the code, while tidying up a bit. It eases you back into the flow. I often end up being “on task” again in places I didn’t expect. Actually, much better for continuity than heading for the coffee station or nearest gossip nook.

#4 http:// on 08.25.06 at 8:05 am

Pessimistic no, security thinking yes, pessimism is not creative enough, thus can get really annoying. Angered By Sloppy Code, stupid, anger shows you have lost control, educate the coder, strongly if necesary, but be wary of stupid conflicts over trivial style issues, if the coder can’t learn he should be set-up to be canned. Long Term Life Planners are a nice idea, but often futile given changing customer requirements and environment, better to make you and your code adaptable to allow flex with change. Attention to Detail yes, up to a point, but being anal can get tiresome fast and piss off a team. My suggestion is pragmatism and being able to quickly adapt to live issues e.g. by using plenty of error trapping, logging and use of (unpredictable) live data, where possible, instead of unit testing.

#5 Mehfuz Hossain on 08.25.06 at 3:47 pm

Nice blog, i liked the putting 2 spaces instead of tab” part greatly.

#6 http:// on 08.25.06 at 10:45 pm

I agree that attention to details is a vital characteristic of a great programmer and too often taken for granted. I work on a team that has no agreed upon coding standards. You can only imagine how messy some our code looks. BTW, I’d love to see a ban of the use of continue and break statements. I always clean those up when I see them. They disrupt the flow and readability of the code.

#7 http:// on 08.26.06 at 7:32 pm

Great read considering I meet all those traits. However, I would argue that a good developer does not need to be a good speller (which I am not). They do need attention to detail but that will not tell them if something is misspelled. As long as they consistently misspell something they can have the same attention to detail. I have always said that as long as it misspelled 100% of the time that’s just as good 🙂 Of course I do see the even better value of spelling correctly 🙂 P.S. Tabs should be killed!!! I can’t stand them in code. Except when required for makefiles.

#8 Basil Vandegriend on 08.28.06 at 1:01 pm

Great article! As another corporate software developer, I found myself agreeing with every point.

#9 Carsten Saager on 08.28.06 at 8:05 pm

Thanks for praising pessimism, I refer to myself a pessimistic optimist: “Everything will go wrong, but eventually we’ll succeed.” – Normally I earn irritated faces (at best) when saying this. You put in much better words. Also thank you for addressing the common misconception that sequences in short term success are equivalent to long term success. This applies to private as professional live.

#10 tim dugan on 08.31.06 at 7:24 pm

It’s an interesting point of view and I more or less understand the points made here. But, first off, I’m skeptical that these “Personality Traits of the Best Software Develpers” were arrived at in any scientific manner. I would find it more interesting if someone could find a more objective way to measure the best personality traits… Beyond that…”Software Developer” is an amorphous term. On any given team, there are people addressing different types of problems, ranging from architectural design, database design, GUI design, measuring performance, providing descriptions to document/help authors, debugging algorithms, working out interfaces, implementing domain-specific details, implementing operating system-specific details, configuration management, etc., etc., etc. Isn’t it very likely that different personality traits make different people better suited for different roles within software development?

#11 Paul Norrie on 09.01.06 at 5:34 am

I particularly agree with the attention to detail – I’ve noticed those that don’t, make sloppy incorrect commenting, don’t completely desk-check or test their routines before submitting them, etc. So, how do we test for this?

#12 rwalling on 09.01.06 at 6:13 am

Tim Dugan made some great points. First of all, although I try to back up most of my articles with some type of research-based data, “Personality Traits…” came purely from my own experience working with software developers with a wide range of abilities. Before I wrote this article I searched far and wide for a study of this nature, but did not find one. “Software Developer” is an amorphous term, but at the start of the article I narrowed it to corporate development. But one thing I can tell you (again, from my experience), that most of the roles you mentioned would be well-executed by someone with the traits I outlined. Additional traits may be needed, but these “four core” are an excellent foundation for any role in a software team.

#13 http:// on 09.01.06 at 3:12 pm

Some other traits that I’ve found to be prevalent in the best of the best: – insatiable curiosity (broadly-based, not just about programming or software), a lifetime learner. – habitual puzzle / problem solver (you put a puzzle (crossword, sudoku, wooden blocks that need to be put together to form a shape, rubik’s cube, etc.) down on the table in front of him/her, he/she can’t help but pick it up and solve it) – never satisfied with their own best efforts, always striving to do more, be better

#14 http:// on 09.09.06 at 11:37 pm

I use 3 spaces, no tabs, from C programming in the early 80s. I reformat code to get to know it, and to pace between bursts of new or revised code. And to make it look pretty (readable), unless it already was (someone else is going to read it when I’m gone). Pessimism, well, yes, initially, and I find that is often a way of pacing to the successful end, pacing and setting things up right in a world that often moves too fast. Go Slow And Win, my Uncle Bill always used to instruct his clients, and it really does work, if your client has the stamina for it.

#15 rwalling on 11.03.06 at 11:12 pm

In defense of my friend who would go through and remove tabs by hand, there were a few reasons he didn’t automate it: 1. We were in a college lab and the only editor available was really lame (was it the edit command in DOS? I don’t even remember). What I do remember is that there were no shortcuts or ways to automate this. 2. He also did it to keep from running into the most hated issue in C (especially without a debugger) – missing brackets. This saved our bacon more than once. 3. He was able to learn my code pretty well as he went through it. He had a better handle on our software than I did – that’s for sure. So although it was time consuming, given our constraints, it was a decent approach. Rob