Comments on: Personality Traits of the Best Software Developers

By: rwalling

rwalling — Fri, 03 Nov 2006 23:12:26 +0000

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

By: http://

http:// — Sat, 09 Sep 2006 23:37:36 +0000

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.

By: http://

http:// — Fri, 01 Sep 2006 15:12:15 +0000

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

By: rwalling

rwalling — Fri, 01 Sep 2006 06:13:35 +0000

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.

By: Paul Norrie

Paul Norrie — Fri, 01 Sep 2006 05:34:19 +0000

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?

By: tim dugan

tim dugan — Thu, 31 Aug 2006 19:24:13 +0000

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?

By: Carsten Saager

Carsten Saager — Mon, 28 Aug 2006 20:05:59 +0000

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.

By: Basil Vandegriend

Basil Vandegriend — Mon, 28 Aug 2006 13:01:44 +0000

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

By: http://

http:// — Sat, 26 Aug 2006 19:32:39 +0000

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.

By: http://

http:// — Fri, 25 Aug 2006 22:45:21 +0000

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.

By: Mehfuz Hossain

Mehfuz Hossain — Fri, 25 Aug 2006 15:47:14 +0000

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

By: http://

http:// — Fri, 25 Aug 2006 08:05:20 +0000

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.

By: http://

http:// — Thu, 24 Aug 2006 19:56:55 +0000

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.

By: http://

http:// — Thu, 24 Aug 2006 09:57:45 +0000

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?

By: ArtVandalay

ArtVandalay — Thu, 24 Aug 2006 02:43:16 +0000

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.

By: http://

http:// — Wed, 23 Aug 2006 22:24:02 +0000

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.

By: http://

http:// — Wed, 23 Aug 2006 19:37:27 +0000

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.

By: http://

http:// — Wed, 23 Aug 2006 16:27:44 +0000

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

By: http://

http:// — Wed, 23 Aug 2006 15:54:50 +0000

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.

By: http://

http:// — Wed, 23 Aug 2006 00:08:57 +0000

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!