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.

Chess

Pessimistic
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.

Guitar

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.

65 comments ↓

#1 http:// on 08.21.06 at 10:04 am

I find it hard to believe that one of your examples of a “best software developer” was someone who would manually go through each line of code to convert tabs to spaces…

#2 TC on 08.21.06 at 10:12 am

That is one great article. I totally concur with the benefits of being pessimstic in the short term. There are enough folks out there already, who just “assume it will work”. They need to be balanced by folks who *don’t* assume it will work, but instead, actually think it through from a critical viewpoint. But the problem is, to carry this off successfully! If you’re not careful, management starts to perceive you as a negative influence. (“He always disagrees with new ideas!”) So in my opinion, you need to tread carefully, depending on the type of person to whom you report :-) Again, a really good article IMHO.

#3 TC on 08.21.06 at 10:21 am

Damien: one of my own quibbles is unnecessary trailing spaces on source-code lines. I always get rid of them without exception. Some time ago, some code that I had written, stopped working. The owner of the code swore blind, that it had not been changed. As soon as I looked at it, I knew that it had. But how could I convince him of that? The answer: all of the new source lines had trailing spaces. I easily showed him that none of my other code had trailing spaces – at all – anywhere. He soon admitted that someone else had worked on it!

#4 http:// on 08.21.06 at 11:16 am

TC: Moral of the story: use revision control. ;p By the way, I do set my editor to show trailing whitespace so that I can also “fix” that. However, manually changing every line of a file to expand tabs is just… silly.

#5 http:// on 08.21.06 at 11:31 am

I agree with your proposition that the best developers are pessimistic in the short term. But I have also noticed that great developers are also extremely hostile to pessimism from others that is uninformed. For example, a manager might say that something is “hard” without much understanding of the code internals. This kind of uninformed pessimism is another example of scorn for those who don’t pay attention to details, etc.

#6 http:// on 08.21.06 at 1:41 pm

N.B. “jided” isn’t a word. Perhaps you meant “chided”?

#7 Patrick Fitzgerald on 08.21.06 at 2:53 pm

Thanks for this great article! One small grammar problem though: “learning to recognize a problem before they occur” change to “learning to recognize problems before they occur”

#8 http:// on 08.21.06 at 3:16 pm

These characteristics are definitely true – and apply just as much in the startup world. I’d add: ability to concentrate, and good old raw intelligence.

#9 http:// on 08.21.06 at 4:00 pm

“However, manually changing every line of a file to expand tabs is just… silly.” Right, just use global search and replace. Using tabs in source files makes baby Jesus cry.

#10 rwalling on 08.21.06 at 4:39 pm

Thanks Michael and Patrick for your grammar corrections – I’ve updated the article appropriately.

#11 rwalling on 08.21.06 at 4:45 pm

In response to Damien’s comment: “I find it hard to believe that one of your examples of a ‘best software developer’ was someone who would manually go through each line of code to convert tabs to spaces… ” I was not agreeing with this friend’s approach to software development, only pointing out that he has the personality trait of “attention to detail.” This particular trait has served him well in his career, although I assure you his “2 space” mentality has long passed into extinction (thankfully for all of us). Rob

#12 http:// on 08.21.06 at 5:41 pm

I can see your point about paying attention to detail, I just think it’s a bad example for a programmer. It’s not the fact that he was obsessed about having 2-space indentations, it’s his method of fixing his “problem” which to me screams “non-programmer”. Even if he didn’t use a decent editor (Emacs for example) or had never heard of the expand command (http://www.gnu.org/software/coreutils/manual/html_mono/coreutils.html#expand-invocation), a programmer should realize that something so simple and repetitive is easily automated and would be a waste of time to do manually. Good article otherwise though, I don’t mean to be a pain in the ass about it. ;p

#13 http:// on 08.21.06 at 8:23 pm

I have always used 2 spaces instead of tabs too, (unless the editor allows the tab button to use two spaces) :) And if the language is not case sensitive I capitalize the first letter of reserved words like “If” instead of “if” (just looks nicer to me) For trailing spaces, I use a tool to kill white space at the end of lines or without thinking (Shift + End, Del, Enter). Doesn’t really take more time because it’s all habit, (infact I am often faster because of it)

