What makes a great developer?

I’ve been thinking recently about the variation in the field of software developers and what properties we can ascribe to those who we might call great. This comes from a desire to continuously improve as a professional software developer, having an idea of what makes someone great gives me a set of attributes to aspire to.

A naive interpretation would be that a great developer writes a lot of code but I find this to be flawed. Lines of code is a terrible metric, it penalises more effective solutions to many problems. So perhaps measuring on features delivered is more appropriate. However I believe that there is more to being a great developer than simply measuring productivity.

Integrity

Hopefully self-explanatory.

The ability and courage to admits to mistakes

I’m a big believer in engendering trust through honesty. Everyone makes mistakes, I’m more likely to have confidence in someone who can acknowledge this and be upfront about their errors than someone who dissembles, denies, or shifts the blame for their failings.

Committed to continuous learning

I’ve been know to say (repeatedly and at length) that if you can look at code you wrote six months ago and not find anything that causes you to recoil in horror then you have stopped improving and need to find an alternate profession. Software development is both a constantly changing field and has a large body of existing knowledge. A large part of being a professional software developer rather than an amateur hack is continuous improvement to deliver clients improved value.

Able to accept the ideas of others

No one can know everything and no one is right all the time, regardless of what your ego may tell you. To be a great developer is to be able to take the best ideas regardless of source and form from them the solution that gives most value to the client.

Able to improve a team and its members

Beyond simply being able to work in a team environment a great developer should be a positive influence above and beyond their own individual work. This includes providing assistance and mentoring to other team members as well as continuous improvement to the structure and practices of development.

Knowledge of patterns

Design Patterns are in my opinion the most effective reuse mechanism currently available in software development because they reuse knowledge rather than implementation. This gives them applicability to many problem domains and allows their use across multiple platforms.

This is my initial list of things to aspire to but I’m sure there are more. On the off chance anyone ever reads this, add your criteria below.

Tuesday, March 31, 2009 11:39 PM

Your Comments.

# re: What makes a great developer?

ah Yes Colin! So what's not to agree. Of course as senior people we must set the lead here too - difficult when the universe is frequently wrong! Wouldnt you agree?

but with regards to design patterns, I have one concern - In any team, some will know established design patterns intimately and others won't. Some will rely on their own knowledge and experience, yet others need the GoF book. In my view, most design patterns are too complex and/or overkill.
Also, all the GoF did was to enumerate patterns that have worked in the industry - but GoF is neither exhaustive nor complete and never will be... see: http://hillside.net/patterns/papers/7habits.html. They are, I believe, fashionable - a new interview question even. Now dont get me wrong, I'm not against knowing patterns, it's a must, I just dont think they should receive the weight they do, the way they do.

they are no more or less important than, say, good coding principles and as such do not belong in your list above.

In fact I'm surprised you didnt' add TDD above! :-)

Left by John Coppola at 4/1/2009 10:41 AM

# re: What makes a great developer?

OK, in some kind of order:

- Patterns are targetted at particular scenarios and outside these scenarios are indeed complex and/or overkill. The Design Patterns books and all subsequent pattern references I've seen spend a lot of space on describing both the advantages and disadvantages of the patterns. Understanding the scenarios where patterns do not apply is just as if not more important than understanding where they do.

- GoF is not complete and makes no claims to be. I linked to it because I had a link handy and because it is a very good starting point. There are many other subsequent works addressing particular domains and further patterns are being identified. There's always room to learn more.

- I think pattern knowledge is a valid question in an interview, but not in a traditional "what is the singleton pattern?" kind of way. I'd be looking for understanding of patterns and their tradeoffs rather than a rote recitation of their structure.

- The list isn't complete, lucky we have you to add to it :)

Left by Colin Scott at 4/1/2009 12:34 PM

# re: What makes a great developer?

Well of course your response is absolutely correct, but it rarely comes without prodding. I just think it adds an unnecessary pressure on younger, up and coming developers to, as you say, learn by rote, rather than think for themselves.

And speaking of adding to your list, here's one: "Displays a pragmatic attitude" - One should provide the ideal technical solution, suited to the the client and their budget and their long term strategy. Too often developers do what they think is correct, effectively adding their own technical non-functional requirements into the equation. Such an attitude would also temper their view of patterns! :-)

Left by John Coppola at 4/2/2009 11:36 AM

# re: What makes a great developer?

My previous post (www.abstractcode.com/.../156.aspx) described my attitude on being expedient, which passes for pragmatism far too often.

