Some characteristics of the best developers I worked with

I had a conversation last November on the PyConEs, when I was on a conversation stating that I am working with truly brilliant people in DemonWare, and then someone asked me: “Do you have problems agreeing in  what to do? Normally great developers have problems reaching consensus on tech discussions”. My answer something like: “Well, in my experience, truly awesome developers know when to have a strong argument and they usually are ok reaching an agreement in a reasonable time”.

So, I wanted to, as sort of follow-up, summarise what are the characteristics that I’ve seen in the best developers I’ve been lucky to work with. This is not a list I am making on “what’s my ideal developer”, but more a reflexion on the common traits I’ve seen on my experience…

    • Awesome developers are obviously smart, but that’s not typically shown as bursts of brilliance, solving really difficult issues with “aha!” moments. In my experience, genius ideas are rarely required nor expressed (though they surely happen once in a blue moon). Instead, great developers are consistently smart. They present solutions to problems that are reasonable all the time. They find and fix typical bugs with ease. They struggle with very difficult problems, but are able to deal with them. They are able to quickly present something that will make you say “Actually that’s a nice point. Why didn’t I think about this?”. They do not typically present something ingenious and never heard of, but deliver perfectly fine working ideas over and over, one day after another.  Their code is not full of mind blowing concepts, but it is logical, clean and easy to follow most the time (and when’s not, there is a good reason). They are able to remove complexity and simplify stuff, to a degree that it almost look easy (but it’s not)
Normally brilliant people on real life do not come with crazy great ideas out of nowhere

Brilliant people on real life do not come with insanely great ideas out of nowhere

  • They keep a lot of relevant information on their minds. They are able to relate something that is in discussion with something that happened three months ago. They seem to have the extraordinary ability of getting out of the hat some weird knowledge that is applicable to the current problem.
  • While they have a passion for coding, it is not the only thing in their lives. They have hobbies and interests, and they don’t usually go home in the weekends to keep working on open source all day, though they may occasionally do.
  • They love to do things “the right way”, but even more than that, they love to make things work. This means that they will use tools they consider inferior to achieve something if it’s the best/most convenient way. They’ll complain and will try to change it, but deliver will be more important that being right. They have strong opinions about what language/framework/way of doing stuff is best, being that Python, Ruby, Haskell, PostgreSQL, Riak or COBOL, but that won’t stop them knowing when it’s important to just stop arguing and do it.
  • They are humble. They are confident most of the times, but far from arrogant. My impression is that they don’t think that they are as awesome as they truly are. They will want to learn from everyone else, and ask when they have questions. They will also catch new ideas very fast. They are also friendly and nice.
  • Communication is among their best skills. They are very good communications, especially, but not limited, about tech issues. They may be a little social awkward sometimes (though this is not as common as stereotypes portrait), but when they have the motivation to express some idea, they’ll do it very clearly.
  • In some of the truly remarkable cases, they’ll be able to fulfil different roles, when needed. I mean different roles in the most broad sense, basically being able to be what’s needed for that particular moment. Sometimes they’ll have to be leaders, sometimes they’ll be ok being led. They’ll know when a joke is the proper thing to do and when to remain formal. They’ll be the person that helps you with a difficult technical question, or the one that will tell you “you’re tired, just go home and tomorrow it will be another day”
  • And they’ll have a great sense of humour. I know that almost everyone thinks that they have a good sense of humour. That’s not totally true.

Again, this is sort of a personal collection of traits based in my experience and on what I consider the best developers I’ve been honoured to work with. Any ideas?

11 Comments on “Some characteristics of the best developers I worked with

      • So you don’t agree that it’s navel gazing then? The one thing worse than working with a jaded curmudgeon is working with world-class, best-in-their-field, passionate, guru rockstars, who are also 23-year-old recent graduates.

      • Just to clarify, I am far from having 23 years (I’m 36 years old), and most of the people that I refer about in this post are not in their 20s (though there has been a few young people that have impressed me), most of them are older or around the same age than me…

        I only talk about my personal experience. I think that I work (and have worked previously) with very talented people. Are they among the best of the world? Well, I’m not sure. But they are far from being the “guru rockstars” kind

  1. Reblogged this on NeverFriday and commented:
    I don’t see thinking or analyzing or writing really well or being able to use formal methods or understanding more than the basics of computer science theory. Too bad.

  2. I think you’ve made some great points – what you’ve basically described is a team player.

    Looking at the comments that others have made, they seem to under value the point you’ve made regarding how hard (i.e. simple) day to day work often is as a programmer. Truly complex problems seldom come about. I also think you’ve hit the nail on the head about making complex things look simple.

    Rudolf’s list is a given for anyone you should be working with – what your post is about is the best people to work with and it also lies on a spectrum – otherwise how would anyone ever learn? I’ve known people who know their technical stuff really well, but can’t actually build anything or can’t work with other people. The irony is that the formal “science” of software is most important on larger projects where you NEED a team because most customers don’t want to wait 30 years for their system.

  3. Pingback: Links – January 2014 | Ninad's Blog

  4. Pingback: Let your fellow developers know they’re great | Wrong Side of Memphis

  5. Pingback: The amazing forgiveness of software | Wrong Side of Memphis

Leave a comment