#14 http:// on 08.21.06 at 8:54 pm

I have been developing software for 12 years. I have worked with well over 100 software developers over the years. There are only 5 developers I know of who don’t suck. Most software developers write SHIT and SLOPPY code and don’t have the first clue as to how to design an enterprise object model. The truth hurts.

#15 http:// on 08.21.06 at 10:10 pm

You really must be kidding. While these are some characteristics of decent coders, great coders, in my opinion, need to try different ways of doing things. Attention to detail is a prerequisite for doing work in the software industry. To be great, you must understand the many different design patterns that can be used, and then select the best one… Another trait missing is excellent communication skills.

#16 http:// on 08.22.06 at 1:52 am

I think you missed one – Tenacity. Good developers are always running into seemingly insoluble problems but they refuse to give up. They have the basic attitude that “there’s always an angle, we just gotta find it”, as they reframe the problem and attack from a different angle.

#17 http:// on 08.22.06 at 2:01 am

great article, although you misrepresent console game programming as “playing games all day” – or at least thats how I read the phrase: “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?” In my experience knowing in advance that requirements would change 2 months in the future sounds like stability! I can assure you the level of team dependency (multidisciplinary teams > 100 becoming the norm), technology risk, applied R & D, etc. makes corporate development look like a risk-less, purely political cakewalk. Of course, I suppose anyone’s job seems easier than the one you know well!

#18 Tomasz Wegrzanowski on 08.22.06 at 2:49 am

Come on, how can someone who manually corrects indentation be described as even a good programmer. Every programmer who is at least semi-competent knows how to indent automatically using a Perl one-liner or some indent program :-)

#19 Jonathan Watmough on 08.22.06 at 3:43 am

I seriously gratified that I meet all those points. I knew I was doing something right. Talking about the 2 spaces guy: I re-indent SQL, manually, and these are some big-ass SQL statements. It sounds crazy, but it’s like parsing it into my brain. It helps 1) to have nicely formatted SQL, and 2) to have already read it over once. There’s an interview in Susan Lammers book where a LucasArts guy talks about how everytime something gets faster, something else is lost. Case in point, when waiting for a sound fx tape to spool, you could be thinking about levels to apply, now the spooling is ‘instant’. That time to think is gone.

#20 http:// on 08.22.06 at 3:51 am

This doesn’t seem to fully jive w/ currently popular principles like XP, unit testing, YAGNI, rolling/anticipating change etc. For my programming dollar, I’d prefer a pragmatic programmer. Some traits: – Ability to role w/ change, – Ability to communicate and get along w/ customers as well as peers, – Intense drive to learn, – Desire to work w/ the newest technology, – Ability to think outside the box, (not for the sake of being different, or reinventing the wheel, but to solve problems that have not been addressed before!), – focus on maximizing project ROI

#21 http:// on 08.22.06 at 4:22 am

No, they are not pessimistic! They are, however, sceptical (and optimistic). The phrase “Hope for the best, but plan for the worst” tend to describe how they think…

#22 Michael Economy on 08.22.06 at 4:33 am

omg they just described me!

#23 simran on 08.22.06 at 4:55 am

I think the article refers to “a good type of software developer” … there are PLENTY of them out there that do not care about retirement plans etc. What is important is what is important and that is: * Ability to think outside the “box” (hacker attitude) * Good documentation skills * Excellent attention to detail * Good methodology and consistent process * Flexibility (esp. in the area of having a process for each type of, small, medium, large projects – without compromise on quality) And i think in an interview you should ask them what you really need to know and see examples… trying to “infer” if they are good developers by asking irrelevant questions about savings is just that… irrelevant!

#24 http:// on 08.22.06 at 5:02 am

