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.

[ad] Free Bug Tracking & Project Management Software Axosoft’s OnTime 2007 allows software development teams to collaborate on software projects by tracking everything from defects to enhancements to helpdesk incidents in one easy-to-use database driven by an intuitive Windows, Web or VS.NET Integrated UI. Get a Free Single-User License ($200 Value!)

What others have said

Requesting Gravatar... Steve Jackson Jan 30, 2007 1:28 PM
# re: Better Programming By Programming Better
Good points. Shame on me for assuming I was even in the 80th percentile. I can't even work my way around simple lisp without an amusement park map.

Requesting Gravatar... Rob Conery Jan 30, 2007 1:38 PM
# re: Better Programming By Programming Better
Interesting posts (yours and Jeff's), and I think the topic really is far more massive than a few studies and the definition of a percentile. What makes one better than the other anyway? Lack of errors? Fewer lines of code? Better logging and exception handling? Scalability?

I would argue that if you asked Mr. Tech and Mr. Business what they thought about their programmer - you would get some vastly different opinions on the concept of a "better programmer".

I'm the perfect example of this paradox - some of my clients think I walk on water; developers I've worked with think I'm the hack of the century :).

Maybe it's time to put this altogether into some quantifiable measure - how about the "Haack Index"?

"Dude, what's your Haack?"

"Wow, that guy has a SICK Haack."

"Phil Haack just published his new site - 'Are you Haack or Not?'"

Requesting Gravatar... Scott Jan 30, 2007 3:43 PM
# re: Better Programming By Programming Better
The biggest problem is, no one can quantify what constitutes "good" or "excellent" code or programmers. Is this code good or bad?

/*
* If the new process paused because it was
* swapped out, set the stack level to the last call
* to savu(u_ssav). This means that the return
* which is executed immediately after the call to aretu
* actually returns from the last routine which did
* the savu.
*
* You are not expected to understand this.
*/
if(rp->p_flag&SSWAP) {
rp->p_flag =& ~SSWAP;
aretu(u.u_ssav);
}
/*
* The value returned here has many subtle implications.
* See the newproc comments.
*/
return(1);

http://www.google.com/codesearch?hl=en&q=+file:/usr/sys/ken/slp.c+%22You+are+not+expected+to+understand+this.%22+show:Ljj4gw8sDcU:LpqPd8QofXc:rZ61TsK1o2o&sa=N&cd=1&ct=rc&cs_p=http://pdos.csail.mit.edu/6.828/2003/6828sw.tar.gz&cs_f=6.828/v6/usr/sys/ken/slp.c#a0

Is it possible for a mediocre programmer to have a flash of insight and product excellent code on certain project? Can the best programmers in the world make mistakes from time to time? What if you want to write good code, but your platform has a bug or quirk that requires you to write hackey workarounds? (IMO, 90% of all code is workarounds in the framework.).

Until you can quantify code, you can't say one programmer is better or worse than the other. It's like art. "I may not know much about art, but I know what I like."
Requesting Gravatar... Haacked Jan 30, 2007 4:04 PM
# re: Better Programming By Programming Better
> Until you can quantify code, you can't say
> one programmer is better or worse than the other.

Really? But you do it all the time, don't you? Have you ever had to lay off or fire a developer?

People generally think of John Carmack and Linus Torvalds as being great coders. If you can't say one programmer is better than another, why hold these developers in high esteem? Why does Google claim to hire the best developers, when they could just hire anyone off the street, if what you say is true?

Sure, it is impossible to create some sort of metric for developer aptitude (You have a score of 9321 and I have a score of 9322 so I'm better than you.) That will never happen.

However, I think it is possible to say one developer is better or worse than another in a specific context, when you realize that such a statement comes with a margin of error.

Some developers are so far apart from others, that the margin of error is easily overcome. For example, if developer A beats developer B in all measures of productivity and code quality, couldn't we say that developer A is a better developer than developer B?

In my book, a good programmer gets things done in a timely manner and makes his clients/customers happy.

Does this mean a good developer writes maintainable code? Yes, otherwise when the developer has to maintain the code, he/she can't get things done quickly.

Does this mean a good developer is a good problem solver? Well yeah!

Does this mean a good developer writes high performance code? Well yes, if that's the thing that needs to get done.
Requesting Gravatar... Rob Conery Jan 30, 2007 4:19 PM
# re: Better Programming By Programming Better
Your Haack score just dropped by 10...
Requesting Gravatar... Haacked Jan 30, 2007 4:40 PM
# re: Better Programming By Programming Better
> Your Haack score just dropped by 10...

plus or minus 20, right?
Requesting Gravatar... Joe Brinkman Jan 30, 2007 5:50 PM
# re: Better Programming By Programming Better
I think to a large degree your programming skills are determined by factors that are not programming specific. While effortful study can improve your skills, not everyone has the drive necessary to put in the effort. Even with effortful study your programming skills will ultimately be capped by your analytical and logic skills. Similar to the fact that not everyone can wrap their minds around quantum physics, military tactics and strategy, or even linguistic skills, not everyone will be able to understand how to break down a problem into its constituent components that allow you to visualize the solution.

I also agree with you Phil, that some programmers are definitely better than others, and it doesn't take a genius to be able to determine that fact. That is not to say that you can specifically quantify a programmer's skill, but it is possible to determine that some programmers fall somewhere in the 90th+ percentile range and others are in the bottom quartile, and if you don't think so then maybe you fall into the latter group rather than the former ;-).
Requesting Gravatar... John Jan 31, 2007 7:11 AM
# re: Better Programming By Programming Better
I suspect the really good programmers don't have a lot of time to write books or blog about percentiles or quantification. Too busy being productive so their kids can eat. I've hired and fired quite a few of you "head in the clouds" programmers.
Requesting Gravatar... Haacked Jan 31, 2007 8:47 AM
# re: Better Programming By Programming Better
I doubt that. If really good developers are so productive, they should definitely have time to engage in outside interests apart from working all the time just to make ends meet and keep the kids fed.
Requesting Gravatar... Brandon Jan 31, 2007 9:21 AM
# re: Better Programming By Programming Better
Actually I would say that the "Great Programmers" probably are more of the people who have time to write blogs and books. If you think about it if you measure a developer by productivity then a good developer would have projects done faster then others and might encounter idle time where he/she might want to share some of their knowledge with others. As for the "head in the clouds" developers those are usually the people that will come up with the great idea, because they are always trying to think about doing things out of the ordinary.
# Being a Better Programmer
There's a flurry of great posts and comment discussions going on right now about the divide between good
Requesting Gravatar... Justin's Blog Jan 31, 2007 11:59 AM
# The Programming Divide
Requesting Gravatar... Don Jan 31, 2007 1:57 PM
# re: Better Programming By Programming Better
I am just amazed that so many lines have been written about good and bad programmers without even mentioning "class".

Just doesn't feel like a technical discussion.

Cheers.
Requesting Gravatar... James Taylor Jan 31, 2007 2:38 PM
# re: Better Programming By Programming Better
While I think there are "problems" with programmers or at least with our expectations of them, I do think that most people don't want to write code , and could not if they wanted to. The fundamental problem is that programmers and business users have a different perspective that makes it hard for them to collaborate. Yelling at programmers won't help.
JT
Requesting Gravatar... thecancerus Jan 31, 2007 9:23 PM
# re: Better Programming By Programming Better
ability to think and passion are only differentials between two programmers. any one can code... if can't code sure as hell can copy paste someone else work.

this has nothing to do with programming itself. can you think logically? can you see beyond the specification in front of you to realize what will actually help person get his task done easily. i agree with jeff when he says you become better programmer by understanding the big picture.

you mentioned Linus Torvalds as example, is he a great programmer because he wrote a piece of code which others had already working for them(their were os's before linux)? No, he is considered great because he made it public, provided others a chance to contribute and hack OS of their dreams. Above all he made it work successfully, any one will respect him for that. he understood the big picture, has great ability to think and he is passionate about programming.

now let's take this issue of percentile, you know all the functions available in a programming language(let's take java as example ;) ), you know all the correct syntax, nifty language features, you will still produce crap, may be good crap because language forces you to follow good practices. while you don't know most of these details and you can produce good code... after all what are documentations are for, earlier MIT hackers are their to prove this(refer hackers by steven lee).

i don't know everything a language has to offer but when i have a problem to solve then i look into documentation to understand how i can solve it.
Requesting Gravatar... Ayende @ Blog Jan 31, 2007 10:38 PM
# Can you learn to program better?
Requesting Gravatar... Brad B Feb 01, 2007 7:32 AM
# re: Better Programming By Programming Better
In the early 1990's, I was probably 30 or 40 percentile. I was just starting to learn to code, and there were not many programmers, and they were good.

In the late 90's, I was probably 99th percentile, as I got a lot better, and demand for programmers flooded the market with new 'programmers' looking to find money or just find a job.

When the bubble burst, I probably moved down a few percentile, as many programmers, mostly those who came for high salaries or easy employment, moved on to other fields.

None of this matters. No one cares what percentile I am in.

The effort to get from 99th to 99.5th is very great (assuming the talent of other programmers does not change), but this does not mean it provides diminishing margins of return. One thing proven time and time again is there is a huge difference between really great programmers and above average. Who cares if a ton of effort only moves you up a small fraction of percentile, when at the same time, your productivity and quality improves greately?
Requesting Gravatar... Haacked Feb 01, 2007 8:31 AM
# re: Better Programming By Programming Better
@Brad, I'm starting to regret using the term "percentile". I meant that in the abstract.

Let's use chess as an analogy. When you are an average player, you have tons of room for improvement. But when you are a grandmaster, you start to reach the limit of how much you can improve. You can train harder and harder, but you only improve by inches, rather than leaps and bounds.

That's all I meant by "diminishing margins of return". Another way to look at it, is you still have to keep working at it just to maintain your level. That's why it's hard to improve upon a four minute mile, but easy to improve on an eight minute mile.
Requesting Gravatar... Paul Davis Feb 03, 2007 8:41 AM
# re: Better Programming By Programming Better
This topic is one we often discuss at work.
At one level, I think it comes down to motivation. The best developers I know, actually spend time trying to become better. They write code at home, they try new things, they study best practices and design patterns. Their skill is independent of formal education.

One issue may be, the schools don't really know how to teach programming yet. Sure they can give you the syntax, mechanics, and theory but, actual coding takes something else.

Currently "effortful study" in programming is only happening on the individual level. This has led many of us to theorize that the best way to go forward is through apprenticeship programs. But, even that is no silver bullet (who and how do you pick the masters to take apprentices?).
Requesting Gravatar... Christopher Steen Feb 04, 2007 9:15 PM
# Link Listing - February 4, 2007
Refactor!T for ASP.NET - Free Download [Via: dhayden ] Prototype 1.5 Documentation in PDF [Via: Dion...
# What it takes to become a great developer
Requesting Gravatar... Michael Ramirez Feb 12, 2007 12:57 PM
# re: Better Programming By Programming Better
What are programmers but problem solvers. How do we separate the good from the great is in how they solved the problem. So we should be talking about what makes a good solution vs a great solution. I think a great solution should be fast,flexible,and easy to maintain. So a good programmer might create an application that is very fast but that nobody can understand or expand on. Great programmers can find the balance :)
Requesting Gravatar... Tom Anderson Sep 04, 2007 7:02 AM
# Where’s the empirical evidence to suport these types of claims?
You said you're not convinced by the idea that developers are either born with it or they are not, and asked for empirical evidence.

Well, maybe you've already seen this (or have since writing that), but Saeed Dehnadi and Richard Bornat supply exactly that - see their <a href="http://www.cs.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf>first and second papers on their work.

I don't really know whether to believe it or not.

-- tom

What do you have to say?

(will show your gravatar)
Please add 1 and 3 and type the answer here: