10 ms·

How To Become A Better Programmer By Not Programming

152 points by davidjnelson 15y ago

riledhel 15y ago
I'll just keep the "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." quote. I think that's the main point of the article. Also, the article is more than four years old, I'd like to read what he thinks now or five more years from now.
szany 15y ago
"When, in the late sixties, it became abundantly clear that we did not know how to program well enough, people concerned with Programming Methodology tried to figure out what a competent programmer's education should encompass. As a result of that effort programming emerged as a tough engineering discipline with a strong mathematical flavour. This conclusion has never been refuted, many, however, have refused to draw it for the unattractiveness of its implications, such as 1. good programming is probably beyond the intellectual abilities of today's "average programmer" 2. to do, hic et nunc, the job well with today's army of practitioners, many of whom have been lured into a profession beyond their intellectual abilities, is an insoluble problem 3. our only hope is that, by revealing the intellectual contents of programming, we will make the subject attracting the type of students it deserves, so that a next generation of better qualified programmers may gradually replace the current one. The above implications are certainly unattractive: their social implications are severe, and the absence of a quick solution is disappointing to the impatient. Opposition to and rejection of the findings of programming methodology are therefore only too understandable. We should remember that the conclusion about the intrinsically mathematical nature of the programming task has been made on technical grounds, and that its rejection is always for political or emotional reasons." EWD611 (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD611.html http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EW...)
- cageface 15y ago
  Some of the most productive programmers I've known toss code together in a horrifying slapdash fashion but somehow get great things done. And sometimes people with far more precise and mathematical minds just get mired in their beautiful architectures. The common trait I've seen in all exceptional programmers is an ability to keep a tremendous number of details in memory at one time. Most real world code is not lambda calculus but a barely controlled mess. Humanizing technology is a bigger win than technologizing humans, IMO.
  - mariusmg 15y ago
    "Most real world code is not lambda calculus but a barely controlled mess." Beautifully put.
  - Chirono 15y ago
    The common trait I've seen in all exceptional programmers is an ability to keep a tremendous number of details in memory at one time Would you care to elaborate on this? I'm a programmer with 'precise and mathematical mind' and I'd say that my one big weakness is exactly that: I struggle to large numbers of disconnected facts in my head at one time.
    - cageface 15y ago
      Most programming tasks involve reconciling a bunch of competing constraints. Abstraction techniques make it easier to deal with subsets of those constraints but abstractions leak and even well abstracted software still involves the interactions of many small pieces. This is why it takes 20-30 minutes to get your head into a programming problem - you have to pull enough of that problem space into your head to start manipulating it. The best programmers can get into that space faster and pull a bigger chunk of a system into their heads at one time. This is why they don't necessarily write clean code because they don't have to. The less gifted of us need strong abstractions and code discipline or we just can't keep up. This is why somebody like Linus Torvalds can afford to be disdainful of a lot of common practices in software - he doesn't need the extra help those practices provide. And all this happens well above the level of a strong mathematical formalism.
wyclif 15y ago
You can only complement and enhance your existing programming skills by branching out. A big part of that branching out in my opinion is expanding vistas in areas unrelated to engineering, like reading good literature, creating or appreciating art, and travel.
- peteretep 15y ago
  I've not found this to be true. I'd like it to be true, but I don't think it is. When I try new programming methodologies, ideas, etc, I often notice a distinct change in how I program and how I think about programming. When I try new life choices (emmigrating to the third world, reading good literature, etc) I grow as a person, but I really can't think of how it's affected my programming.
  - jwingy 15y ago
    Maybe the point is that, programming isn't all coding, but also talking, connecting, and relating with other people you're working with, working for, and those that you're building a product for. Growing as a person I think does help in those aspects.
    - davidjnelson 15y ago
      great analysis
- mattgreenrocks 15y ago
  I've wondered if engineering/CS undergrads should be forced to take a Design 101 class to learn: * design is everywhere * having a sense of taste is vital to anyone who makes things * end users are severely affected by every design decision you make I run into too many engineers that try to disregard the subjective aspects of development (architecture/UX/etc) because they believe the only worthwhile things are the logical ones.
  - EponymousCoward 15y ago
maeon3 15y ago
Programming is about representing the world with structures that are adaptable to how the world really changes, so it pays off to read books about human psychology (normal and abnormal), statistics, game theory, and war. When you get a intuitive feeling for how the world morphs and changes around you according to stimuli, then better code structures strike you, and those superior code structures will have much longer lifespans and will be more adaptable to the needs that the users don't know they have yet. It's all about predicting the future, and in order to predict the future of a complex worldly system, you have to KNOW it inside and out.
yaongi 15y ago
So many sentences in bold, yet so little substance. What he seems to be saying is that to be a better interface between development and customers/management/etc requires more than pure programming ability. Yeah, ok. And maybe this is beneficial for business or, if there really is a lack of this talent, for career prospects. But it's not being a better programmer. The pithy title is not very relevant to the content. As regards the pithy title though, and the earlier part of the article, I disagree. Programmers can and do develop. There is a large difference in ability between people who stick with the craft for a large number of years (and actively develop their abilities), and those who are new to it. When I was younger I would have probably agreed, yeah, programmers are just good or bad (and I'm good). But I wasn't good. I've become better since. And there's still a lot to learn and pursue. It takes time. Having said that, it's definitely possible not to progress as a developer despite programming every day. It requires some amount of contemplation.
St-Clock 15y ago
"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." This is a very condescending look on humanity and I did not know that Jeff had said such things. To anyone thinking the same, let me introduce you to the concept of deliberate practice (how to really improve a skill) and please, even if it wasn't published then, read "Talent Is Overrated" by Geoff Colvin. This will probably change your perception on things like excellence, creativity, so-called "talent" and whether it's true that you must be born a genius to become one. And by the way, that does not mean that everything is an american dream and that anyone can become a self-made person. Geoff shows through many examples and studies in his book that superstars in music, sports, and science had an exceptional learning environment in their childhood. They did not suffer from hunger and extreme poverty. He also talk about a study that demonstrated that ordinary people could increase their short term memory (remembering up to 100 items if I recall correctly, no pun intended) by doing deliberate practice.
- silverbax88 15y ago
  When I was first starting as a programmer, I would have agreed with you. But over the years I've learned that it is 100% accurate that some people can program while others simply cannot. But it's not a matter of stupid/smart. It's actually the same reason why Paul Graham's 'Hackers and Painters' analogy is so apt. The reality is that some people can think in abstract terms, while others cannot. Someone who can think in abstract terms can be a graphic artist or a programmer. Consider that even in mathematics, the most concrete things are numbers, which are completely abstract. If you understand that, then guess what? You can think in abstract terms.
  - St-Clock 15y ago
    I completely agree with you that some people, right now, cannot think in abstract terms. My point though, is that they could learn it through deliberate practice, unless they have a severe medical condition that affect the way they think. Maybe they don't know they can learn it (possibly because others have told them that they would never get it), maybe they try hard but fail to do deliberate practice (which is different than programming every day), maybe they aren't interested and still want to have a programming job (that's a problem and they should be redirected to a more appropriate position). Another book I really like to recommend for people who hate maths or don't understand them is Innumeracy by John Allen Paulos. It really helps you get a more positive view on maths. The sequel, Beyond Numeracy, is less groundbreaking though.
rickmb 15y ago
This article just confirms my notion that in the debate about "what makes a great programmer" there is a fundamental disconnect between the concepts of being "a programmer" and being "a maker of software". Making software consists of way more than just programming, and in that respect I agree with Atwood. However, that ignores two other things I consider to be proven truths: 1. You don't have to be a great programmer to make great software. Some of the best products are build from horrible code, not just by people who deliberately rushed things, but by people who simply didn't know any better. 2. You can definitely become a better programmer by simply practicing the craft a lot, even after many years. It doesn't however make you a better "maker of software", just a better coder.
- gaius 15y ago
  It's the difference between a musician and a composer. They overlap often and both are absolutely essential to the performance. But practicing one doesn't necessarily carry over to the other.
- cloudhead 15y ago
  But he's not talking about becoming a better programmer. He's talking about becoming great. Not all software can afford to be made out of crappy code either. There are many fields in which being a good programmer is the same thing as being able to write good software. The web might be the exception here.
  - 16s 15y ago
    The phrase "crappy code" is subjective and not easily measured. What you consider "crap" may be pure art to the people that produced it. Perhaps you just lack their perspective? Perhaps you've never had to write code in that language or at that scale? Perhaps they are just learning to code? The world is bigger than individuals. Some code may be "crap" to you, but let me assure you that your code is "crap" to someone else. Linux kernel code is often called "crap" by the OpenBSD developers. In their mind it is. I'm sure Linux kernel devs feel otherwise and in places where they aren't proud of it, they slowly improve it to make it better. Oh, and BTW, the "crap" that is the Linux kernel supports far more hardware than OpenBSD will ever support. So in my mind, it's all a matter of perspective and goals. Nothing is "crap". And calling it "crap" is wrong and may cause others to feel bad about themselves and their project. It's juvenile and unnecessary. If you are interested in the project and think it's "crap" do something constructive, submit your glorious code to make it better and to enlighten us all.
philjr 15y ago
I make the distinction between "Programming" and "Development" in my own head. In fact, I try to avoid using the phase programming, I call it coding. i.e. putting the code on the screen with a keyboard. I see Jeff talking more about "development" here - coders get better at coding by writing and reading more code. But there's no point being good at putting code on the screen if it doesn't do the thing your end users need to do.
viandante 15y ago
Why people are so focused on the top x% of something? I really don't see the point. Sometimes what you need is a person with great ideas, not a top x% that believes to be some sort of god.
edw519 15y ago
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. What a scary thought. Good thing it's not true. One of the many reasons I became a programmer was that the sky was the limit. Still is. Want to learn something new? Learn it. Want to build something cool? Build it. The only real limitations are your belief that you can do it and your willingness to perservere until you do. We are not like basketball players or musicians or chess masters where only the extremely gifted (who also work hard) can rise to the top of their craft. With few exceptions, we all can. I didn't always think this way. I had a college math professor who once said, "Many of my students are simply not suited for the sciences." And I was stupid enough to believe him! In retrospect, his comment said more about his weakness as a teacher than anything about his students. How do I know this? Because I learned the hard way. When working with my first mentor, I was always too quick to blame someone else for their limitations slowing progress. Until he said, "So teach them!" He believed that almost anyone can learn and get good at almost anything. This seemed counterintuitive but after a while, I was able to adopt this belief system, and it has made all the difference. There are many reasons why so many programmers suck, but "not being able to cross the chasm" isn't one of them. Just a few of the real reasons: - They never learned right in the first place. - They never built anything of real substance. - They were a tiny cog in a machine and never saw the big picture. - They got pigeon-holed into a small area for a long time. - Other things in their life took over. - They had shitty teachers. - They had to build on top of pre-existing shit and couldn't do it right. - They were stuck in environments where excellence never mattered. - They went into management too soon. - They got trapped into old technologies and methodologies. - They made too much money to make a career u-turn. - They just didn't care enough. - <add your own> My programming has always gotten better every year. Sometimes I read my old code and can't believe I wrote it. And I still have tons of room for improvement. I'm firmly convinced that almost any of us can get better, much better. And even become "elite", whatever that means. Please don't listen to anyone else who tells you otherwise.
- ayanb 15y ago
  > 'They never learned right in the first place.' I can relate this to a game of Table Tennis. A guy I know played lousy for two decades, his technique never improved. Then one day he got hold of a masterful neighbor who taught him how to play, hit top spins, do spin serves, hit chops. He participates in amateur tournaments now and does fairly well.
rubyinghana 15y ago
One company tell me I'm bad programmer, then other company teach me Ruby in Rails. Now everything wonderful.
geek_silk 15y ago
What bill is talking about programmers at MS or any big company like facebook, google etc just like super start sports person or musician, but in general there are lots of requirement of programmers who don't need to those kind of super programming skill but programming with business value. Comparing programming with sports is not a good idea because you are comparing super start sport person with avg programmers. Even in sports or other fields there are people who were avg or above avg sport person but latter they become great coach . So it is quite subjective. If your heart say you can become programmer and you are doing enough for the same and you are improving day by day then you are on right track. In my view just writing code is defiantly not going to make good programmer. Code, understanding end user and domain is going to make you better software maker.
agentultra 15y ago
Programmers are not born. They're made. You may have a certain aptitude or talent for software development. However talent without discipline fizzles out or produces wildly varying results. Talent is like that. What makes a good programmer, mathematician, sports player, etc is discipline. The love of the craft/sport/etc that pushes a person to believe that all the discipline and hard work is worth it. People are naturally lazy. However if they really believe in something they will work on it and become better.
- cloudhead 15y ago
  I completely agree, but at the same time, discipline alone doesn't make a good programmer. You need the other half.
  - agentultra 15y ago
    I think you can become a great programmer without any natural talent for it at all. I just don't think you'll find it that interesting... so staying disciplined will probably be very masochistic.
coliveira 15y ago
I think this article says more about the corporate culture where programmers work than about their capacity. What happens in Microsoft, as in most other companies, is that they make a decision about what a person can do in about 1 to 3 years. After that period, they will no longer give exciting assignments to the programmer and he will be forever viewed by management as doing the same old job. Many times this happens because of lack of determination from the part of the employee, but frequently because he didn't have the right opportunities and didn't know how to look for them. Usually when this happens, either the employee will leave the company in a short period, looking for better opportunities, or resign itself to do the same thing until retirement (or until he gets lucky).
jeffreymcmanus 15y ago
The fact that programmers tend to not get better has little to do with programmers' inherent worth or talent. It has everything to do with how programmers are trained. Employers are doing less and less to train their technical staffs, which has fostered a generation of programmers who believe that the right way to learn something is by Googling it or experimenting randomly on their own. Of course you're not going to get better this way.
- cloudhead 15y ago
  Part of talent is knowing how to learn the right way.
  - jeffreymcmanus 15y ago
    Maybe true, but "knowing how to learn" doesn't completely cover it. It's absolutely possible to make middle-of-the-road developers into good developers through training and mentorship. It's just that many (possibly most) developers don't get opportunities for good training. They're expected to use their "talent" to figure things out on their own, which in most cases means Googling or trial-and-error experimentation. These are among the poorest, least efficient ways to learn.
    - cloudhead 15y ago
      I agree, it's sad that not everyone gets the opportunity to have a great mentor. But somehow, when it's meant to be, most will still push through.
      - Morcane 15y ago
        You sound like my manager, refusing all requests for training, and saying 'HANG IN THERE BUD' all the time.
    - davidjnelson 15y ago
      I think it comes down to drive. If you want it bad enough you'll figure it out. Don't understand the difference between the stack and the heap? Read about it for 4 hours after work, etc. etc. etc.
asimjalis 15y ago
There are two types of people: those who peak early and those who evolve gradually but steadily over a longer period.
- dj_axl 15y ago
  This is missing what I will quote from another post above "If they really believe in something they will work on it and become better." If you peak at something this makes you good. If you work ard at something this makes you good. If you peak at something and work on it and become better, this makes you great. Evolving gradually but steadily might increase one's belief that hard work is rewarded, however you will never become great, merely good.
cloudhead 15y ago
There's definitely a confusion between "product designer" and "programmer". Sometimes they are the same thing, other times not. So I don't think it's a useful metric. There are truly great programmers... Andrew Appel, SPJ, McCarthy etc who have no need or interest in making "products", yet that doesn't disqualify them from being great. Sure, communication skills are important, especially writing, but I wouldn't push the idea much further.
csomar 15y ago
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. Not true with the current neuroscience. Well, in reality, that's what is happening. But do you know why? I'll tell you: Because I'm obsessed with programming. The typical programmer that is not obsessed will just make use of the skills he got while programming and learning. These skills are limited to the time he spent learning/coding. I'm obsessed; I learn and code even when I'm not in front of the computer.The time of my experience expand. Add to that, the fact that I'm obsessed. I'll brainstorm code/ideas/tricks/google... to get that thing working. I'll make any opportunity in life to learn more about programming. This gives me advantage over that typical programmer that disconnects when he quits his job.
montages 15y ago
Umm... that pours the whole theory of deliberate practice and (more importantly) rocky style style montages for programming down the toilet.
choxi 15y ago
I hate that Bill Gates quote, why would you cite the opinion of a guy who isn't known for his programming ability nor has any history of hiring good programmers?
- gwern 15y ago
  Well, the thing is, Gates was an expert programmer. His coding on BASIC was impressive. He transitioned to management pretty quickly, but that doesn't mean much.
snarfy 15y ago
Part of the controversy with this article is that it is combining two separate ideas into one concept, blurring the differences. Implementing software is something you can absolutely get better at with experience, discipline, and practice. You only need to look at your old code for evidence of this. Designing software takes imagination and creativity. Experience and practice may give you a tool chest of preconceived ideas to use when designing your own software, but it isn't going to help you conceive completely new ideas yourself. That requires thinking outside of the box, and it's not something you learn by studying the nuances of implementation. It's not even something you learn by studying programming. IMO this is what Atwood is talking about.
alecco 15y ago
The "gift" is borderline-masochistic obsession coupled with good abstract thinking.
kragen 15y ago
Well, I may not be a great programmer, but after programming for 30 years, I'm a hell of a lot better than I was after programming for three or four years. The story of my evolution as a programmer is at http://lists.canonical.org/pipermail/kragen-tol/2007-March/000849.html http://lists.canonical.org/pipermail/kragen-tol/2007-March/0.... Even after 25 years, I was doing things that I didn't have the knowledge or skill to do five years before. (On the other hand, sometimes I look at kragen-hacks posts from ten years ago and say, "Whoever did that must be a lot smarter than I am ---" before remembering it was me.)
- Revisor 15y ago
  Thank you for the high-level overview and the book recommendations in your post.
  - kragen 15y ago
    I'm glad you enjoyed it!
leon_ 15y ago
So at least Mr. Atwood can now stop pretending being a programmer.
gwern 15y ago
Times like this, I wish everyone could be made to read _The Cambridge Handbook of Expertise and Expert Performance_ ( http://dl.dropbox.com/u/5317066/cambridge-expertise.pdf http://dl.dropbox.com/u/5317066/cambridge-expertise.pdf ) or at least the original deliberate-practice paper ( http://www.gwern.net/docs/1993-ericsson-deliberatepractice.pdf http://www.gwern.net/docs/1993-ericsson-deliberatepractice.p... ).
deleted 15y ago
[deleted]
usedtolurk 15y ago
Maybe 4 years at Microsoft is enough to tell if you have what it takes, but I doubt it. If you work elsewhere you can find yourself moving backwards if you're surrounded by poor practises, particularly early on in your career. My programming wasn't much cop to begin with and declined in the first 4 years of my career. After 8 years it leaped forward when I read Code Complete (by Steve McConnell). Only later on, when I was maintaining other peoples code rather than writing from scratch, did I realise the pain I had been inflicting on others earlier on. Another leap occurred when I found myself as the most senior programmer in a (small) company - when the buck stops with you, you're forced to stretch. My every day programming has also been improved by my attempts at architecture. Its taken me about 15 years to feel reasonably confident and I can't be the only slow learner out there. So although I disagree with Jeff Atwood that you either have it or you don't, I suppose he does have a point - it was largely non-programming tasks that were the break-throughs. It can be tempting to write-off a junior programmer as having no hope but I was that guy once and I came right eventually - there is hope for everybody.

152 points by davidjnelson 15y ago

I'll just keep the "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." quote. I think that's the main point of the article. Also, the article is more than four years old, I'd like to read what he thinks now or five more years from now.

szany 15y ago

"When, in the late sixties, it became abundantly clear that we did not know how to program well enough, people concerned with Programming Methodology tried to figure out what a competent programmer's education should encompass. As a result of that effort programming emerged as a tough engineering discipline with a strong mathematical flavour. This conclusion has never been refuted, many, however, have refused to draw it for the unattractiveness of its implications, such as 1. good programming is probably beyond the intellectual abilities of today's "average programmer" 2. to do, hic et nunc, the job well with today's army of practitioners, many of whom have been lured into a profession beyond their intellectual abilities, is an insoluble problem 3. our only hope is that, by revealing the intellectual contents of programming, we will make the subject attracting the type of students it deserves, so that a next generation of better qualified programmers may gradually replace the current one. The above implications are certainly unattractive: their social implications are severe, and the absence of a quick solution is disappointing to the impatient. Opposition to and rejection of the findings of programming methodology are therefore only too understandable. We should remember that the conclusion about the intrinsically mathematical nature of the programming task has been made on technical grounds, and that its rejection is always for political or emotional reasons." EWD611 (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD611.html http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EW...)

cageface 15y ago
Some of the most productive programmers I've known toss code together in a horrifying slapdash fashion but somehow get great things done. And sometimes people with far more precise and mathematical minds just get mired in their beautiful architectures. The common trait I've seen in all exceptional programmers is an ability to keep a tremendous number of details in memory at one time. Most real world code is not lambda calculus but a barely controlled mess. Humanizing technology is a bigger win than technologizing humans, IMO.
- mariusmg 15y ago
  "Most real world code is not lambda calculus but a barely controlled mess." Beautifully put.
- Chirono 15y ago
  The common trait I've seen in all exceptional programmers is an ability to keep a tremendous number of details in memory at one time Would you care to elaborate on this? I'm a programmer with 'precise and mathematical mind' and I'd say that my one big weakness is exactly that: I struggle to large numbers of disconnected facts in my head at one time.
  - cageface 15y ago
    Most programming tasks involve reconciling a bunch of competing constraints. Abstraction techniques make it easier to deal with subsets of those constraints but abstractions leak and even well abstracted software still involves the interactions of many small pieces. This is why it takes 20-30 minutes to get your head into a programming problem - you have to pull enough of that problem space into your head to start manipulating it. The best programmers can get into that space faster and pull a bigger chunk of a system into their heads at one time. This is why they don't necessarily write clean code because they don't have to. The less gifted of us need strong abstractions and code discipline or we just can't keep up. This is why somebody like Linus Torvalds can afford to be disdainful of a lot of common practices in software - he doesn't need the extra help those practices provide. And all this happens well above the level of a strong mathematical formalism.

wyclif 15y ago

You can only complement and enhance your existing programming skills by branching out. A big part of that branching out in my opinion is expanding vistas in areas unrelated to engineering, like reading good literature, creating or appreciating art, and travel.

peteretep 15y ago
I've not found this to be true. I'd like it to be true, but I don't think it is. When I try new programming methodologies, ideas, etc, I often notice a distinct change in how I program and how I think about programming. When I try new life choices (emmigrating to the third world, reading good literature, etc) I grow as a person, but I really can't think of how it's affected my programming.
- jwingy 15y ago
  Maybe the point is that, programming isn't all coding, but also talking, connecting, and relating with other people you're working with, working for, and those that you're building a product for. Growing as a person I think does help in those aspects.
  - davidjnelson 15y ago
    great analysis
mattgreenrocks 15y ago
I've wondered if engineering/CS undergrads should be forced to take a Design 101 class to learn: * design is everywhere * having a sense of taste is vital to anyone who makes things * end users are severely affected by every design decision you make I run into too many engineers that try to disregard the subjective aspects of development (architecture/UX/etc) because they believe the only worthwhile things are the logical ones.
- EponymousCoward 15y ago

maeon3 15y ago

Programming is about representing the world with structures that are adaptable to how the world really changes, so it pays off to read books about human psychology (normal and abnormal), statistics, game theory, and war. When you get a intuitive feeling for how the world morphs and changes around you according to stimuli, then better code structures strike you, and those superior code structures will have much longer lifespans and will be more adaptable to the needs that the users don't know they have yet. It's all about predicting the future, and in order to predict the future of a complex worldly system, you have to KNOW it inside and out.

yaongi 15y ago

So many sentences in bold, yet so little substance. What he seems to be saying is that to be a better interface between development and customers/management/etc requires more than pure programming ability. Yeah, ok. And maybe this is beneficial for business or, if there really is a lack of this talent, for career prospects. But it's not being a better programmer. The pithy title is not very relevant to the content. As regards the pithy title though, and the earlier part of the article, I disagree. Programmers can and do develop. There is a large difference in ability between people who stick with the craft for a large number of years (and actively develop their abilities), and those who are new to it. When I was younger I would have probably agreed, yeah, programmers are just good or bad (and I'm good). But I wasn't good. I've become better since. And there's still a lot to learn and pursue. It takes time. Having said that, it's definitely possible not to progress as a developer despite programming every day. It requires some amount of contemplation.

St-Clock 15y ago

"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." This is a very condescending look on humanity and I did not know that Jeff had said such things. To anyone thinking the same, let me introduce you to the concept of deliberate practice (how to really improve a skill) and please, even if it wasn't published then, read "Talent Is Overrated" by Geoff Colvin. This will probably change your perception on things like excellence, creativity, so-called "talent" and whether it's true that you must be born a genius to become one. And by the way, that does not mean that everything is an american dream and that anyone can become a self-made person. Geoff shows through many examples and studies in his book that superstars in music, sports, and science had an exceptional learning environment in their childhood. They did not suffer from hunger and extreme poverty. He also talk about a study that demonstrated that ordinary people could increase their short term memory (remembering up to 100 items if I recall correctly, no pun intended) by doing deliberate practice.

silverbax88 15y ago
When I was first starting as a programmer, I would have agreed with you. But over the years I've learned that it is 100% accurate that some people can program while others simply cannot. But it's not a matter of stupid/smart. It's actually the same reason why Paul Graham's 'Hackers and Painters' analogy is so apt. The reality is that some people can think in abstract terms, while others cannot. Someone who can think in abstract terms can be a graphic artist or a programmer. Consider that even in mathematics, the most concrete things are numbers, which are completely abstract. If you understand that, then guess what? You can think in abstract terms.
- St-Clock 15y ago
  I completely agree with you that some people, right now, cannot think in abstract terms. My point though, is that they could learn it through deliberate practice, unless they have a severe medical condition that affect the way they think. Maybe they don't know they can learn it (possibly because others have told them that they would never get it), maybe they try hard but fail to do deliberate practice (which is different than programming every day), maybe they aren't interested and still want to have a programming job (that's a problem and they should be redirected to a more appropriate position). Another book I really like to recommend for people who hate maths or don't understand them is Innumeracy by John Allen Paulos. It really helps you get a more positive view on maths. The sequel, Beyond Numeracy, is less groundbreaking though.

rickmb 15y ago

This article just confirms my notion that in the debate about "what makes a great programmer" there is a fundamental disconnect between the concepts of being "a programmer" and being "a maker of software". Making software consists of way more than just programming, and in that respect I agree with Atwood. However, that ignores two other things I consider to be proven truths: 1. You don't have to be a great programmer to make great software. Some of the best products are build from horrible code, not just by people who deliberately rushed things, but by people who simply didn't know any better. 2. You can definitely become a better programmer by simply practicing the craft a lot, even after many years. It doesn't however make you a better "maker of software", just a better coder.

gaius 15y ago
It's the difference between a musician and a composer. They overlap often and both are absolutely essential to the performance. But practicing one doesn't necessarily carry over to the other.
cloudhead 15y ago
But he's not talking about becoming a better programmer. He's talking about becoming great. Not all software can afford to be made out of crappy code either. There are many fields in which being a good programmer is the same thing as being able to write good software. The web might be the exception here.
- 16s 15y ago
  The phrase "crappy code" is subjective and not easily measured. What you consider "crap" may be pure art to the people that produced it. Perhaps you just lack their perspective? Perhaps you've never had to write code in that language or at that scale? Perhaps they are just learning to code? The world is bigger than individuals. Some code may be "crap" to you, but let me assure you that your code is "crap" to someone else. Linux kernel code is often called "crap" by the OpenBSD developers. In their mind it is. I'm sure Linux kernel devs feel otherwise and in places where they aren't proud of it, they slowly improve it to make it better. Oh, and BTW, the "crap" that is the Linux kernel supports far more hardware than OpenBSD will ever support. So in my mind, it's all a matter of perspective and goals. Nothing is "crap". And calling it "crap" is wrong and may cause others to feel bad about themselves and their project. It's juvenile and unnecessary. If you are interested in the project and think it's "crap" do something constructive, submit your glorious code to make it better and to enlighten us all.

philjr 15y ago

I make the distinction between "Programming" and "Development" in my own head. In fact, I try to avoid using the phase programming, I call it coding. i.e. putting the code on the screen with a keyboard. I see Jeff talking more about "development" here - coders get better at coding by writing and reading more code. But there's no point being good at putting code on the screen if it doesn't do the thing your end users need to do.

viandante 15y ago

Why people are so focused on the top x% of something? I really don't see the point. Sometimes what you need is a person with great ideas, not a top x% that believes to be some sort of god.

edw519 15y ago

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. What a scary thought. Good thing it's not true. One of the many reasons I became a programmer was that the sky was the limit. Still is. Want to learn something new? Learn it. Want to build something cool? Build it. The only real limitations are your belief that you can do it and your willingness to perservere until you do. We are not like basketball players or musicians or chess masters where only the extremely gifted (who also work hard) can rise to the top of their craft. With few exceptions, we all can. I didn't always think this way. I had a college math professor who once said, "Many of my students are simply not suited for the sciences." And I was stupid enough to believe him! In retrospect, his comment said more about his weakness as a teacher than anything about his students. How do I know this? Because I learned the hard way. When working with my first mentor, I was always too quick to blame someone else for their limitations slowing progress. Until he said, "So teach them!" He believed that almost anyone can learn and get good at almost anything. This seemed counterintuitive but after a while, I was able to adopt this belief system, and it has made all the difference. There are many reasons why so many programmers suck, but "not being able to cross the chasm" isn't one of them. Just a few of the real reasons: - They never learned right in the first place. - They never built anything of real substance. - They were a tiny cog in a machine and never saw the big picture. - They got pigeon-holed into a small area for a long time. - Other things in their life took over. - They had shitty teachers. - They had to build on top of pre-existing shit and couldn't do it right. - They were stuck in environments where excellence never mattered. - They went into management too soon. - They got trapped into old technologies and methodologies. - They made too much money to make a career u-turn. - They just didn't care enough. - <add your own> My programming has always gotten better every year. Sometimes I read my old code and can't believe I wrote it. And I still have tons of room for improvement. I'm firmly convinced that almost any of us can get better, much better. And even become "elite", whatever that means. Please don't listen to anyone else who tells you otherwise.

ayanb 15y ago
> 'They never learned right in the first place.' I can relate this to a game of Table Tennis. A guy I know played lousy for two decades, his technique never improved. Then one day he got hold of a masterful neighbor who taught him how to play, hit top spins, do spin serves, hit chops. He participates in amateur tournaments now and does fairly well.

rubyinghana 15y ago

One company tell me I'm bad programmer, then other company teach me Ruby in Rails. Now everything wonderful.

geek_silk 15y ago

What bill is talking about programmers at MS or any big company like facebook, google etc just like super start sports person or musician, but in general there are lots of requirement of programmers who don't need to those kind of super programming skill but programming with business value. Comparing programming with sports is not a good idea because you are comparing super start sport person with avg programmers. Even in sports or other fields there are people who were avg or above avg sport person but latter they become great coach . So it is quite subjective. If your heart say you can become programmer and you are doing enough for the same and you are improving day by day then you are on right track. In my view just writing code is defiantly not going to make good programmer. Code, understanding end user and domain is going to make you better software maker.

agentultra 15y ago

Programmers are not born. They're made. You may have a certain aptitude or talent for software development. However talent without discipline fizzles out or produces wildly varying results. Talent is like that. What makes a good programmer, mathematician, sports player, etc is discipline. The love of the craft/sport/etc that pushes a person to believe that all the discipline and hard work is worth it. People are naturally lazy. However if they really believe in something they will work on it and become better.

cloudhead 15y ago
I completely agree, but at the same time, discipline alone doesn't make a good programmer. You need the other half.
- agentultra 15y ago
  I think you can become a great programmer without any natural talent for it at all. I just don't think you'll find it that interesting... so staying disciplined will probably be very masochistic.

coliveira 15y ago

I think this article says more about the corporate culture where programmers work than about their capacity. What happens in Microsoft, as in most other companies, is that they make a decision about what a person can do in about 1 to 3 years. After that period, they will no longer give exciting assignments to the programmer and he will be forever viewed by management as doing the same old job. Many times this happens because of lack of determination from the part of the employee, but frequently because he didn't have the right opportunities and didn't know how to look for them. Usually when this happens, either the employee will leave the company in a short period, looking for better opportunities, or resign itself to do the same thing until retirement (or until he gets lucky).

jeffreymcmanus 15y ago

The fact that programmers tend to not get better has little to do with programmers' inherent worth or talent. It has everything to do with how programmers are trained. Employers are doing less and less to train their technical staffs, which has fostered a generation of programmers who believe that the right way to learn something is by Googling it or experimenting randomly on their own. Of course you're not going to get better this way.

cloudhead 15y ago
Part of talent is knowing how to learn the right way.
- jeffreymcmanus 15y ago
  Maybe true, but "knowing how to learn" doesn't completely cover it. It's absolutely possible to make middle-of-the-road developers into good developers through training and mentorship. It's just that many (possibly most) developers don't get opportunities for good training. They're expected to use their "talent" to figure things out on their own, which in most cases means Googling or trial-and-error experimentation. These are among the poorest, least efficient ways to learn.
  - cloudhead 15y ago
    I agree, it's sad that not everyone gets the opportunity to have a great mentor. But somehow, when it's meant to be, most will still push through.
    - Morcane 15y ago
      You sound like my manager, refusing all requests for training, and saying 'HANG IN THERE BUD' all the time.
  - davidjnelson 15y ago
    I think it comes down to drive. If you want it bad enough you'll figure it out. Don't understand the difference between the stack and the heap? Read about it for 4 hours after work, etc. etc. etc.

asimjalis 15y ago

There are two types of people: those who peak early and those who evolve gradually but steadily over a longer period.

dj_axl 15y ago
This is missing what I will quote from another post above "If they really believe in something they will work on it and become better." If you peak at something this makes you good. If you work ard at something this makes you good. If you peak at something and work on it and become better, this makes you great. Evolving gradually but steadily might increase one's belief that hard work is rewarded, however you will never become great, merely good.

cloudhead 15y ago

There's definitely a confusion between "product designer" and "programmer". Sometimes they are the same thing, other times not. So I don't think it's a useful metric. There are truly great programmers... Andrew Appel, SPJ, McCarthy etc who have no need or interest in making "products", yet that doesn't disqualify them from being great. Sure, communication skills are important, especially writing, but I wouldn't push the idea much further.

csomar 15y ago

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. Not true with the current neuroscience. Well, in reality, that's what is happening. But do you know why? I'll tell you: Because I'm obsessed with programming. The typical programmer that is not obsessed will just make use of the skills he got while programming and learning. These skills are limited to the time he spent learning/coding. I'm obsessed; I learn and code even when I'm not in front of the computer.The time of my experience expand. Add to that, the fact that I'm obsessed. I'll brainstorm code/ideas/tricks/google... to get that thing working. I'll make any opportunity in life to learn more about programming. This gives me advantage over that typical programmer that disconnects when he quits his job.

montages 15y ago

Umm... that pours the whole theory of deliberate practice and (more importantly) rocky style style montages for programming down the toilet.

choxi 15y ago

I hate that Bill Gates quote, why would you cite the opinion of a guy who isn't known for his programming ability nor has any history of hiring good programmers?

gwern 15y ago
Well, the thing is, Gates was an expert programmer. His coding on BASIC was impressive. He transitioned to management pretty quickly, but that doesn't mean much.

snarfy 15y ago

Part of the controversy with this article is that it is combining two separate ideas into one concept, blurring the differences. Implementing software is something you can absolutely get better at with experience, discipline, and practice. You only need to look at your old code for evidence of this. Designing software takes imagination and creativity. Experience and practice may give you a tool chest of preconceived ideas to use when designing your own software, but it isn't going to help you conceive completely new ideas yourself. That requires thinking outside of the box, and it's not something you learn by studying the nuances of implementation. It's not even something you learn by studying programming. IMO this is what Atwood is talking about.

alecco 15y ago

The "gift" is borderline-masochistic obsession coupled with good abstract thinking.

kragen 15y ago

Well, I may not be a great programmer, but after programming for 30 years, I'm a hell of a lot better than I was after programming for three or four years. The story of my evolution as a programmer is at http://lists.canonical.org/pipermail/kragen-tol/2007-March/000849.html http://lists.canonical.org/pipermail/kragen-tol/2007-March/0.... Even after 25 years, I was doing things that I didn't have the knowledge or skill to do five years before. (On the other hand, sometimes I look at kragen-hacks posts from ten years ago and say, "Whoever did that must be a lot smarter than I am ---" before remembering it was me.)

Revisor 15y ago
Thank you for the high-level overview and the book recommendations in your post.
- kragen 15y ago
  I'm glad you enjoyed it!

leon_ 15y ago

So at least Mr. Atwood can now stop pretending being a programmer.

gwern 15y ago

Times like this, I wish everyone could be made to read _The Cambridge Handbook of Expertise and Expert Performance_ ( http://dl.dropbox.com/u/5317066/cambridge-expertise.pdf http://dl.dropbox.com/u/5317066/cambridge-expertise.pdf ) or at least the original deliberate-practice paper ( http://www.gwern.net/docs/1993-ericsson-deliberatepractice.pdf http://www.gwern.net/docs/1993-ericsson-deliberatepractice.p... ).

deleted 15y ago

[deleted]

usedtolurk 15y ago

Maybe 4 years at Microsoft is enough to tell if you have what it takes, but I doubt it. If you work elsewhere you can find yourself moving backwards if you're surrounded by poor practises, particularly early on in your career. My programming wasn't much cop to begin with and declined in the first 4 years of my career. After 8 years it leaped forward when I read Code Complete (by Steve McConnell). Only later on, when I was maintaining other peoples code rather than writing from scratch, did I realise the pain I had been inflicting on others earlier on. Another leap occurred when I found myself as the most senior programmer in a (small) company - when the buck stops with you, you're forced to stretch. My every day programming has also been improved by my attempts at architecture. Its taken me about 15 years to feel reasonably confident and I can't be the only slow learner out there. So although I disagree with Jeff Atwood that you either have it or you don't, I suppose he does have a point - it was largely non-programming tasks that were the break-throughs. It can be tempting to write-off a junior programmer as having no hope but I was that guy once and I came right eventually - there is hope for everybody.