JustPaste.it

Better Programming By Programming Better

Jeff Atwood writes a great post on how to become a better programmer by not programming. For the most part, I totally agree with his premise that to become a better programmer, you need to...

Learn about your users. Learn about the industry. Learn about your business.

Understanding the big picture is absolutely essential to being a good developer. Especially when you’re in the 99th percentile. The effort to get to 99.5th is very great and provides diminishing margins of return.

However, most developers are not in the 99th or even 90th percentile (by definition), and thus still have room for improvement in programming ability, along with the important skills just mentioned.

I am not convinced by the idea that developers are either born with it or they are not. Where’s the empirical evidence to suport these types of claims? Can a programmer move from say the 50th to 90th percentile?

Jeff points out that study after study shows there is no relationship between a programmer’s amount of experience and code quality or productivity. I don’t doubt that for a second. I’ve worked with developers who have 10, 15, 20 years in the industry and couldn’t code a virtual rat through a maze consisting of two parallel lines.

But recent research points out that the belief in innate talent is “lacking in hard evidence to substantiate it” as well. I wrote about this topic recently in my post, The Question Of Innate Talent.

So how do I reconcile these seemingly contradictory statements?

Well going back to the Scientific America article, The Expert Mind, we get a clue.

Ericsson argues that what matters is not experience per se but “effortful study,” which entails continually tackling challenges that lie just beyond one’s competence. That is why it is possible for enthusiasts to spend tens of thousands of hours playing chess or golf or a musical instrument without ever advancing beyond the amateur level and why a properly trained student can overtake them in a relatively short time. It is interesting to note that time spent playing chess, even in tournaments, appears to contribute less than such study to a player’s progress; the main training value of such games is to point up weaknesses for future study.

So what we learn from this research is that experience does not matter to a person’s performance. Exactly what the studies cited by Atwood support. However, what does have an impact is effortful study.

Effortful study

This makes a ton of sense to me. Typically, experience in any field, especially software development, often means solving similar problems over and over again using the same techniques as before. There is no way this contributes to being a better programmer.

Sure an experienced developer had to learn new technologies to stay relevant, but if the experienced developer applies the new technologies in the same way over and over again, the developer has not improved.

I’m currently looking at some legacy C# code written in a procedural style. The developer can write C# code, but hasn’t taken the time to learn to recognize when object oriented patterns would help solve a problem more elegantly. Thus his experience has not made him a better programmer.

However, with focused effortful study and training, a programmer can lift him or herself out of mediocrity. Its not by programming more one gets better, but by programming better. Even better is to program more better (as in more often and better).

Keep in mind though, that this takes nothing away from Atwood’s main point. My point is that most developers (by definition) are not in the 90th percentile, at which point there is diminishing margins of return for effortful study. Most developers still have room for improvement in their coding skills as well as the ever important tangential skills to which Atwood refers.

In fact, I believe that for many developers, the tangential skills will distinguish and increase the value of a developer faster than improving programming skills. But don’t toss out that book on Design Patterns just yet.

 

Source: Phil Haack

License: Creative Commons