I <3 Steve McConnell*
Coding Horror
programming and human factors
by Jeff Atwood

January 29, 2007

How To Become a Better Programmer by Not Programming

Last year in Programmers as Human Beings, I mentioned that I was reading Programmers At Work. It's a great collection of interviews with famous programmers circa 1986. All the interviews are worth reading, but the interview with Bill Gates has one particular answer that cuts to the bone:

Does accumulating experience through the years necessarily make programming easier?

Bill Gates: No. I think after the first three or four years, it's pretty cast in concrete whether you're a good programmer or not. After a few more years, you may know more about managing large projects and personalities, but after three or four years, it's clear what you're going to be. There's no one at Microsoft who was just kind of mediocre for a couple of years, and then just out of the blue started optimizing everything in sight. I can talk to somebody about a program that he's written and know right away whether he's really a good programmer.

We already know there's a vast divide between those who can program and those who cannot.

But the dirty little secret of the software development industry is that this is also true even for people who can program: there's a vast divide between good developers and mediocre developers. A mediocre developer can program his or her heart out for four years, but that won't magically transform them into a good developer. And the good developers always seem to have a natural knack for the stuff from the very beginning.

I agree with Bill. From what I've seen, there's just no crossing the skill chasm as a software developer. You've either got it, or you don't. No amount of putting your nose to the grindstone will change that. But if you accept that premise, it also presents us with a paradox: if experience doesn't make you a better programmer, what does? Are our skill levels written in stone? Is it impossible to become a better programmer?

To answer that question, you have to consider the obsessive nature of programming itself. Good developers are good at programming. Really good at programming. You might even say fanatically good. If they're anything like me, they've spent nearly every waking moment in front of a computer for most of their lives. And naturally, they get better at it over time. Competent software developers have already mastered the skill of programming, which puts them in a very select club. But if you're already in the 97th percentile for programming aptitude, what difference does a few more percentile points really make in the big scheme of things?

The older I get, the more I believe that the only way to become a better programmer is by not programming. You have to come up for air, put down the compiler for a moment, and take stock of what you're really doing. Code is important, but it's a small part of the overall process.

This piece in Design Observer offers a nice bit of related advice:

Over the years, I came to realize that my best work has always involved subjects that interested me, or — even better — subjects about which I've become interested, and even passionate about, through the very process of doing design work. I believe I'm still passionate about graphic design. But the great thing about graphic design is that it is almost always about something else. Corporate law. Professional football. Art. Politics. Robert Wilson. And if I can't get excited about whatever that something else is, I really have trouble doing a good work as a designer. To me, the conclusion is inexcapable: the more things you're interested in, the better your work will be.

Passion for coding is a wonderful thing. But it's all too easy to mindlessly, reflexively entrench yourself deeper and deeper into a skill that you've already proven yourself more than capable at many times over. To truly become a better programmer, you have to to cultivate passion for everything else that goes on around the programming.

Bill Gates, in a 2005 interview, follows up in spirit to his 1986 remarks:

The nature of these jobs is not just closing your door and doing coding, and it's easy to get that fact out. The greatest missing skill is somebody who's both good at understanding the engineering and who has good relationships with the hard-core engineers, and bridges that to working with the customers and the marketing and things like that. And so that sort of engineering management career track, even amongst all the people we have, we still fall short of finding people who want to do that, and so we often have to push people into it.

I'd love to have people who come to these jobs wanting to think of it as an exercise in people management and people dynamics, as well as the basic engineering skills. That would be absolutely amazing.

And we can promise those people within two years of starting that career most of what they're doing won't be coding, because there are many career paths, say, within that Microsoft Office group where you're part of creating this amazing product, you get to see how people use it, you get to then spend two years, build another version, and really change the productivity in this very deep way, take some big bets on what you're doing and do some things that are just responsive to what that customer wants.

You won't-- you cannot-- become a better programmer through sheer force of programming alone. You can only complement and enhance your existing programming skills by branching out. Learn about your users. Learn about the industry. Learn about your business.

The more things you are interested in, the better your work will be.

Posted by Jeff Atwood    View blog reactions

 

« Extending The Windows Vista Grace Period to 120 Days Stylesheets for Print and Handheld »

 

Comments

true!

Juha on January 30, 2007 02:39 AM

!false

Great post.

Maybe you could write some about how you organize your day? Because I want to learn how I get time to "not programming"? :)

Peter Palludan on January 30, 2007 02:57 AM

i think that we should have a definition of what a 'good developer' is. let's assume that a 'good developer' is someone who develops code that doesn't hog the system's resources and who uses the minimum number of lines of code and in minimum time.
i firmly believe that having a good design phase can greatly improve your coding.once you have your plan,you can start programming instead of constantly going back and forth between designing and programming.a good programmer knows how to translate an idea into effective code and having a good design phase will save you a lot of time and allow you to concentrate on other aspects of the project.

so i totally agree with the article that you can become a better programmer by not programming.by becoming better at designing, you can become a better programmer.

ajmal on January 30, 2007 03:31 AM