1) All corporate code needs to be reviewed. This means that when you check your code in, it will be seen by someone else. You’ll be confronted if your code is sloppy. Period. In fact, the better your manager, the better your code will be. 2) Corporate programmers usually work on teams. Some person’s potential might never get reached on his or her own, but in a group this person can shine. If they are stumbling, then maybe they need to find another team where they fit in better. 3) Sure there are some weaker programmers in a corporate world, but because things are so competitive and fast paced, the weaker ones will remain at the bottom working on crappy projects. If they’re getting ahead and you’re not, then you need to either A) see if you’re the weaker programmer, or B) see if your management is just crappy. 4) Engineering by its very nature is a painstakingly meticulous type of industry. You have to be precise, or things do not work. Software Engineering is no different. If you’re not a meticulous person, then engineering is probably not for you. Just like physics in college is never about memorizing equations, its about being methodical in solving problems. 5) Creativity is also a huge bonus. The more creative you can be in your coding and your ideas for making things the best they can be, the better off the project will be. 6) ALSO, ABOVE ALL ELSE!!!!…. A Corporate programmer is one who can communicate with others. You will be asked to give presentations, write documents, and explain, explain, explain your code X number of times before it goes live. The most articulate of the engineers will advance.

#25 http:// on 08.22.06 at 5:12 am

It’s a nice article, but you paint the best developers as basically those who follow the rules taught in school. Sorry, but the devil *is* in the details. The best developers I’ve worked with have always a nak for understanding the big picture, and actually **caring about the big picture**, i.e. the goal and success of the software delivered. Guess what? Windows started out like the code you described, but poor engineering decisions, and then handing engineered code to folks who didn’t care about it ended up with what we see today. People lost the big pic and lost interest NASA writes decent code cause it has the time. For most of us, i.e. 7-10 yrs for a science mission, unfortunately a luxury we don’t have (and safeguarding bank records are just as important as flying 1 million miles in space, think about it), considering most projects are 8months to operational prototype stages. SEI level 5 folks predicted it takes 3months for 1 line of code to get into a operational baseline. I can agree on short term pessimism, but that applies to a lot more fields that s/w development. As for long term retirement? That’s a bit of a stretch. Remember, most big-company coding efforts are about complex problems using the K.I.S.S. methodology, period. Structured coding in a production line manner makes a lot of sense for ulitmate reliablility & reusability. In the end, there’s a common set of traits, but no set of specifics as this article suggests. The best developers are ones who put the right code in the right place for the right purpose.

#26 http:// on 08.22.06 at 5:52 am

Generally agree. Funny thing is, operators are often leapfrog’ed to supervise/manage developers. The rhetoric is usually: “Just because they can’t do this doesn’t mean that they can’t do that.” So those who don’t know what to do or how to do it end up making decisions, and evaluating developers. Makes sense.

#27 http:// on 08.22.06 at 6:46 am

I am winding up a gig with a developer with most of the traits you mentioned who topedoed a project despite a year and a half of time to work on it. His pessimism made him distrust the client to the point of paranoia. He constantly revisited coding standards (tabs vs. spaces, naming of variables, and so on) when discussing software engineering problems. His long term planning paralyzed him against making short term gains; rather than solve the problem at hand he was always worried about solving the problems that might arise in the future. His obsession with learning every nuance of a language before using it prevented him from adopting tools that would have been better suited for getting the job done. He is considered a senior software developer, and was hired precisely because he exhibited the qualities you listed above. I was one of the people who made that decision, and it has haunted me. Of the qualities you list above I would add that you need to have a person who isn’t afraid to take risks, and who is willing to make mistakes and learn from them. It is that quality that has defined the success my own work has seen over the last year (I will likely continue in my position as my work has started to bring in more contract dollars, whily my co-worker is agonizing over what his next career step will be). My willingness to explore new territory (sometimes at the expense of code quality) forced me to understand new problems and find solutions for them.

#28 http:// on 08.22.06 at 8:05 am

I would go through your school friend’s code line-by-line replacing spaces with tabs. He and I would be the worst pair programmers in the world.

#29 http:// on 08.22.06 at 12:24 pm