Patterns are important because they're a good way for moving knowledge about. In saying that it's important to understand that the pattern is much more than the class structure prototype. The discussion of the pros and cons is critical and needs to be understood. Otherwise pattern use does reduce to rote application and that's never a good thing.

I'm against over-engineering but I've even more strongly against under-engineering. You can simplify an over-engineered implementation. You can't improve the design of a big ball of mud in a cost effective manner.

And frankly I think up-and-comers need more pressure. The number of people who allege that they're developers but produce unmaintainable crap is far too high. This has a direct cost to business and to the ability to those who succeed them to work with their applications. I have no sympathy whatsoever for people who refuse to learn the skills and practices relevant to their profession.

Left by Colin Scott at 4/2/2009 11:52 AM

# re: What makes a great developer?

being 'more' against under engineering, as opposed to overengineering tells me you are not pragmatic, at least in the true sense. Not that its' a bad thing and knowing you the bit that I do, leads me to think to you would find it difficult to do a less than perfect job (in your eyes at least). Secondly patterns is not the answer to better programmers - mentoring is - if up and comers produce crap code it's because their not being mentored properly, either through the blind leading the blind or due to pressure to learn stuff they dont 'practically' need in their daya to day job, except for when they go for an interview!

So again, I will reiterate, there's nothing wrong with patterns, but when promoted on their own as the be all, end all answer to crap software, then that's a mistake. Thats why I agree with all your points about what makes a good developer, except 'knowledge of patterns' :-)

Left by John Coppola at 4/2/2009 9:52 PM

# re: What makes a great developer?

I getting the feeling we're arguing in circles. :-)

It's not about a perfect job, it's about a maintainable system. I will take the upfront cost for the lower overall cost in almost all cases, and in the exceptions I'll know Technical Debt has been incurred. Sometimes this is necessary for deadlines, in others because the perfect solution is simply not cost effective. However I believe from everything I have encountered that defaulting to good practices is the best approach.

I'd prefer over-engineering because it's easier to collapse into a more appropriate architecture than it is to take a big ball of mud and apply an architecture to it. I don't agree that under-engineering is in any way pragmatic. A true pragmatic approach needs to consider the lifetime of the project and over time lack of design means high costs and large bug counts.

I'm going to keep knowledge of patterns firmly where it is. Because it's not application of patterns, that's a subset. I've been in situations where upon encountering a pattern my knowledge of it's strengths and weaknesses allowed me to (pretty much instantly) recognise that it was inappropriate and should be removed. Patterns are abused; their application must be justified. But you cannot build a system of any decent size and complexity without patterns and expect it to turn out maintainable.

One of the nice things about TDD is that you basically get the best of both worlds. You do the simplest thing that will work. Then if that's the best solution in context you leave it, otherwise you refactor.

Mentoring is good, it should happen more. Developers also need to learn to find knowledge themselves. Luckily we have this interblag thing for that.

I suggest that we continue this with pistols around mid-afternoonish (I'm not a dawn kind of guy).

Left by Colin Scott at 4/2/2009 10:43 PM

# re: What makes a great developer?

I will admit to having over-engineered in the past. I'm getting much better at recognising that though. And we do seem to learn best through failure.

Left by Colin Scott at 4/2/2009 10:47 PM

# re: What makes a great developer?
ah Yes Colin! So what's not to agree. Of course as senior people we must set the lead here too - difficult when the universe is frequently wrong! Wouldnt you agree?

but with regards to design patterns, I have one concern - In any team, some will know established design patterns intimately and others won't. Some will rely on their own knowledge and experience, yet others need the GoF book. In my view, most design patterns are too complex and/or overkill.
Also, all the GoF did was to enumerate patterns that have worked in the industry - but GoF is neither exhaustive nor complete and never will be... see: http://hillside.net/patterns/papers/7habits.html. They are, I believe, fashionable - a new interview question even. Now dont get me wrong, I'm not against knowing patterns, it's a must, I just dont think they should receive the weight they do, the way they do.

they are no more or less important than, say, good coding principles and as such do not belong in your list above.

In fact I'm surprised you didnt' add TDD above! :-)

Left by John Coppola at 4/1/2009 10:41 AM
# re: What makes a great developer?
OK, in some kind of order:

- Patterns are targetted at particular scenarios and outside these scenarios are indeed complex and/or overkill. The Design Patterns books and all subsequent pattern references I've seen spend a lot of space on describing both the advantages and disadvantages of the patterns. Understanding the scenarios where patterns do not apply is just as if not more important than understanding where they do.

- GoF is not complete and makes no claims to be. I linked to it because I had a link handy and because it is a very good starting point. There are many other subsequent works addressing particular domains and further patterns are being identified. There's always room to learn more.

- I think pattern knowledge is a valid question in an interview, but not in a traditional "what is the singleton pattern?" kind of way. I'd be looking for understanding of patterns and their tradeoffs rather than a rote recitation of their structure.

- The list isn't complete, lucky we have you to add to it :)

Left by Colin Scott at 4/1/2009 12:34 PM
# re: What makes a great developer?
Well of course your response is absolutely correct, but it rarely comes without prodding. I just think it adds an unnecessary pressure on younger, up and coming developers to, as you say, learn by rote, rather than think for themselves.

And speaking of adding to your list, here's one: "Displays a pragmatic attitude" - One should provide the ideal technical solution, suited to the the client and their budget and their long term strategy. Too often developers do what they think is correct, effectively adding their own technical non-functional requirements into the equation. Such an attitude would also temper their view of patterns! :-)

Left by John Coppola at 4/2/2009 11:36 AM
# re: What makes a great developer?
My previous post (www.abstractcode.com/.../156.aspx) described my attitude on being expedient, which passes for pragmatism far too often.

Patterns are important because they're a good way for moving knowledge about. In saying that it's important to understand that the pattern is much more than the class structure prototype. The discussion of the pros and cons is critical and needs to be understood. Otherwise pattern use does reduce to rote application and that's never a good thing.

I'm against over-engineering but I've even more strongly against under-engineering. You can simplify an over-engineered implementation. You can't improve the design of a big ball of mud in a cost effective manner.

And frankly I think up-and-comers need more pressure. The number of people who allege that they're developers but produce unmaintainable crap is far too high. This has a direct cost to business and to the ability to those who succeed them to work with their applications. I have no sympathy whatsoever for people who refuse to learn the skills and practices relevant to their profession.

Left by Colin Scott at 4/2/2009 11:52 AM
# re: What makes a great developer?
being 'more' against under engineering, as opposed to overengineering tells me you are not pragmatic, at least in the true sense. Not that its' a bad thing and knowing you the bit that I do, leads me to think to you would find it difficult to do a less than perfect job (in your eyes at least). Secondly patterns is not the answer to better programmers - mentoring is - if up and comers produce crap code it's because their not being mentored properly, either through the blind leading the blind or due to pressure to learn stuff they dont 'practically' need in their daya to day job, except for when they go for an interview!

So again, I will reiterate, there's nothing wrong with patterns, but when promoted on their own as the be all, end all answer to crap software, then that's a mistake. Thats why I agree with all your points about what makes a good developer, except 'knowledge of patterns' :-)

Left by John Coppola at 4/2/2009 9:52 PM
# re: What makes a great developer?
I getting the feeling we're arguing in circles. :-)

It's not about a perfect job, it's about a maintainable system. I will take the upfront cost for the lower overall cost in almost all cases, and in the exceptions I'll know Technical Debt has been incurred. Sometimes this is necessary for deadlines, in others because the perfect solution is simply not cost effective. However I believe from everything I have encountered that defaulting to good practices is the best approach.

I'd prefer over-engineering because it's easier to collapse into a more appropriate architecture than it is to take a big ball of mud and apply an architecture to it. I don't agree that under-engineering is in any way pragmatic. A true pragmatic approach needs to consider the lifetime of the project and over time lack of design means high costs and large bug counts.

I'm going to keep knowledge of patterns firmly where it is. Because it's not application of patterns, that's a subset. I've been in situations where upon encountering a pattern my knowledge of it's strengths and weaknesses allowed me to (pretty much instantly) recognise that it was inappropriate and should be removed. Patterns are abused; their application must be justified. But you cannot build a system of any decent size and complexity without patterns and expect it to turn out maintainable.

One of the nice things about TDD is that you basically get the best of both worlds. You do the simplest thing that will work. Then if that's the best solution in context you leave it, otherwise you refactor.

Mentoring is good, it should happen more. Developers also need to learn to find knowledge themselves. Luckily we have this interblag thing for that.

I suggest that we continue this with pistols around mid-afternoonish (I'm not a dawn kind of guy).

Left by Colin Scott at 4/2/2009 10:43 PM
# re: What makes a great developer?
I will admit to having over-engineered in the past. I'm getting much better at recognising that though. And we do seem to learn best through failure.

Left by Colin Scott at 4/2/2009 10:47 PM

Jump Menu

So what are all these buttons for?

Personalize

Text Size

Layout

Navigation Position

AbstractCode

Code too abstract to instantiate

What makes a great developer?

Your Comments.

Archives

Post Categories

Syndicate