Very true indeed. I did not recognize the "do not program" fact this way of my own, but I recently wrote something similar categorizing "Different types of programmers" (http://goit-postal.blogspot.com/2006/10/different-types-of-programmers.html) even without having that in mind: "The Generalist" is pretty the kind of guy who does not program while programming.

Thumbs up! Georgi

Georgi on January 30, 2007 03:35 AM

Isn't everything in this post related to basically any creative field? If you'd replaced the programming references by music, art, literary, or performance references, you'd have the same point and there'd be nothing fresh about it. (Except that making an emotional connection to your audience is perhaps done in a completely different way.)

Foxyshadis on January 30, 2007 03:37 AM

Expanding your horizons is also a key. Being personally supposed to teach software engineering this year, I have been having the same kind of concerns. See "The unteachable parts of software engineering", http://blog.vermorel.com/?p=28

Also, being "good" involves many aspects. For example: is-it wise to implement (even if the execution is perfect) a product that either already exists or that does not reflect any business needs?

Joannes Vermorel on January 30, 2007 04:41 AM

I disagree that you can't get better. While certainly like anything else there are those that are gurus or prodigies at it. But every programmer learns better way of doing things as time goes on. Whether it is coding something by hand and then moving to wiring in a COTS to save resources or programming with Web Services for the first time as opposed to limit oneselves to a Windows Form. Some things cannot be learned overnight. 4 years is a long time. Nothing looks the same as it did 4 years ago. So I think it all can be boiled down to how readily a programmer adapts to new technology instead of for example still doing VB6 for everything in 2007.

I often find this blog overgeneralizes. The trend you speak of is inherent in anything. Not just programming.

Josh on January 30, 2007 04:48 AM

I think this post points in the wrong direction.
Programming, the art of abstraction, logic, reduction, and rewriting is independent of 'the real world'. A great programmer can look at a program and see it's beauty irrespective of it's real world significance. Finding new minimal ways to represent patterns and mechanisms to verify the correctness of those patterns is more important to me than how it can be used in real life.
I agree with the need to raise your head, but for a different reason. Other great programmers are exploring important ideas regarding syntax and semantics that can drastically improve your expressivity, correctness, and productivity. A significant amount of any programmer's time is well spent measuring him/herself and his/her productivity, and looking for ways to optimize that. The payback of exploring different architectures, computing paradigms, languages, and algorithms is enormous.
Ben

Ben on January 30, 2007 04:59 AM

Jeff, nice post about needing some breadth to go with your programming depth. But, I was a littel disappointed with the content vs the title: I'd hoped that you'd be writing about the programmer's failure mode of approaching every problem with the solution "write more code" already in mind.

Really great programmers go to the heart of the problem, find what aspect of it adds most value to the user then write a very small amount of code to address that, and that alone. Programmers have a tendency to think that the thing that they do that adds value (and justifies their paycheck) above all else is write more code. And so they write code. What they don't take into account is that code is a liability for the customer, not an asset, so the less of it they produce (while adding value through solving the problem), the better.

Best of all, delete some. The very best programmers can take a new problem, find the essence of it, find the commonality with the essence of the problems already solved, incorporate the new solution and end up with less code than they started with. http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt for example

Ivan Moore will even tell you that deleting code is a refactoring http://ivan.truemesh.com/archives/000393.html In fact, he sometimes says that even if that isn't your goal a good non-delete refactoring should allow you to delete some code, or else you are just pushing code around for the sake of it.

keithb on January 30, 2007 05:11 AM

Absolutely true. I like developing software, but I also like spending time with my family, working out, writing music, reading, etc., etc. If all I did was code, I'd have a very limited perspective and my problem solving skills would deteriorate rapidly.

Jason Bock on January 30, 2007 05:32 AM

"But if you accept that premise, it also presents us with a paradox: if experience doesn't make you a better programmer, what does? Are our skill levels written in stone? Is it impossible to become a better programmer?"

Um, that's not what Bill said. He said you'll know within a couple years what type of programmer you are, not that experience can't make you a better programmer.

Dave on January 30, 2007 05:32 AM

Really good programmers spend a lot of time THINKING.
Not madly typing in code. Typing should be the last
act, not the first.

Rob on January 30, 2007 05:42 AM

This reminds me of the old and so true quote from Larry Wall

"The three chief virtues of a programmer are: Laziness, Impatience and Hubris"

Where I think that order also is important...

Edward on January 30, 2007 05:52 AM

Your ability to think creatively is proportional to your programming talent. Great problem solvers make great programmers.

farmsworth on January 30, 2007 05:59 AM

Some of the best code I've ever written was actually done on a legal pad with a pen. I've written code across the spectrum, from memory management on early Linux kernels up to massively parallel supercomputers over satellites. Code that I look back at and say "Damn! That was good." I did when I back away from the computer, say down with pen and paper, and write the algorithm/design out. Sometimes it was before coding and sometimes in the middle of slogging through digital sewage.

My point is that good code is developed in your head, not your compiler. You don't need a computer immediately to write good code.

JimmyZ on January 30, 2007 06:04 AM

Here you go again, Jeff, beating that poor dead horse again. We've already familiar with your opinion on this. But I would like to ask you a few things. Will not running make you a better runner? Will not playing tennis make you a better tennis player? Will not thinking make you a better thinker? You're preaching this approach because you, in the natural progression of your career, are programming less and managing more. I mean, come on, if you have this much time to blog then you're not pumping out a thousand lines a day.

You see, you are trying to convince yourself as much as you are trying to convince us that programming less is the way to go. It's ok, I'm not faulting you for that. We all evolve in our careers (we have no choice, eh?) It's just that I don't think you're main argument is valid. You might become a better manager, a better architect, etc. by programming less, but you won't become a better programmer that way.

Ken on January 30, 2007 06:20 AM

@ken

I think you're completely missing the point.

Programming more will give you a better understanding of syntax, control structures and other techincal elements of programming, but there is more to being a good programmer than just writing code.

An example of the difference is the word verification on this page. A bad programmer who knows lots of syntax would probably write a bulky code base that randomly generates and scrambles a series of random characters. However, that's like hammering a finishing nail with a sledgehammer. The simple phrase 'ORANGE' is probably just as effective at blocking comment spam as some over complicated captcha system, but it required far less code and is much easier for users to deal with.

The point is that there are 2 ways to solve most programming problems. Either keeping writing code until it works or take time to address the goals and develop a concise elegant solution. Anybody can memorize syntax, it takes a good programmer/developer to really understand the bigger picture.

Ian Muir on January 30, 2007 06:42 AM

You may want to read Steve Yegge's counterpoint to this post:
http://steve.yegge.googlepages.com/practicing-programming

How do you know you are even a 'good' programmer?

Pedro on January 30, 2007 06:56 AM

If I thought 4 years ago "This is the best I'll ever be." then I would probably be a worse programmer today. Well-roundedness is an issue and being a good programmer is about solving the right problems.

Perhaps Bill meant your personality as a programmer is set in stone, but you'd never convince me that I haven't been increasing my skills and knowledge.

To be fair, I still approach problems the same way. I also still like writing good clean code and I still like to read books on all sorts of topics (dev and otherwise).

I would however hope the code I write now isn't as bad as what I wrote back then.

MintyFreshness on January 30, 2007 06:58 AM

Good stuff. However, the term 'programming' perhaps needs to be better defined: Optimizing a routine (pointlessly) so it is impossible for someone else to read but is 1% faster? Writing code that can easily be extended and modified? Building an app that can (relatively) easily be changed due to the whims of the customer? Seeing the big design picture and organizing the development strategy?

Another curious thought is why are some people really, really productive in one language but not in another? Why does a certain language 'get in the way' of a person's mind as they try to turn a problem into a solution?


Steve on January 30, 2007 07:10 AM

I read both articles (which includes the one in the comments above). They both approach programming from two different perspectives. Yes, you have to practice and study to become a better programmer. You also have to get away from it from time to time to gain the perspective of those who are going to use, sell, or market the code you're working with.

The way I see it, the articles are not opposing each other but complementing each other.

RT Cunningham on January 30, 2007 07:10 AM

I agree to a point. I would strongly argue against the notion that we can't get any better ever. I've been coding professionally for about 7 years now and I think I'm MUCH better now than I was even 2 or 3 years ago.

That said, I do think that there are some people who hit that wall and can't proceed any further. People for whom this article is more true. I've seen it in school, in my work, etc.

So I think you can't generalize this to all programmers. I continually study and read to improve my skills. Not all my studying is on actual coding but a good portion of it is. And I feel like I've gained more skill in the past 2-3 years than I did in the 4-5 years before that.

Jeremy on January 30, 2007 07:20 AM

Kathy Sierra's "How to be an expert" essay

http://headrush.typepad.com/creating_passionate_users/2006/03/how_to_be_an_ex.html

takes the opposite point of view to your suggestion that "A mediocre developer can program his or her heart out for four years, but that won't magically transform them into a good developer....You've either got it, or you don't. No amount of putting your nose to the grindstone will change that."

Her view is that "The only thing standing between you-as-amateur and you-as-expert is dedication. All that talk about prodigies? We could all be prodigies (or nearly so) if we just put in the time and focused. At least that's what the brain guys are saying. Best of all--it's almost never too late."

Peter Norvig's "teach yourself programming in ten years"

http://norvig.com/21-days.html

would seem to agree with Ms Sierra's 'dedication' theory.

Dave Bartlett on January 30, 2007 07:33 AM

Ben wrote:

> I think this post points in the wrong direction.
> Programming, the art of abstraction, logic, reduction,
> and rewriting is independent of 'the real world'.
> A great programmer can look at a program and see it's
> beauty irrespective of it's real world significance.

Ben, there's a hell of a difference between a skilled developer and a skilled programmer. That's the whole point of the story.

JensG

JensG on January 30, 2007 07:43 AM

Well said, JensG. The point is that you must look beyond yourself to improve -- not simply sharpen what you already know.

If you know a programming language, it becomes a means - a tool - not an end in and of itself. It's just part of your skills that can't get much better.

bryan on January 30, 2007 08:03 AM

Overrated blog post! Nothing intriguing. Actually its difficult to describe a good programmer and I know a few folks who have gotten much better at programming after years of programming. IMHO, good programming is a function of your intelligence and I think great programming requires not only intelligence but also creativity. The best programmers I know are artists not engineers!

Kashif Razzaqui on January 30, 2007 08:03 AM

It's all about the niche of programming. Programmers are problem-solvers. It's what I do 95% of the time. I like doing it. I perfer to do it with code, but sometimes it requires an email, a conversation, a new roof, etc. My family expects me to solve their problems, my coworkers and customers do as well.

These visionary types are about seeing and creating new problems. This is what I'm not very good at and don't like to do. I can build the taj mahal, if you tell me you want a very nice house, but I can't figure out that you want the taj mahal through some spark of intuition or while we're talking about the cubbies.

Would I be a better programmer if I did more of the idea-work? I don't think so. I think my skills would rust because I've stopped solving problems. We've got some genius idea people (who are/were programmers) that know how to express and describe an idea to anyone, but it would take them 50x as long to write the solution. Bring me the problem, you take the glory. Works for me.

Steve Jackson on January 30, 2007 08:15 AM

Very interesting post! IMO, the "da Vinci route" should be efficient to excel in just about anything: Study anything even remotely related to your field. You can get completely different insights from doing a bit of 3D modeling, OS tweaking, web accessibility, iPod hacking, gaming, system administration, etc.. Any of these can make you a better programmer, by giving you a view of how different types of systems behave - Or maybe more important, give you ideas of how they /should/ behave.

l0b0 on January 30, 2007 08:21 AM

After re-reading this a few times, I think I agree, but it'd be very easy to draw some wrong conclusions from what you've written.

At 3 or 4 years, a programmer has demonstrated if they've got the innate ability to program, but programming skill becomes dated very quickly. Being a good programmer also requires being current in your skills, and that only happens through practice. Most programmers demonstrate their aptitude at 3 or 4 years, but they demonstrate their potential as a programmer (mind you, I'm just talking about their skill as a programmer) when the first big industry shift hits, and they need to update their skills. Then they demonstrate it again when the second shift hits. Then they demonstrate it by realizing that the whole thing is constantly shifting, and they come up with ways to keep their skills constantly up to date.