Sheeesh. I wouldn’t want to pay mr. anal to replace tabs with spaces… (A good developer, with the same neurotic tendencies, would have automated the process.)

#30 Matt on 08.22.06 at 1:17 pm

I believe that the guy that replaced tabs with two spaces had the advantage of re-reading the projects’ code before going to work. I find it easier to understand someone else’s code by reading and reciting it. As far as I can tell, details are the most important part of our job too. When working with a team you must agree on some standards so it will be easier for everyone.

#31 IB on 08.22.06 at 1:26 pm

I see a lot of people commenting, that chaning tabs to spaces was going overboard. The truth of the matter is it depends on your compiler. The COBOL compiler I used in the Mid 1980’s could not differentiate between space and tabs. Your code could look the same on the monitor but you would get a compiler error. This was true for compilers on UNIX and on DOS. My friends using FORTRAN had similar issues with using too many spaces or too little spaces. The TAB keyword was reserved in our company for wordprocessing not programming . At one time we even had programming keyboards with the tab key missing. Compilers and linkers are much more forgiving now.

#32 http:// on 08.22.06 at 1:31 pm

From the comments it looked to me like half the people were mocking the line-by-line replacements of tabs to spaces (which I too think is a ridiculous waste of time) while the other half mocked doing it altogether (which in my opinion is a good idea). One simple regular expression which replaces “\t” with ” ” (ignoring quotes) is run against all of my projects. That way when I’m searching the project from that point forward I know I can look for space and not tabs, tabs and spaces, or some other mixture thereof. Consistency in coding is a great thing. Now can we get to the real problem? Unnecessary space at the end of a line!!! (Concidentally, “[\t ]+$” with “”) Where would I be without regular expressions? I shudder to think…

#33 Detlef D. Doerscheln on 08.22.06 at 1:57 pm

This is really a great article. You wrote: “But in corporate development each of these these screw-ups is a death knell.” Shouldn’t this be: “But in corporate development each of these screw-ups is a death knell.” Two options I guess. My language skills are as bad as I always thought they are or I am too detail oriented.

#34 http:// on 08.22.06 at 2:00 pm

Not surprising, though maybe interesting, but I find that I disagree with everyone who commented with misspelled words. Or focused solely on one point, one that they failed to see the point of. Attention to detail.

#35 http:// on 08.22.06 at 3:56 pm

I think one thing you missed is the ability to prioritize efficiently. Most people get caught up in the idea of seeing the _whole_ problem before them, and for many people – that’s a very daunting thing to look at. Truly great programmers (and successful people everywhere) have learned to simply attack the most pressing item first, then the next, and so on. They might not get through the entire problem space – but they’ll get a lot farther than someone who sits there and stares at the whole problem for days trying to solve it all at once.

#36 http:// on 08.22.06 at 4:31 pm

I know I am looking at the code of great coder when the code is simple and well documented. The best always assume that someone with less ability will at some point be asked to modify it, test it or re-use it. The programmers who try to code everything in a single line and use obscure compiler knowledge are the ones that are at the bottom of the pile. They know code but they don’t understand software development.

#37 http:// on 08.22.06 at 4:36 pm

OK, making someone point out a spelling error in code is just cruel. Think about it. Do you really want to hire someone who has the audacity to point out a spelling error to their *interviewer* whom they have *just met*? Do you want them pointing out misspellings in a customer’s requirements document? As someone with pretty good spelling, I have learned through the years that pointing out misspellings does nobody any favors unless they specifically ask for the input. It mostly just belittles them for a mistake that most people wouldn’t have noticed anyway. So, please nobody take that particular piece of Rob’s advice. You will find that you’ll be favoring the rude programmers, not the great ones.

#38 David Seruyange on 08.22.06 at 4:36 pm

I wonder how NASA’s perfection relates to that whole Mars Rover incident. Don’t get me wrong; the kids at CalTech and JPL are amazing, but it’s human to err.

#39 Tom on 08.22.06 at 5:48 pm

Thanks for the great article! At the end of it you wrote: “Take these four traits and go find a bargain (or better yet, make yourself into one).” Though I believe you have to be somewhat predisposed to these traits, what, other than coding and debugging and reading and studying and developing yourself in as many ways as possible, do you think is an efficient and effective way to develop them? Perhaps you can address this in a follow-up article?

#40 Thom Allen on 08.22.06 at 6:18 pm

Loved the post. Couldn’t agree more. I need to work on a lot of those attributes myself.

#41 Stuart Muckley on 08.22.06 at 6:51 pm

My personal experience in development agrees with most of your points, but, I think you’ve slightly missed with “Attention to Detail”. I’ve had the privilege of working with a dozen or so really good programmers and one thing above all has always been common: an obsessive behaviour pattern. The example of your colleague who meticulously corrects bad-indenting is a good example. My own experiences have shown myriad examples including obsessive laying out of paper, pens and other stationary (including the monitor, keyboard, and mouse) in exact positions on the desk (every 10 minutes). Many have had trouble in anything but small groups, and shied away from “unnecessary” social interaction. I believe “Attention to Detail” is a consequence of the obsession. Of course, all this comment is based on anecdotal evidence (much like the above :) ) so it shouldn’t be taken as scientific fact. Still, it would be interesting to find out via a large study group.

#42 http:// on 08.22.06 at 7:26 pm

Nice article! I got tired of getting derided for my pessimism at my last stint by the likes of “yes” people, whom I percieved as having little talent for anything more than taking up space and efficent exchangers of CO2 with plants. Guess I feel somewhat vindicated, but truth is few recognize this as a desireable attribute. More than once I’ve heard, “you sounded apprehensive at first, but delivered in the end.” Gee, and thanks. And yes, always look deeper at a problem when you can. I’ve found countless bugs that way, some of them my own. Programmers in general, I think, need attention to detail. Probably there are differing levels that make a big difference. Persaverance (did I spell that right?) is always an admirable trait in my book, along with the willingness and ability to always take it one step further than others might. Thanks again!

#43 http:// on 08.22.06 at 8:04 pm

This is the kind of complete and utter nonsense I have been hearing again and again for years. First off, pessimism leads to failure – it is a self-fulfilling prophecy. I hate whiny programmers. Have you ever considered what a waste of time replacing tabs with two spaces is? And why on earth would he go through it “line by line”? Can’t he automate this – or try a Find – Replace with a text editor? Your buddy should be shot – not held up as an example! Hack and slash coders are the best – they’ll smoke any of your pansy buddies any day on any project of any size. You anal-retentive types spend ten times as much time that’s needed to get the job done because you place too much attention on unnecessary detail. As for NASA, how many of their shuttles have blown up and how many astronauts have died in recent years? I can’t believe NASA is still being held up as a model for everyone to follow. NASA has admitted it no longer has the capabilities to land on the moon. How’s that for source control? NASA lost all the knowledge to do so and are at least 10 years away from being able to do it again. Morons! Intel? Aren’t they getting smoked by AMD? It’s not that Intel doesn’t have enough anal-retentive robotic geeks – it’s because they fell behind in the battle of vision, creativity and ideas – qualities which you forgot to mention. Long term life planners? Is this about creating software or buying Mutual Funds? It’s completely irrelevant. It has nothing to do with good programming. The best programmers are the ones who are smarter than the others. They are driven by an overriding passion to be the best. They have strong personalities and a youthful energy that inspires others. They might forget to comment their code or check it in to source control from time to time, but they possess qualities which are much more important than the ones you have listed.

#44 http:// on 08.22.06 at 10:37 pm

It’s fairly typical that those who feel that they don’t fit the criteria discussed in an article like this would end up posting a rather heated response in an attempt to make themselves feel better. Such a shame. For what it’s worth, I enjoyed reading this – and that is regardless of whether I have any or all of the above traits. I think that for the most part you have hit the nail on the head. Cheers.

#45 Coopz on 08.22.06 at 11:01 pm

I think there could be one important factor you have forgotten, for I cannot function in my role as a programmer without……caffeine!! Every good programmer I have EVER known has been a caffeine junky.

#46 http:// on 08.23.06 at 12:08 am

I have met 4 such people. They all fit the profile apart from one distinction. They are not pessimists they are sceptics. Sceptics do not accept recieved wisdom, they challenge all assumptions and are generally untrusting of ‘the hype’. This can easily be confused with pessimism. 28 times better? One guy was easily 128 times better!

#47 http:// on 08.23.06 at 3:54 pm

Right on! Incompetence runneth rampant. I often ask folks on my team, “Is this your best work?” If the answer is not a resounding, “YES,” I quite frankly wish the developer would just go home. Quit. Save us all the hassle. I want to ask them, “If you don’t have pride in your work, why are you even here?!” I have little tolerance for sloppy code, short-sighted “solutions,” and people that are coding for any reason other than a love of doing so and doing it well.

#48 http:// on 08.23.06 at 4:27 pm

I haven’t read your article, but in my experience in recruiting and building software development teams it the size of the project that matters and what it calls for. For instance, if you have a large project that requires requirements gathering to implmenentation and you have a large budget, then you need people who know their roles specifically. Architects, Managers, Hammer and nails peeple. Pretty simple. In this conceptual world, getting away from this is what creates chaos. If it’s a smaller project that requires all these roles, higher an abstract thinker that can complete every role. Keep in mind, you must let them do their work because they are “Artists”. My 2 cents. I used to profile individuals by their thinking style and match it up to roles within a software development life cycle. Robin

#49 http:// on 08.23.06 at 7:37 pm

I think a lot of people misunderstand the bit about first changing all the indentation. Some of us have the mental trait that misspellings, inconsistent/foreign indentation and other odd artifacts in the code can be so distracting as to make it very difficult to focus on the underlying algorithm being expressed. I often find myself “normalizing” code formatting as a first step when I have to do any significant amount of maintenance or enhancement. For those of you whose brains aren’t wired this way, imagine someone talking to you while they’re picking their nose and scratching their privates. Pretty hard to concentrate on what they’re saying… I think its a mistake to assume that this particular mental trait is necessarily either helpful or detrimental to being a great programmer. I’ve met both great and lousy developers that were this way. I can only speak for myself and say that I (humbly) consider myself to be in the “great programmer” category, and this anal-retentive tendency of mine has been more of a blessing than a handicap in my 25+ year career.

#50 http:// on 08.23.06 at 10:24 pm

It is a great post Rob, but i would tend to challenge it. The most talented developers i worked with had one common quality: – The ability to keep things simple. You don’t realize until you start asking them how they would do something. I have often been so humiliated by the simplicity of the solutions of others that i now always ask myself if i am not missing a simpler solution. The KISS principle is really key: Keep It Simple, but not Simpler (Einstein). – Being pessimistic, i agree. The one thing i would have are the usual suspects: SPOFs: Single Point Of Failures. These are really problematic as major software catastrophes have SPOFs, starting with the Windows screens of death caused usually by a SPOF (read faulty driver). – I’d trade anger by sloppy code by anger by sloppy architecture. The best developers have seen so many code smells in their lifetime that we are no longer agressed by them. Code smells are often fixes at relatively lost cost. Faulty architectures are… well… very painful to fix. – Long term planning is true, but above all, the best of us have a vision of our the system should be. Not that much how they should be coded, but more how they should be architected. Each of us can place different concepts at a different place in the list, but to spot a good developer, i am looking for an exchange. The last guy i contributed in hiring had a fundamental disagreement with me over the user of the visitor design pattern. That’s precidely why we hired him: Because he had convictions.

#51 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.

#52 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? ;)

#53 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.

#54 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.

#55 Mehfuz Hossain on 08.25.06 at 3:47 pm

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

#56 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.

#57 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.

#58 Basil Vandegriend on 08.28.06 at 1:01 pm

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

#59 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.

#60 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?

#61 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?

#62 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.

#63 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

#64 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.

#65 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