As an example - If I had to hire a developer today for a 2 month website project, I'd pick Scott Guthrie over Bill Gates. Why? Bill has demonstrated exceptional programming ability and is likely more informed on a lot of things, but his skills probably aren't as current as Scott's. Scott has a blog and posts code. I don't know, but I'm guessing that Bill could only talk at a high level about many of the essential elements of programming circa 2007. I'm not saying Bill isn't accomplished as a software professional (an untenable position if ever there was one), but my guess is that he's no longer a great programmer.

As someone mentioned above, running makes a good counterpoint. It's easy to tell in a few years if someone has the body to be a good runner, but if a runner stops running regularly, they won't continue to be a good runner for very long.

Jon Galloway on January 30, 2007 09:09 AM

Well, to give you an idea, I program perhaps once every few months. The few times I dive into code, I'm there for a reason. Nine times out of tend, I write the unoptimized version within the first 10% of the time I spend coding. The other 90% is a pretty even split between optimizing the code and tweaking its functionality. I think the reason I never became a hard-core programmer, even though I've been told time and time again that I have the chops, is that I simply don't want to make the compiler and debugger my two best friends (and worst enemies). I'm not a social butterfly by any stretch of the imagination, but I need more social interaction than that...

Jae on January 30, 2007 09:14 AM

You either have it or you don't...

Rabid Wolverine on January 30, 2007 09:20 AM

I think there's a common arrogance among developers that "great programmer" == "thinks like me".
In one instance I was arguing for a significant abstraction layer between some incoming data and an (informal) datamart we were building on top of it. The incoming data was from several sources and a) was very inconsistent, b) the developers kept making mistakes when trying to glue all the data together so they could use it, and c) I didn't want to impact all of the downstream apps when the incoming files were modified.
My co-worker wanted very minimal abstraction, because a) more abstraction means more code to maintain and more opportunities for bugs and b) the incoming data only changed 2-3 times a year, and c) most of the people who used the data were familiar with the incoming feeds but wouldn't have access to the code base, and therefore if we put too much code in between it would be hard for them to differentiate bad incoming data (very common) from bugs in our code (also very common).
For 2-3 days each of us was convinced that the other was at best naive, more likely stupid, and most certainly SUCKED as a developer. But ultimately we were both right -- we were just optimizing different aspects of the problem based on our gut feel for where the pain would be in the future.
As a coda, I ended up winning the argument and (as I was debugging and modifying the abstraction layer over the next few years) developing what I call "The Law of Constant Pain". There is no optimal spot where pain is minimized -- all good solutions trade off pros and cons in equal measure, so all good solutions are equally bad and good. Making it better in one aspect makes it (at best) equally worse in another aspect. (And of course there are lots of solutions that are worse all around, but the people who come up with those are the *real* lousy developers.)

JPLemme on January 30, 2007 09:29 AM

This may be tangential to the topic ...

"The main idea of our column is that “talent” is overrated; that practice really does make perfect; and that it’s a good idea to do what you truly love in life, because if you don’t, you probably won’t work hard enough at it to get really good."

http://www.freakonomics.com/blog/2007/01/08/practice-makes-perfect-revisited/

kloodge on January 30, 2007 09:29 AM

One more point. If I owned Microsoft I'd want cracker-jack programmers. But if I ran an IS department I'd rather have VB6 developers with business degrees than brilliant computer science grads. This is a bit bigoted, but real life is messy and inelegant. People with an CS background too often seem to get frustrated (or even angry) when their elegant solutions can't handle the real world. Obviously the real world is at fault in these situations, and therefore it just has to change. People with an IS background seem more willing to tolerate messy solutions if it means the business problem gets solved quickly and correctly.

I know there's a balance, but it should be tilted towards the activities that earn money for the company, not to some propeller-heads mathematically pure conceptual frameworky things.

JPLemme on January 30, 2007 09:42 AM

Gates was only saying that programming experience won't turn one into a good programmer. He never said that programming experience will not make one a better programmer.

anonymous on January 30, 2007 10:07 AM

i will say that it is not about coding but more about understanding the requirements. if you know the problem then you can solve it, but if you don't, how can you solve it? think about it. a better programmer is one who understands the problem faster then others.

thecancerus on January 30, 2007 10:19 AM

I used to spend every waking moment in front of the computer also. Then I got tendinitis so bad I almost had to change careers. Now I spend no more then 4 or 5 hours a day at the computer, but I'm still a damn good programmer.

Be careful people.

MarketGarden on January 30, 2007 10:26 AM

Interpretation: Compare "programmers" to singer-songwriters. A would-be songwriter can practice on an instrument all day and all night for years, but if they have nothing to say, then? "Passionate" people throw themselves into larger concerns, and out of their experience and personality will have plenty to say as a result. ... As one side-effect, programmers will say it through code.

Jerry Van Polen on January 30, 2007 10:35 AM

> Gates was only saying that programming experience won't turn one into a good programmer. He never said that programming experience will not make one a better programmer.

That's right. And what I'm saying is that the skill differential between mediocre and great programmers is so wide and so vast, that *the tiny differences between great programmers are barely significant*.

Once you're a great programmer, you're worth 5, 10, 20 mediocre programmers. See the many data points cited here:

http://www.codinghorror.com/blog/archives/000072.html

Studies have proven time and time again that, statistically, there is *NO* correlation between years of experience and skill in software development. This isn't conjecture, this isn't my opinion, it's a scientific result supported by experiments and hard data.

Therefore, if you are *already* a great programmer, and you want to distinguish yourself even further, you should learn complementary disciplines, rather than going for the 99.5th percentile skill level of greatness. Nobody can tell a 99.5th percentile coder from a 98th percentile coder. But they can sure as heck tell the difference between a great coder and a great coder who *also* understands usability, the business, the customer, etcetera.

Jeff Atwood on January 30, 2007 10:41 AM

"Therefore, if you are *already* a great programmer, and you want to distinguish yourself even further, you should learn complementary disciplines, rather than going for the 99.5th percentile skill level of greatness."

I think the counterpoint that a few people are making is that if you go after these complementary disciplines you might lose that 98% greatness and fall back into the masses. It may only take you a few months/minutes to get back to full developing speed, but there is a transition there between being an advocate/"business" type person and a code slinger. If you don't write code anymore you're not a great programmer. It's like saying Michael Jordan is a great basketball player. Michael Jordan WAS a great player. Now he's an incredibly rich and successful something else. But I don't code for riches or fame, I code because it's what I would do for fun if my full time job was gas station attendant. And because I do it for me, I don't care if no one else cares that I'm in the 90 percentile. It matters to me. That's not to say those other things are inferior (it certainly pays as if it were more important), I just wouldn't go around thinking I'm an 98% great programmer if I was actually a 98% great writer, a 75% great speaker, and an 85% great programmer.

Steve Jackson on January 30, 2007 11:18 AM

I am, as the original post describes, a "good" programmer, but *not* a great one.

My algorithms/modules/programs work. They do the job. But, they are neither elegant nor efficient. No matter how much I programmed, no matter how much I studied, my raw ability to problem-solve did not improve. My repertoire of languages improved. My documentation improved. Other things improved. But, not my ability to produce elegant code, nor efficient code.

I've recognized this, and thus, when required to produce code, explain to the requestor that the end result will work, but will likely be brute-force rather than elegant, and can always be edited for efficiency.


.

Izzy on January 30, 2007 11:50 AM

Bravo. Exactly what I've been telling fellow developers for years.

TJ on January 30, 2007 11:52 AM

"...Competent software developers have already mastered the skill of programming"

Can some one define the programming skill? if there's such a thing.

Programming is closer to art than any other engineering profession. The range in the solution field is so great that solutions to any problem are as varied as the colors of the rainbow. In fact I'm willing to assert that the reason why there are great programmers and not so great is the same reason why there has been and will only be one Monalisa and one DaVinci.

cland on January 30, 2007 12:18 PM

Well most programmers aren't in the 90th percentile, so there's still room for programming improvement. I'm not convinced by this "innate talent" argument. See my response: http://haacked.com/archive/2007/01/30/Better_Programming_By_Programming_Better.aspx

Although I do agree that the "tangential" skills are very important for *all* levels of developers and most likely will make a developer more valuable faster than improving programming skills.

Haacked on January 30, 2007 12:47 PM

> Will not running make you a better runner? Will not playing tennis make you a better tennis player?

I think the physical analogies break down. Programming is a purely mental activity. And as I've cited multiple times in the original post and in the comments, the distribution of skill in programming is extremely lopsided relative to other professions. There's no normal curve: it's a double hump of those who can, and those who can't.

So if you can do it *at all*, you can always do it. Your programming skills won't deteriorate to the point that you can't program. You won't slide back over from a Sheep to a Goat. It's impossible.

> Will not thinking make you a better thinker?

Sometimes not thinking can, in fact, make you a better thinker. You don't stop thinking entirely. You stop thinking about the same topics and instead think about related (or completely unrelated) topics that can lead to breakthroughs in other areas. Richard Feynman didn't spend all his time thinking about physics:

http://en.wikipedia.org/wiki/Surely_You're_Joking,_Mr._Feynman!

Jeff Atwood on January 30, 2007 01:10 PM

Interesting post, but utter BS. :)

You can be anything you want to be. Whatever you set out to achieve you can do if you really decide to and really work at it. You've heard this pep talk before, I know, but it happens to be true.

The guys who try to tell you that you can't cut it simply have their own ax to grind. Either they tried and failed, or they have some vested interest in your failure. Don't believe any of it.

andy on January 30, 2007 01:29 PM

Thinking is for fratboys

retardonerd on January 30, 2007 01:44 PM

Typical boooschwaa sensibility crap. Bill "I got rich cuz mommy had a hook up" Gates is a great swindler. Anyone who tries to justify thier greatness by saying you have to not do something to be good at it is trying to justify their own fear being looked at for what they really are.

Attitudes like the ones portrayed by these "lifestyle" programmers have no clue what it really takes because they have been getting others to code for them since they got thier cushy new office with thier ultra-geek pong clocks...

Excuse me while I barf all over my keyboarasdfa;lkj;alkdja;sldadj

retardonerd on January 30, 2007 01:53 PM

Anyone can be a good programmer. The difference is that most people are not driven to become good at anything. They reach a point that is comfortable for them and stop improving. You see this in all aspects of life.

I completely disagree that a good programmer is apparent or not within a few years. What you might discover is if someone cares enough to improve themselves.

It has often been said that it takes 10 years to develop a mastery of any skill. In my experience this is a reasonable statement. It's just a pity that in software development 10 years is just about a programmers expiry date.

Whoop on January 30, 2007 02:27 PM

mixing up a lot of notions here:

- that Gates is qualified to judge. may be not. IIRC, he's never provided evidence that he ever wrote anything other than a BASIC interpreter (and legend has it that Allen was the primary author). is there any? being a critic of X doesn't entail being good at X; usually, but not systems development. the quality of criticism here derives not from subjective preference (this picture pleases me more than that picture), but acknowledged superiority (i built a better mousetrap, and yours is crap because it doesn't trap mouses). which brings us to...

- that M$ is a demonstrable example of innovation, superior systems development, or creativity. if you go down the list; it was something they stole (DOS), something they built for hire then stole (Windows UI), something they built for hire then ported (Office), something they EEE (IE), something they lucked out on (DOS for IBM, who were clueless; and Lotus 1-2-3 which was made ONLY for DOS and thus made DOS mandatory), something they did that was illegal but didn't get really punished for (the anti-trust stuff, and the continuing punitive contracts with OEMs; do you really think Dell, et al wouldn't offer Linux if they could without penalty?). face it: M$ got where they are not by building better mousetraps, but by trapping folks into buying only M$ mousetraps.

- folks are confounding understanding syntax (can you write tight code in X language?) with semantics (do you understand O/S prinicples or database principles or Knuth's books?). the notion that what you know how to do changes in 4 years is the syntax trap. being able to absorb new syntax/languages in short order is a demonstrable skill. not the same as being a brilliant developer.

- that coders are the same as developers. developers are different from each other (coders, too). having a deep understanding of the logic and structure of an O/S is different from (and have less $$$$ value), than deep understanding of how to build a databased G/L. in fact, i'd bet on it.

- DaVinci wasn't born doing that stuff; he learned his trade first. the aura of creativity is self-aggrandizement. even Picasso had different periods and made different stuff.

Buggy Fun Bunny on January 30, 2007 02:33 PM

- "Programming is closer to art than any other engineering profession"
- "Your ability to think creatively is proportional to your programming talent."
- "I think great programming requires not only intelligence but also creativity. The best programmers I know are artists not engineers!"

Above posters would be interested in http://www.amazon.com/Software-Creativity-2-0-Robert-Glass/dp/0977213315/sr=1-1/qid=1170197290/ref=pd_bbs_sr_1/002-0838152-3645618?ie=UTF8&s=books

- "Finding new minimal ways to represent patterns and mechanisms to verify the correctness of those patterns is more important to me than how it can be used in real life."
- "People with an CS background too often seem to get frustrated (or even angry) when their elegant solutions can't handle the real world"

Interesting that both ends of the spectrum read this blog. BTW, the first post relates much to the previous blog entry about how much code you've written that's actually in use. I assume the poster is an academe.

Brad on January 30, 2007 02:51 PM

i'm 30, and went back to school after having a diploma (gifted, etc. - just lazy as a 10 year cat) and have learned that practice does indeed make better... I used to have the worst code ever, but was the most computer-literate person otherwise. Stuff I'd do would include extensive hard-code, redundant vars and such, and some of the worst logic ever (after I re-read it a week later). Now after a few failed jobs and such, I've realized how much code I did know and have now 'grown' a sense programming that I didn't know I didn't have.

I see the same problems that used to take me twenty lines of code i now do in five. So, I disagree... Spending time with the code does help - but the article is true about one thing... If a person is not comfortable with abstracts and meaninglessness, the concept of code would be lost.

ceelow on January 30, 2007 02:59 PM

So I'm never going to be a good programmer then.

engtech on January 30, 2007 04:05 PM

> I think the physical analogies break down.
> Programming is a purely mental activity.

As is Chess, which was featured prominently in the article I referenced. Chessmasters are made, not born. Why not good programmers?

Haacked on January 30, 2007 04:36 PM

> Chessmasters are made, not born. Why not good programmers?

I'll answer your question with another question. If chess is analogous to programming, why can't computers write code as well as they play chess?

Human grandmasters are barely holding their own against chess programs these days. And depending on who you ask, human chess players have already lost the war.

http://www.codinghorror.com/blog/archives/000701.html

The answer, of course, is that programming has an infinity of choices compared to chess. As others have commented, it's so open ended that it's more analogous to art, or writing, or other purely creative activities.

Also, just to clarify, I never said that you can't improve as a programmer. Sure you can. But 90% of the improvements will be realized in the first four years of your professional career, and the rest will be incremental.

Jeff Atwood on January 30, 2007 04:49 PM

I feel that this posting does hold some weight though because a persons IQ is said never to change. There's always some programmers code snippet that you find around the web that is just so clever it sometimes depresses me to think 'oh, i would've never thought of that!'.

does reading, absorbing then implementing tons of good code, and adding you're own little twist make you a good coder?, i don't think so. So maybe those really good programmers are just the ones that make the breaththroughs.. like david heinemeier hansson with rails for example.. and i'm just the average guy who is just good enough to use it.

oh, and about the idea that not coding can make you better only makes sense if the reason why you've stopped is because you became over critical of yourself (i've done it). When you come back without all the negativity and a clear head.. you're automatically better.

.. if i've repeated something, sorry, i didn't have the time to read all the comments.

crappy_coder :) on January 30, 2007 04:57 PM

Couldn't agree with you more Jeff, programmers must keep their head above the water for other things beside coding. Computer programs will be useless without any users using it right? It's just like your previous post, coding is fun, but shipping is the real job.

Hendra Saputra on January 30, 2007 07:07 PM

The best programmers are not normal... they are either obsessive compulsive, bipolar, paranoid, or neurotic.

cyclo on January 30, 2007 08:58 PM

Great post, Jeff.

The problem with more of the "people" aspects of software development, is that I believe these skills are very hard to learn or practice.

If it doesn't come naturally to you, can you practice or learn enough about how to get people to like you and have decent human interactions with them?

With some things you can "fake it til you make it," but the real issue you're dealing with in personal dynamics is empathy. If you're just naturally nihilistic and have no empathy for others, and use them as objects or ends to your means, then no matter how hard you fake it -- that will still show through.

And it is a damn shame that more corporations don't recognize the value of the 99%'s out there. It's why anyone in that category should seriously consider starting up their own thing with a couple of buddies -- it's the only way you can extract that latent value.

Shanti Braford; On Web Apps on January 30, 2007 10:00 PM

In my opinion this is disheartening for beginners,
Someone who does not know anything about programming and wants to learn
you say something like this to them and there goes there desire to learn out the window~~!!!!!
My comment on this is Not everyone is a great programmer to start They worked diligently at it and if there not so great it's because someone like you wrote a statement like this and discouraged there desire!

Donna on January 30, 2007 10:46 PM

True, totaly agree with you,

But what i think is just 2 years is not enough to predict the issues in the design, for that one need at least 4 years of coding experience.

Anoop Jose on January 31, 2007 12:13 AM

What junk is this ?

Atreya on January 31, 2007 12:28 AM

"To truly become a better programmer, you have to to cultivate passion for everything else that goes on around the programming." 100% agree. Now based on that premise, how can you become better programmer even without programming?

fade2blac on January 31, 2007 12:52 AM

i wonder why programming is related to art? I taught programming is all about the logic. Good programmer can solve a problem by producing a good logic. from my perspective, coding is more like giving instructions for computer to do this and that.correct me if i'm wrong..

tokan on January 31, 2007 02:26 AM

ooops..grammar mistake.."taught" should be "thought"

tokan on January 31, 2007 03:57 AM

> If chess is analogous to programming, why can't computers write
> code as well as they play chess?

Well they can't *yet*. Just as computers couldn't play chess very well 20 years ago. Today, they still can't compete against humans at GO.

Give it time.

Haacked on January 31, 2007 08:50 AM

I agree with Bill. I am just amazed to find out how many people disagree with Bill.

From a midocre programmer who will never be a "good" programmer and who is quite happy to be a "mediocre" programmer, but a good human being, which I think is better than being a good programmer and suck at being a decent human.

Thanks

don on January 31, 2007 09:20 AM

1) If you're reading this blog-- and by this blog I mean any technical blog-- it's unlikely that you are a mediocre programmer.

2) Mediocre programmers don't even know that they are mediocre. So if you think you are, that level of self-awareness automatically disqualifies you from mediocrity.

3) Mediocre programmers don't read technical blogs, or Joel on Software, or Code Complete, or Don't Make Me Think, etcetera.

If you're reading this, I can assure you that you, yes you, ARE a good programmer. Trust me.

Jeff Atwood on January 31, 2007 10:32 AM

Thanks for the wonderful words of encouragement. However, I know pretty well that I am a mediocre programmer, mostly because I am lazy enough to avoid complex problems, but also because I am unable to resolve certain complex problems.

Having said that, I have the impression that for a lot of good programmers, the whole idea of being a good programmer is to tell everyone how bad or "mediocre" everyone else is, and they make a point that being mediocre is like having a disease of some sort.

All I am suggesting that it is not. Mediocre programmers fulfill their roles in the organization in a lot of ways and they are just a great bunch of people to hang around with.

Cheers.

don on January 31, 2007 12:38 PM

While I think there are "problems" with programmers (http://www.edmblog.com/weblog/2006/11/the_problem_wit.html), I do think that most people don't want to write code (http://www.edmblog.com/weblog/2007/01/does_everyone_e.html), and could not if they wanted to. The fundamental problem is that programmers and business users have a different perspective (http://www.edmblog.com/weblog/2005/08/different_persp.html)
JT
http://www.edmblog.com

James Taylor on January 31, 2007 02:35 PM

Who is talking, and who is who? A good programmer doesn't have time for morals and bitching on the others. Also, what made a good programmer is subjective. It could happen that junior finds something that the others didn't see. Is probably the only substancial contribution that this person made but it may save the compagny from hell ... Remember Jobs, every buddy was looking at him as a looser. He 's making a tremendous comeback.

If your not the father of a great system or builder of a new program, your just a vulgar refurbisher of what you never build, because you dont have the guts to work on real things; but i'm sure you prove that you have fast mind but rabbits are better with estragon then a turtles.

N.B. dont see any discussion on real code... maibe you working on boring stuff...

Raphael on January 31, 2007 04:34 PM

I little off topis but this is a message for all of the young guys out there that think programming is their life.

Go out, meet people, travel, get a girlfriend, get married, have kids, buy a house, shower, learn how to dress, DON'T WORK AT HOME, DON'T PLAY COMPUTER GAMES ALL NIGHT........

I'm sure I will get lots of responses about this and that and excuse after excuse.......

IT needs to get a life outside of IT and interact with REAL PEOPLE.

Thanks,

Trev

Trev on January 31, 2007 04:48 PM

I think that Ben and Ken have it right. Steve, your article describes well how to be a software manager, but if you love coding and want to understand it as well as possible and work creatively and incisively in the field (as, say, a mathematician might without wanting to do the admin work of a department chair) then the question is "Is there a path to the deep understanding that a guru has?" and several posts have said "Yes!".

Barry on January 31, 2007 04:48 PM

BS.

I'm sorry, but I don't believe for a second that you can't change enough personally to make the leap from unable to be even a decent coder to becoming a great one. It's got nothing to do, however, with classical education. Much more to do with actual change.

I know I am an exponentially better coder than I was when I started coding fourteen or fifteen years ago. I can tell in my code, I can tell in the way I study others' code, I can tell in the way I approach the problems involved.

People change drastically over the course of their lives, they just generally do it for the worse mentally. It's an amazingly stupid assumption that people who started out as bad programmers will end up that way. I used to believe it. Then I saw people I originally had judged completely incapable of certain things accomplish them. And saw people I assumed I would hear from later disappear.

One thing I do know is that looking to a corporate manager for a judgment like this is not a great idea. You're looking in the completely wrong place. University profs who push coders from zero to 'usable newbie' are the people I would ask.

Dylan Brams on February 1, 2007 10:22 AM

The best advice I can give programmers is NOT to restrict your career path down one programming language / platform. Don't avoid C# if you have been a VB programmer for 5 years.

Why? Because in the end, it's all the SAME.

C++, C#, VB, ColdFusion, Pascal, PHP, whatever....

Sure, each language has it's quirks and idosyncrasies. Some languages take more care than others. In the end, you pick the right development tool for the job and go with it.

If you are a good programmer with a solid development methodology you can "code" in anything....

Shawn C on February 1, 2007 11:20 AM

>If chess is analogous to programming, why can't computers write
> code as well as they play chess?

>Well they can't *yet*. Just as computers couldn't play chess very well >20 years ago. Today, they still can't compete against humans at GO.


Maybe if we could ensure that only "good programmers" are working on it, instead of a bunch of mediocre programmers, they could solve the Go problem as well have computers write code for the rest of us.

<> Just a mediocre programmer

Petey on February 1, 2007 02:58 PM

Reg Braithwaite pointed out an excellent discussion of this article at Reddit. It's well worth reading if you got this far.

http://programming.reddit.com/info/11vft/comments

My favorite comments?

edheil: reddit loves self-improvement.
schizobullet: Unfortunately, it doesn't love being told what it loves.

That HAS to be one of the funniest things I've read this year.

Jeff Atwood on February 1, 2007 03:55 PM

I think the reason there's so much a mixed response to this post is that the act of programming is defined differently by different people.

If you define "programming" as the time when you sit in front of a computer writing code, than the running or chess metaphors make sense and you might claim more practice will always make you better.

If, however, you include the process of figuring out what and how to code, and the way your code gets used and maintained after you finish, then it seems to me this article makes a pretty solid argument.

For me code is meaningless if it's not used by someone. If you want it to be used, you need to understand people, markets, business etc. There is no way to learn this things by just coding some more.

Nir on February 2, 2007 08:55 AM

Moishe Lettvin of Google was also reading Programmers at Work, and offers his unique take on this topic:

http://moishelettvin.blogspot.com/2007/01/less-programming-more-skill.html

Love the Heinlein quote:

"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."

Jeff Atwood on February 2, 2007 11:27 AM

Bullocks!

Bullocks! on February 2, 2007 11:51 PM

All you have to do is to validate this is look at who you work with and estimate if they are a good programmer (ie can get the job done) or a great programmer (can get the job done, but know why they're doing the job - ie the bigger picture).

A great programmer produces a better solution because they understand the problem better, due to the insight gained from non programming activities, and interests.

Understanding the business as an abstraction and as an instance, the specific way this company does business, will allow the programmer to become great.

Paul Broadfoot on February 4, 2007 12:35 PM

If "conscious mind" is a fraction (ex: 10%) of one's active brain power, the rest being "sub-conscious"...

How can we know what programs and designs are being written by our subconscious when we are and aren't programming?

Keta Meme on February 5, 2007 12:56 PM

Jeff Atwood on January 29, 2007:
> To truly become a better programmer, you have to to cultivate passion for everything else that goes on around the programming.

I agree, and that is the same with any other creative work I did :-)

Shawn C on February 1, 2007 11:20 AM
> The best advice I can give programmers is NOT to restrict your career path down one programming language / platform.
>Don't avoid C# if you have been a VB programmer for 5 years.

Of course not. Platforms are everchanging, and that's good, because every single one of them sucked (because they were written for architectures which where slow, had almost no RAM and every design decision was made in favour of speed, smallness and cheapness, disadvantaging programmer convenience/expressiveness in the process).

> Why? Because in the end, it's all the SAME.

From the programmer's standpoint, there's a HUGE scale on them. So no, they are not.

> C++, C#, VB, ColdFusion, Pascal, PHP,

These are all the same, yeah.

> whatever....

Look at Dylan, Haskell, Logo, Pliant, Prolog, Ruby, Python, Boo or a language of the LISP family and say that again.

> Sure, each language has it's quirks and idosyncrasies. Some languages take more care than others. In the end, you pick the right development tool for the job and go with it.

Yeah. But if every tool was the same you could pick any of them for anything.

But none is the same. Members of the C family are mostly the same language-wise but completely different framework-wise.

All others are completely different from the C family.

> If you are a good programmer with a solid development methodology you can "code" in anything....

... [anything] that you know

Keta Meme on February 5, 2007 12:56 PM:
> If "conscious mind" is a fraction (ex: 10%) of one's active brain power, the rest being "sub-conscious"...

> How can we know what programs and designs are being written by our subconscious when we are and aren't programming?

When something comes into your mind fully formed and you are making up some kind of reason for it, it came from the subconsciousness.
That is, the subconsciousness raised an interrupt on the consciousness once the subconsciousness was done processing whatever it wanted to process (passing a tiny amount of data with it).

Danny Milosavljevic on February 7, 2007 07:07 AM

Similar comments from Peter Varhol, editor of FTPOnline:

http://www.ftponline.com/weblogger/forum.aspx?ID=11&DATE=01/17/2007&blog=#717

--
Don't know where to put yourself in these situations? They are all around you, but they almost certainly have nothing to do with sitting at your desk and coding away for five days a week. There is a Toastmasters session in your cafeteria after hours, a standards committee meeting at your competitor down the street, and a study group in a conference room at lunchtime. Open source projects are begging for help, in testing and documentation writing, if not coding. You can be doing all of these things with an e-mail or two. Yes, work is demanding (I worked twelve hours last weekend, and Nancy Grace is on CNN as I write this), but just doing your job in tech is the surest way to a lengthy stay the unemployment line.
--

Jeff Atwood on February 14, 2007 02:34 PM

I was surfing the comments (still not finished yet) and ended up in a Wikipedia on Dijkstra, and one of his quote:

"Computer Science is no more about computers than astronomy is about telescopes."

Of course, he was talking about computer science, not programming :P

kwonghou on February 18, 2007 08:26 AM

Programming is immaterial.

The entire group of development related professions is problem solving and abstraction with different scopes and different focus.

If you are a good problem solver, the language doesn't matter. A new language is just a different API and rule set (with the implied limitations and pit falls). If you are a good problem solver and good at abstract thinking, the scope doesn't matter either. Programmer, architect, analyst, CTO - solve some set of problems, different scope, different focus, different tools.

I think that what is happening is that those who are good at problem solving and abstraction rise quickly, many others are content where their abilities are (some because they think that they are much higher up the food chain than they are), and never strive to become better at these base skills. There are some that recognize that they are lacking, and directly or indirectly improve their abstraction and problem solving abilities and therefor get better. This is an uphill climb, I am sure - looking at and interpreting the world in a different way is not easy, but can be done.

Jeff- if you think that someone is immediately "better than mediocre" because they read a tech blog, you are sorely mistaken. Ability to read != ability to solve problems.

Voice of Reason on March 6, 2007 02:37 PM

I was fascinated at reading the article published in new scientist on the subject of expertise. The conclusion of which was that expertise was a product of motivation.

It's all too easy to categorize people as having or not having some mysterious talent, and although I wouldn't say that there aren't people that are born with innate cognitive abilities, because after all thoughts are dependent on the brain that thinks them, which is itself a biological machine whose nature is subject to genetics. BUT!!!! What the science says is that even this so called 'talent' is merely a head-start, what makes the expert and expert is the motivation and / or inspiration to endure the pain involved with learning more and more new things.

Humans are built for survival and because of this it's normal for us to take the path of least resistance, this is why it you are more likely to hear an insightful response to philosophical questions from a youth than you do from a 40 year old, (well at least in my experience), the youth finds it easier to think out of the box and is motivated to learn new perspectives, whilst the adult has become comfortable with his box and has lost his ability to see why he might want to change it. I suspect most coders are mostly motivated to code in order to make themselves a living amongst other things, it's not that they are unable to be great, they just aren't motivated to be so.

Good programmers aren't people that see the bigger picture, people that see the bigger picture tend to become better programmers (because they are inspired and motivated to do so).

I think that the opinion expressed in this article tends to be born out of a frustration with the unfair reality whereby the motivated experts often go unrewarded for their works of genius whilst at the same time the mediocre's seem to be rewarded for creating bad code.

So, yes, there are definitely good coders, but they are not 'special' per se, they just happen to be an anomalous group of inspired and motivated individuals.

persistent ponderer on April 7, 2007 09:47 AM

What makes anyone really good at what they do is how much they value what they do. If that value is greater than other values then skill will always increase, talent will develop and brilliance will emerge.

How much do you care about your job?

The Spaghettio on April 19, 2007 06:20 AM

There is the question of what is a better programmer, for example in the following who is the better programmer.

Three Programmers A, B and C go for a job interview. They are all required at the same time. The first part of interview process is to write a program. All three programmers are given the same problem and time to complete it.

When the time is up programmers A and B have completed the program and when the company running the interview tests the results they find both A and B have produced programs that produce the correct results although programmer A's programmer is three times faster that and uses half the memory of programmer B's program. Programmer C said he simply could not work out how to solve the problem.

The company had never emplyed a programmer and had the bright idea of asking programmer C to look at the programs of A and C and give them his comments.

After looking at Programmer A's program he said he could not follow the logic and still had no idea how the problem was solved.

After looking at Programmer B's program he said now he understands how the problem was solved and he could now write the program.

So clearly A and B are both good programmers but which is the better programmer?

In some enviroments programmer A would be prefered but my feeling is that most companies would be much better of with programmer B.

Although it can be very satisfying to write a peace of very clever code I feel it is better code if it is clear and easy to understand by other programmers and even yourself in 2 years time.

So the first question is not how to become a better programmer but what is a better programmer.

Brett Collins on April 19, 2007 06:24 AM

I don't think there are better or worse programmers, just more or less creative problem solvers. Programming languages are certainly more complex today with all of the different classes and methods available, but 99% of the time I still use the same commands I used in Microsoft BASIC 1.0. I still use GOSUB...RETURN, except that in today's code the subroutine is tied to an event or object in a GUI. I still use FOR NEXT loops and instead of PEEKS and POKES into memory, I wread and write from/to a relational database. I still use algerbra and calculus to manipulate my data. The only thing that really changes is the business needs and how you go from wher you're at to where you need to go. This is what Bill Gates was talking about. Are you a programmer or an architect?

Joshua Pery on April 19, 2007 07:52 AM

To me programming is about being in a mental zone, much like an artist, a guitarist, a writer, etc. It's about creating something useful and/or entertaining from nothing. One moment your editor screen is blank and the next moment it contains a function that transforms data into magic. Programming allows us to exercise the part of us that makes us superior to all other life forms.

I've been programming since 1980 (Z-80 assembler) but have been programming professionally for only 1.5 years. In college, I was continually tops in my computer courses--certainly not a result of my memory (it is poor) but rather because I "get it." Learning new programming languages comes easily for me because it makes sense to my logical brain. It could be assembler, c/c++/c#, VB (ugh), Java, etc—it’s not the syntax that matters. What matters is the problem-solving ability that generates into code. Great programmers have great problem-solving ability, at least when it comes to code. But ask me to replace front disc brakes or replace a ceiling fan and I'll struggle. Thus, I am great at programming (IMHO) but am challenged in other areas. No matter how much I practice, I'm never going to be a Liberace or Elton John on the piano. The piano is analog and my noggin doesn't process that communication medium very well.

I find the "average" programmer is pretty good at his/her craft but lacks a perfectionist attitude. I am big on writing code that is well structured, well documented, and well executed. As I told my boss early in my career, I don't know how to write crappy code quickly so if you want me to learn then you're going to have to teach me.

Average programmers rely on debuggers and code analyzers to identify flaws but great programmers can write great code inherently. Not to say they don't use debugger/analyzers (they ARE perfectionists) but those tools find much less to scream about in the latter case.

I also find that average programmers stop asking Why/How when they find a solution to a problem. I push further upstream to find answers to deeper questions. I want to know Why this works or How that black box is doing whatever it is doing.

Just as there are great leaders, great communicators, great poets, etc, there are great programmers. Not everyone agrees on what makes them great or what constitutes greatness but history will record their relative value.

troyS++;


“What is not documented is not done”

Troy S. on May 4, 2007 02:45 PM

find the "average" programmer is pretty good at his/her craft but lacks a perfectionist attitude. I am big on writing code that is well structured, well documented, and well executed. As I told my boss early in my career, I don't know how to write crappy code quickly so if you want me to learn then you're going to have to teach me.

freeporn on June 1, 2007 09:50 PM

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

Very wise.

rvdavid on November 28, 2007 04:56 AM

you scared the hell out of me with you introduction...

then talking about passion made my eyes shines ...

i can recall, every time i felt enjoying programming, was in a field that i loved and understood ( mainly local graphical modeling application )

thanks for this post !

fasteez on January 7, 2008 04:31 PM

interesting, a lot of it is simply true...
some few facts can be questioned,
anyway, a very instersting point of view.

edo on January 8, 2008 05:10 AM

>> a 'good developer' ... develops code that doesn't
>> hog the system's resources ... minimum number of
>> lines of code and in minimum time.

This is the worst definition possible. It's the exact opposite of the point Jeff was making. In order to be a good programmer, you have to *stop* obsessing soley about those programming-related metrics, and come up for air to observe what your users want, what your customers do, how your business works and how your customer's businesses work, where your industry niche is heading.

How about defining a good programmer as someone who can reliably produce programs which are useful enough to more than offset the costs of the time spent creating it?

Jonathan Hartley on February 8, 2008 05:34 AM

I was recently explaining to some interviewers, who, after reviewing my resume, remarked upon all my computer related endeavors. They kept asking me about several trivial aspects of the position and whether I thought that 'with my background', I could accomplish the task. It may have seemed obvious to them that I was holding back a chortle or snicker because I realized that they were already pigeon-holing me like many people I know often do. They don't understand that I'm not interested in the actual computer but its versatility. The computer is a tool, that when well honed allows anyone in any field to become more productive. Being a programmer allows me to go through many different fields, sort of like an actor, for as long as the project is in development. Afterwards, I use the talent to explore some other interest. I have not been contacted as yet. :(

Ezrad Lionel on February 10, 2008 07:39 PM

I think some very good points have been made. But lets be clear about one thing though. There is no such thing as a professional programmer/developer working in the industry; they're actually software engineers.

A software engineer working in the industry doesn't just spend his/her time coding all day: documentation must be written, creating test strategies for the code, communicating with colleages & clients, understanding the client's actual issue/requirements, dealing with incompetent management, resolving disagreements etc. Improving all of these areas helps you become engineer.

Having said that though, I do believe that you can improve your coding skills. As others have pointed out the most important factor is dedication. I don't think it's a coincidence that the best programmers out there also tend to view programming as a hobby. No matter what field you work in you can't improve unless you are willing to learn and work hard. As as long as you keep finding challenges for yourself, you'll keep improving.

Keep learning new material that changes the way you think about programming. This will actually change the way you think about problems and the way you come up with solutions for them.

evil bob on February 14, 2008 05:52 PM

Brett Collins on April 19, 2007 06:24 AM:

"In some enviroments programmer A would be prefered but my feeling is that most companies would be much better of with programmer B."

Right, and that's how we get platforms implementing Shellsort instead of Quicksort. Thank you for your insight, now I understand better why our industry really suffers.


Jeff Atwood on January 30, 2007 10:41 AM:

"Nobody can tell a 99.5th percentile coder from a 98th percentile coder."

Wrong. I can tell the difference, and so can they. But Brett Collins has kindly pointed out why they and I are both unemployable.

98 on February 15, 2008 12:52 AM







(hear it spoken)


(no HTML)




Content (c) 2008 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved.