Hamming: "dubious that great programmers can be trained.."
69 comments
I firmly believe great programmers can be trained, but it's not going to happen after six months. I firmly believe in the 10000 hours rule, and I think it applies here as well, but to become a great programmer, that has to be 10000 hours of:
* writing a lot of code,
* reading other people's code,
* evaluating and re-evaluating the code you've written and read,
* learning and using different paradigms, languages and tools, and
* being mentored by a great programmer who can teach.
And, not surprisingly, these are all things that nearly anybody you consider a "great programmer" would have done to get to that point.
Very few people who are not already inclined towards programming are going to be willing to put that kind of effort in. As a result, while I firmly believe great programmers can be trained, I think there are very few who actually are.
In the end, I'm not even sure that "trained" can even be used as a classifier. I think a better classifier would be "self-selection". So, can a person who has not self-selected to be a programmer become a great programmer? Can a person who has not self-selected to become a basketball player become a Michael Jordan? Genetics may say yes one in a billion times, but most likely not.
It may be easier for programming, thou, because you can spread those 10000 hours out over 15 years while still making a reasonable salary utilizing the mediocre skills you have today. Salary is a strong motivator, but I would be most people are willing to stay at the mediocre level.
* writing a lot of code,
* reading other people's code,
* evaluating and re-evaluating the code you've written and read,
* learning and using different paradigms, languages and tools, and
* being mentored by a great programmer who can teach.
And, not surprisingly, these are all things that nearly anybody you consider a "great programmer" would have done to get to that point.
Very few people who are not already inclined towards programming are going to be willing to put that kind of effort in. As a result, while I firmly believe great programmers can be trained, I think there are very few who actually are.
In the end, I'm not even sure that "trained" can even be used as a classifier. I think a better classifier would be "self-selection". So, can a person who has not self-selected to be a programmer become a great programmer? Can a person who has not self-selected to become a basketball player become a Michael Jordan? Genetics may say yes one in a billion times, but most likely not.
It may be easier for programming, thou, because you can spread those 10000 hours out over 15 years while still making a reasonable salary utilizing the mediocre skills you have today. Salary is a strong motivator, but I would be most people are willing to stay at the mediocre level.
Two things people who put 10,000 hours have in common are:
- They are naive and believe they can conquer the world - or are discouraged about their original inability and hide it.
- They share a sense of destiny in what they do. They can't imagine a world where they wouldn't be working any more in their medium.
So if you wanted to predict who will become a great programmer you could look for naivety and commitment. You could look for people who can't tell what they've accomplished. And which continue to obliviously work on (naively ambitious) things only because noone was around to stop them.
- They are naive and believe they can conquer the world - or are discouraged about their original inability and hide it.
- They share a sense of destiny in what they do. They can't imagine a world where they wouldn't be working any more in their medium.
So if you wanted to predict who will become a great programmer you could look for naivety and commitment. You could look for people who can't tell what they've accomplished. And which continue to obliviously work on (naively ambitious) things only because noone was around to stop them.
On (1) I point out naivety in particular because it's the most transparent and one of the most shocking. It's what you do not expect someone very capable to be. Paradoxical traits of personality in creative people are common.
On (2) MacKinnon suggested the successful creative individual had an ongoing belief in the worth of their creative efforts.
I don't claim these are the only two things to predict who will become a great programmer.
http://arrow.dit.ie/cgi/viewcontent.cgi?article=1005&con...
On (2) MacKinnon suggested the successful creative individual had an ongoing belief in the worth of their creative efforts.
I don't claim these are the only two things to predict who will become a great programmer.
http://arrow.dit.ie/cgi/viewcontent.cgi?article=1005&con...
Interesting, are you that kind of guy?
If you spend 10.000 hours playing the same simple tune on a guitar you're not going to be a great musician. Similarly, if you spend 10.000 hours programming the same mediocre kind of code, you will not have become a great programmer.
Programming is a craft, and like any craft it requires dedication to the craft to achieve a high level of skill in it. People without a passion for programming are not going to have that dedication, and therefore will not reach a high skill level.
Programming is a craft, and like any craft it requires dedication to the craft to achieve a high level of skill in it. People without a passion for programming are not going to have that dedication, and therefore will not reach a high skill level.
I'm not sure how you could spend 10000 hours programming the same mediocre code if you were actually doing the things I outlined. The whole point of the list is to ensure you aren't spending the time doing that.
I can't tell if you are disagreeing with me or not (I think you are), because you've said almost the same things I did. What you call dedication, I call self-selection.
I can't tell if you are disagreeing with me or not (I think you are), because you've said almost the same things I did. What you call dedication, I call self-selection.
One of the assumptions of the 10,000-Hour Rule, as Malcolm Gladwell asserts, is that a person spending 10,000 hours on an activity naturally has a strong proclivity for it.
So working off that assumption:
IF 10,000 hours = passion
AND passion = great at a craft
THEN 10,000 hours = great at a craft
So working off that assumption:
IF 10,000 hours = passion
AND passion = great at a craft
THEN 10,000 hours = great at a craft
That assumption is obviously wrong when you mix financial compensation into it.
I've worked with more than a few programmers who were in it for a paycheck, some of them were perfectly competent at creating code for their little niche (CRUD apps, whatever), but were single-language, single-framework, lots-of-maintenance types of guys.
Needless to say, them putting 10,000 hours into programming isn't the same as someone who is really passionate about it.
To paraphrase: "Some people put in 10,000 hours, some people put in 1000 hours 10 times".
I've worked with more than a few programmers who were in it for a paycheck, some of them were perfectly competent at creating code for their little niche (CRUD apps, whatever), but were single-language, single-framework, lots-of-maintenance types of guys.
Needless to say, them putting 10,000 hours into programming isn't the same as someone who is really passionate about it.
To paraphrase: "Some people put in 10,000 hours, some people put in 1000 hours 10 times".
[deleted]
[deleted]
"It usually takes me more than three weeks to prepare a good impromptu speech." -- Mark Twain
http://www.movesinstitute.org/~mcgredo/HammingLearningToLear...
http://www.movesinstitute.org/~mcgredo/HammingLearningToLear...
That's a great write-up. Thanks!
"I made the comparison of writing software with the act of literary writing; both seem to depend fundamentally on clear thinking. Can good programming be taught? If we look at the corresponding teaching of "creative writing" courses we find that most students of such courses do not become great writers, and most great writers in the past did not take creative writing courses! Hence it is dubious that great programmers can be trained easily."
That's just a staggering misuse of "hence".
That's just a staggering misuse of "hence".
[deleted](1)
HackerNews has always been enamored with the perception of the so called Great Programmer that seemed to attract the next logical discussions: productivity and compensation.
In a big scale software product, great programmer is only marginally important. In a startup, great programmer is definitely useful provided they do not come with "baggages" and asking for top notch compensation (how would you maintain your company's financial health if you are paying him tons of money and giving him stocks while it is your dream, passions, goals, and livelihood that is on the line).
Programmers love to talk about great programmer because that is their dream: fame, money, and freedom.
The real great programmers keep writing good code and act normally like any other workers...and I do not think that the bar is that high...most of us painted it otherwise.
In a big scale software product, great programmer is only marginally important. In a startup, great programmer is definitely useful provided they do not come with "baggages" and asking for top notch compensation (how would you maintain your company's financial health if you are paying him tons of money and giving him stocks while it is your dream, passions, goals, and livelihood that is on the line).
Programmers love to talk about great programmer because that is their dream: fame, money, and freedom.
The real great programmers keep writing good code and act normally like any other workers...and I do not think that the bar is that high...most of us painted it otherwise.
I don't think you should underestimate the essential contributions that great programmers make to large-scale software products. They can:
- Keep the entire system in their heads, which is of great help to other programmers who have questions about how the code works.
- See several steps ahead and thus avoid pitfalls that may not be obvious to others.
- Design stable and maintainable architectures.
- Debug nasty bugs that others on the team may never be able to solve.
- Mentor less-advanced programmers.
Without at least a handful of really good programmers to lead the way, a large development project probably has a very small probability of success.
- Keep the entire system in their heads, which is of great help to other programmers who have questions about how the code works.
- See several steps ahead and thus avoid pitfalls that may not be obvious to others.
- Design stable and maintainable architectures.
- Debug nasty bugs that others on the team may never be able to solve.
- Mentor less-advanced programmers.
Without at least a handful of really good programmers to lead the way, a large development project probably has a very small probability of success.
I've yet to meet someone who can keep the entire complex, humongous system in their head (we're talking about a system that have been developed for 5-7 years with at least 20 smart developers where things keep changing/updated/fixed, etc). I think you're stretching that point too far.
Point #2 is more in the experience, a good developer (not necessarily great) can do this in any given day provided that he/she has the right experience. You don't know what you don't know => all others would either be 50-50 or intuition (a.k.a luck).
Point #3 can be done by "good enough" developer as well. The fact that we have plenty "good enough" software systems that requires little to less maintenance running today is a proof of my statement.
Point #4 debugging is about focus and patience. Give it to a decent programmer without time-limit and he'll figure it out, eventually.
Point #5 any decent developer who have good communication skill can do this.
I think we are guilty of underestimating "good" developer and overestimating (or plain worshipping) great developer.
Point #2 is more in the experience, a good developer (not necessarily great) can do this in any given day provided that he/she has the right experience. You don't know what you don't know => all others would either be 50-50 or intuition (a.k.a luck).
Point #3 can be done by "good enough" developer as well. The fact that we have plenty "good enough" software systems that requires little to less maintenance running today is a proof of my statement.
Point #4 debugging is about focus and patience. Give it to a decent programmer without time-limit and he'll figure it out, eventually.
Point #5 any decent developer who have good communication skill can do this.
I think we are guilty of underestimating "good" developer and overestimating (or plain worshipping) great developer.
Note that Hemming is using the word "training" precisely, to contrast with "education":
> * Education is what, when, and why to do things
> * Training is how to do it
> Either one without the other is not much use.Ah. That, then, changes the meaning of this quote entirely. If he's merely saying that training alone, as opposed to a combination of training and education, is insufficient, then that is much more plausible. I was reading the original post as including what he defines here as "education" in "training".
I think what makes one great in craft is deeply caring about the craft. It's not just a means to an end, it is something one truly feels passionate about. When one has that visceral calling for something, I think they find ways to get better at what they do. The greatest attribute of humans is that they adapt and learn.
I know several people who could be great programmers, in terms of the ability to solve complex problems, but they do not care enough about their code to do so; which is fine, they find passion elsewhere.
Programming is not for everyone, but I do think that it can be learned over time with patience, passion, and practice.
I know several people who could be great programmers, in terms of the ability to solve complex problems, but they do not care enough about their code to do so; which is fine, they find passion elsewhere.
Programming is not for everyone, but I do think that it can be learned over time with patience, passion, and practice.
When asked, greater writers and programmers will both emphasize study and practice. They recognize they were once bad writers and programmers and got better via study and practice. I see no reason to doubt these self-reports.
I think Richard Hamming is out of his depth here, as evidenced by his use of naive anecdotes and analogies. If programming is like writing, it is like a severely restricted writing exercise, where you can only use certain grammatical structures, where you have to define a lot of words explicitly and where your stories have to explain to a machine how to achieve a slew of mundane goals.
I think Richard Hamming is out of his depth here, as evidenced by his use of naive anecdotes and analogies. If programming is like writing, it is like a severely restricted writing exercise, where you can only use certain grammatical structures, where you have to define a lot of words explicitly and where your stories have to explain to a machine how to achieve a slew of mundane goals.
I don't know; I've never written much, and I didn't read nearly as much as I should have in my youth, but I always did seem to have a natural propensity for writing. For some kids in my class it was a war. They had to really battle to make the words come out on a page in a way that was as comprehendable as is their vocal speech, but for me I needed only to type and let it flow.
So I while I agree with the notion that one will become better with practice, I question the ideas that all will progress at a similar rate and that the "ceiling" for their abilities are at the same level of skill.
I think a bit of success bias is operating here. If you take the average NBA player and ask him why he made it, he'll likely cite hard work, having a winning attitude, or something to a similar effect. The fact that he is six foot six never enters into the equation. The chances of an athletically gifted giant making it to the NBA are inherently different than those of one who may have a natural tendency to programm.
To pretend like the two could switch places and, having put in a lot of practice hours, end up in the same place, is either naïveté or self-deception.
So I while I agree with the notion that one will become better with practice, I question the ideas that all will progress at a similar rate and that the "ceiling" for their abilities are at the same level of skill.
I think a bit of success bias is operating here. If you take the average NBA player and ask him why he made it, he'll likely cite hard work, having a winning attitude, or something to a similar effect. The fact that he is six foot six never enters into the equation. The chances of an athletically gifted giant making it to the NBA are inherently different than those of one who may have a natural tendency to programm.
To pretend like the two could switch places and, having put in a lot of practice hours, end up in the same place, is either naïveté or self-deception.
The ceiling doesn't need to be equal for them all to be in the top 0.1% called 'Great'.
It's a fact that you cannot become better at something without doing it. But it is not guaranteed that you become better at something because you're doing it.
The personality traits that let you become a great writer or programmer are not innate in everybody. And for the most part you can't reshape a personality to have the right traits. It's not talent, but the right precondition to make use of the practice.
The personality traits that let you become a great writer or programmer are not innate in everybody. And for the most part you can't reshape a personality to have the right traits. It's not talent, but the right precondition to make use of the practice.
It is practically guaranteed that you will become better if you 'study and practice', which implies the explicit goal of becoming better. It's almost impossible to become worse by practicing with the explicit goal of becoming better.
I don't have any reason to believe there exists such a thing as an identifiable "personality trait that let's you become a great writer or programmer". Perhaps a predisposition towards "being good at what you do" and "practicing and studying to become better" is such a thing, but when I speak for myself I know such tendencies can thoroughly change over time.
I believe it's easy to engage in armchair psychology, while simultaneously thinking ourselves members of a special breed.
I don't have any reason to believe there exists such a thing as an identifiable "personality trait that let's you become a great writer or programmer". Perhaps a predisposition towards "being good at what you do" and "practicing and studying to become better" is such a thing, but when I speak for myself I know such tendencies can thoroughly change over time.
I believe it's easy to engage in armchair psychology, while simultaneously thinking ourselves members of a special breed.
Becoming better isn't the same as becoming great.
I don't think there is such a thing as an identifiable personality trait, not in the way you mean it.
Yet I'll propose to you a simple proof of two points. The first point is that there is more going on than simply applying yourself. And the second point is that whatever that is, it has to do with your personality.
To the first point: If there was a recipe to greatness (the Amadeus, Shakespeare, Einstein, Goedel, Knuth kind) then everybody would simply do it and we'd be a race of supermen. So obviously any argument for the existence of such a recipe has to be fundamentally flawed.
This presents us with a paradox, as we do know that great people did apply themselves to become what they are, and we know that within bounds everybody is equipped with the same mental facilities. How do we reconcile this?
To the second point: Great people applied themselves over decades and tens of thousands of hours. This level of commitment can neither be forced upon you, nor can you make yourself do it with discipline. You will have to find a drive inside yourself to do it. All things being equal and your personality being fully formed as you enter your teens, the answer obviously is that how that happens is your personality.
You cannot predict how the personality of a person will interact with that persons life and goals, so there is no "identifyable". But with hindsight you can analyze a person and see what made somebody apply himself consistently for decades. And every person is different, so you cannot predict if a person will become great or not.
I don't think there is such a thing as an identifiable personality trait, not in the way you mean it.
Yet I'll propose to you a simple proof of two points. The first point is that there is more going on than simply applying yourself. And the second point is that whatever that is, it has to do with your personality.
To the first point: If there was a recipe to greatness (the Amadeus, Shakespeare, Einstein, Goedel, Knuth kind) then everybody would simply do it and we'd be a race of supermen. So obviously any argument for the existence of such a recipe has to be fundamentally flawed.
This presents us with a paradox, as we do know that great people did apply themselves to become what they are, and we know that within bounds everybody is equipped with the same mental facilities. How do we reconcile this?
To the second point: Great people applied themselves over decades and tens of thousands of hours. This level of commitment can neither be forced upon you, nor can you make yourself do it with discipline. You will have to find a drive inside yourself to do it. All things being equal and your personality being fully formed as you enter your teens, the answer obviously is that how that happens is your personality.
You cannot predict how the personality of a person will interact with that persons life and goals, so there is no "identifyable". But with hindsight you can analyze a person and see what made somebody apply himself consistently for decades. And every person is different, so you cannot predict if a person will become great or not.
Remember that you're looking at survivors. The obvious question is how many people studied, practiced, and never became great. You'd have to look at the initial pool.
While you wait for confirmation that studying and practicing increases your changes of becoming Great at what you do, I'm just gonna go practice, expecting to race way ahead of you. I don't need an academic study to confirm the obvious: practice makes perfect.
If all survivors did A and none did not do A, then A is likely to be at least a precondition. But more than that: the number of people that choose to spend time deliberately studying and practicing is already so small that there is room for them all to be Great. I am convinced that nearly every single person that deliberately studies and practices to become better at what he does will become Great at what he does, because 'Great' is a relative concept and most people are easily contented.
If all survivors did A and none did not do A, then A is likely to be at least a precondition. But more than that: the number of people that choose to spend time deliberately studying and practicing is already so small that there is room for them all to be Great. I am convinced that nearly every single person that deliberately studies and practices to become better at what he does will become Great at what he does, because 'Great' is a relative concept and most people are easily contented.
That is an unnecessarily aggressive comment. What makes you think you're racing against me? "Practice makes perfect" is a platitude, not something obvious. Like another commenter said, I could practice infinitely and never be any good at basketball. I just don't have the body type. On the other hand, I was a pretty good programmer at 13, one year after discovering computers (1983). I could tell you that what made me "great" (I'm rich thanks to software) was practice and studying. In reality, it was mostly luck. Think what you want.
It was not intended aggressively, but rather rhetorically. We are not racing against each other, but if you intend to be 'good' at something, you are in a competition with a great many other. If you find excuses not to improve yourself, you will definitely not be 'good'.
If you practiced basketball every day for the next year, and enjoyed doing that, you'd be an excellent basketball player after that year. That you couldn't make it as a pro doesn't detract anything from that.
There's a near infinite amount of things every single one of us could do if they wanted to. The only problem is that we usually do not want to. The number of things that you truly can't do because it depends on some physical characteristic is fairly limited.
You could be a physics professor, an awesome captain, an excellent stock broker or a locally successful artist. You are just not interested in any of those things.
If you practiced basketball every day for the next year, and enjoyed doing that, you'd be an excellent basketball player after that year. That you couldn't make it as a pro doesn't detract anything from that.
There's a near infinite amount of things every single one of us could do if they wanted to. The only problem is that we usually do not want to. The number of things that you truly can't do because it depends on some physical characteristic is fairly limited.
You could be a physics professor, an awesome captain, an excellent stock broker or a locally successful artist. You are just not interested in any of those things.
When I was a teenager I wanted to be a world-class runner. I trained as hard and as methodically as I could for three years. I could never break a five-minute mile. I was mediocre, and slower than guys who barely trained but had bodies more suited to running.
I still run 25 years later, but just for fun. Perhaps I could run a three-hour marathon if I really cared, but that's far from great. Note that this is completely unrelated to the enjoyment you derive from the activity.
If you want to be great at something, you have to pick your battles and play to your strengths. Some people just cannot be great programmers no matter how hard they try. Most people can be great at something if they try hard enough, but most people cannot be great at programming. That was the point that you seem to miss.
I still run 25 years later, but just for fun. Perhaps I could run a three-hour marathon if I really cared, but that's far from great. Note that this is completely unrelated to the enjoyment you derive from the activity.
If you want to be great at something, you have to pick your battles and play to your strengths. Some people just cannot be great programmers no matter how hard they try. Most people can be great at something if they try hard enough, but most people cannot be great at programming. That was the point that you seem to miss.
Those lectures from Hamming are available online on video:
http://www.youtube.com/playlist?list=PL2FF649D0C4407B30&...
http://www.youtube.com/playlist?list=PL2FF649D0C4407B30&...
Two important issues to take into account:
1) The use of "worse" or "better" keeps the conversation very subjective. Better in what sense? What metrics are you using to measure the skill?
2) Deliberate Practice: same as with physical training if you practice in ways that strain your capacity, it will grow as long as the necessary amount of time is put into the activity.
Highly recommended: http://www.amazon.com/Talent-Overrated-World-Class-Performer...
2) Deliberate Practice: same as with physical training if you practice in ways that strain your capacity, it will grow as long as the necessary amount of time is put into the activity.
Highly recommended: http://www.amazon.com/Talent-Overrated-World-Class-Performer...
Let's clear some facts first:
- You're not born a programmer, there's no such thing as "talented"
- Different people have wildly different levels of skill/proficiency in programming.
- Skill in programming invariably takes time to acquire, nobody has become a great programmer after programming for a week.
With that being said, what the author aims for is to predict who will become a great programmer, not just an average one, he's looking for the 99.9th percentile of programmers, for the 0.1%, the ones which outrank 1000 of their peers.
For most of the profession/craft of programming that doesn't matter. You're certainly looking for people to hire in the 80th percentile and above but between 1:1000 and 1:5 there's a huge difference. We know that you can train people to become proficient enough in programming to be useful in it.
As to the difficulty of "training" great programmers, it takes a long time and a lot of hours, persistence and passion to become one. Probably in the order of 10 years, 10'000 hours. Not everybody can do that. The simple fact that different people have different preferences, priorities, etc. ensures that most people on the path from beginner to great programmer fall somewhere along the wayside. But those few with the stamina to persist, who push themselves, for a decade or more, those people have a shot.
So can you train personality traits that will allow you to pull trough? I think it's unlikely. You can show so-inclined persons the way, and if they have the right personality they can walk it, and you can train them on walking the path well. But you can't reshape their psychology to fit the path.
- You're not born a programmer, there's no such thing as "talented"
- Different people have wildly different levels of skill/proficiency in programming.
- Skill in programming invariably takes time to acquire, nobody has become a great programmer after programming for a week.
With that being said, what the author aims for is to predict who will become a great programmer, not just an average one, he's looking for the 99.9th percentile of programmers, for the 0.1%, the ones which outrank 1000 of their peers.
For most of the profession/craft of programming that doesn't matter. You're certainly looking for people to hire in the 80th percentile and above but between 1:1000 and 1:5 there's a huge difference. We know that you can train people to become proficient enough in programming to be useful in it.
As to the difficulty of "training" great programmers, it takes a long time and a lot of hours, persistence and passion to become one. Probably in the order of 10 years, 10'000 hours. Not everybody can do that. The simple fact that different people have different preferences, priorities, etc. ensures that most people on the path from beginner to great programmer fall somewhere along the wayside. But those few with the stamina to persist, who push themselves, for a decade or more, those people have a shot.
So can you train personality traits that will allow you to pull trough? I think it's unlikely. You can show so-inclined persons the way, and if they have the right personality they can walk it, and you can train them on walking the path well. But you can't reshape their psychology to fit the path.
[deleted]
Hemming's point can be summed up with this pithy question:
Do you have n years of experience, or n * 1 year of experience?
Spending years on the job learning nothing or barely learning lots of programming languages does not make one into a great programmer.
My mother taught creative writing, and it's exactly the same. Writers got good ultimately by writing, not by reading books about writing or taking classes on writing.
(edit: Let me add that this is a central problem faced by educators: The good ones know that they can't teach/train success directly, rather that the students must take that training and educate themselves about how to use it to achieve their own success.)
Do you have n years of experience, or n * 1 year of experience?
Spending years on the job learning nothing or barely learning lots of programming languages does not make one into a great programmer.
My mother taught creative writing, and it's exactly the same. Writers got good ultimately by writing, not by reading books about writing or taking classes on writing.
(edit: Let me add that this is a central problem faced by educators: The good ones know that they can't teach/train success directly, rather that the students must take that training and educate themselves about how to use it to achieve their own success.)
> Writers got good ultimately by writing, not by reading books about writing or taking classes on writing.
I'm not sure this is true. I've had a little success in short story writing, and have been pushing myself to get better over quite a few years now. At least for me, writing seems necessary but not sufficient. I have to:
> Do bureaucrats after years of writing reports and instructions get better?
is no. They're not striving to be better.
I'm not sure this is true. I've had a little success in short story writing, and have been pushing myself to get better over quite a few years now. At least for me, writing seems necessary but not sufficient. I have to:
* Write
* Think hard about what I write
* Critique other writers
* Read books by people who know the subject
* Write some more
> Do bureaucrats after years of writing reports and instructions get better?
is no. They're not striving to be better.
[deleted]
Based on years of research by folks like Cal Newport and Scott H. Young, the bureaucratic world epitomizes the antithesis of an efficient learning environment.
To learn, one needs:
* A constant influx of new and increasingly difficult challenges.
* Opportunities to step back and review prior learning, in order to develop a more holistic understanding.
* As rapid and accurate feedback as possible.
As learning animals, we love video games because they hit all of those buttons of ours in rapid succession. The start-up world hosts a disproportionate amount of innovation and technical proficiency for the same reason.
To learn, one needs:
* A constant influx of new and increasingly difficult challenges.
* Opportunities to step back and review prior learning, in order to develop a more holistic understanding.
* As rapid and accurate feedback as possible.
As learning animals, we love video games because they hit all of those buttons of ours in rapid succession. The start-up world hosts a disproportionate amount of innovation and technical proficiency for the same reason.
I've worked with and trained quite a few people over the past 15 years and, though I don't really say it to anybody, I do think great programmers are born not made. Though you can be made into a pretty good programmer that can be a great player on a team. And you can also be a great programmer who is lazy and doesn't live up to their potential. But you can see it in their ideas and way of solving problems.
The writing example isn't that sound. First he asks if you can teach 'good' programming, but then expects 'great' programmers to come of it. Rhetoric like that smells a little fishy. Then he rests his conclusion, that great programmers can't be trained, on the point that we have perfect knowledge of every great writer that ever wrote? I don't buy it.
Agreed. While someone who saw my writing as a college freshman might have thought they had discovered a "natural", that would have ignored the years spent unwittingly honing my craft in online roleplaying environments.
Until we find a very proficient author with a demonstrable lack of writing experience, we have to assume they received direct or indirect training of some kind. The burden of that disproof lies with the proponents of the "natural/gifted" hypothesis.
Until we find a very proficient author with a demonstrable lack of writing experience, we have to assume they received direct or indirect training of some kind. The burden of that disproof lies with the proponents of the "natural/gifted" hypothesis.
How is creative writing comparable to programming? Writing, painting etc is more of creative process than programming, which is more logical than creative. There are infinite ways of writing a short story, but there aren't too many ways of writing a program for binary search, no?
There are an infinite number of ways of solving the same problem. I have dozens of tools with which I can solve most of my problems; and I can choose to do it in many ways. Sure, there are only so many ways you can write binary search, in a given language. But that doesn't mean there is only one way to solve an actual problem.
For example, if your problem is looking up elements in a dictionary (key-value) structure, there are many ways to do it. A hash table? Binary tree? B-tree? Sorted array? Trie? Patricia trie? Linear search in a linked list? Linear search in an array? Are the arrays fixed sized, or variable sized vectors? All of these solutions may be correct, depending on other factors, and all of them have many variants.
And that, of course, assumes that you know that a dictionary structure is what you need. Maybe your problem actually would call better for a table with GiST indexes, or a quadree dividing up a two-dimensional space.
Above that level, even if your data structure needs are fairly simple or fairly well determined, there's how you structure and organize your code to minimize the chance of bugs, make it extensible, and make it understandable to future programmers. Most of my work isn't writing fresh code. It's finding and fixing bugs in existing code, and extending it to do new things it was never intended to do. Depending on how well organized it is, and how expressive the code is of its intent, that job can be much more difficult or much easier.
That's where a lot of the creativity comes in. Finding the write way to structure and express your code to fit the problem at hand. Writing code that will be adaptable to the future, easy to extend without introducing new bugs, easy to fix bugs in, but without including a lot of extra machinery for features that you will never need. It is easy to write code that does a single task, but will be fragile if someone ever tries to extend it to do something else. It is also easy to spend all of your time writing AbstractFactoryIteratorFunctionFactoryAbastractGenerators which are infinitely modular and extensible but don't actually solve any problems.
Great code is code which solves a real problem, and can be used tomorrow to solve five more problems that you didn't even know about today, but which doesn't suffer under the weight of being designed to be extended in ways that you thought might be useful later, but wind up never being so. And writing such software, and modifying in those five ways, takes a substantial amount of creativity.
For example, if your problem is looking up elements in a dictionary (key-value) structure, there are many ways to do it. A hash table? Binary tree? B-tree? Sorted array? Trie? Patricia trie? Linear search in a linked list? Linear search in an array? Are the arrays fixed sized, or variable sized vectors? All of these solutions may be correct, depending on other factors, and all of them have many variants.
And that, of course, assumes that you know that a dictionary structure is what you need. Maybe your problem actually would call better for a table with GiST indexes, or a quadree dividing up a two-dimensional space.
Above that level, even if your data structure needs are fairly simple or fairly well determined, there's how you structure and organize your code to minimize the chance of bugs, make it extensible, and make it understandable to future programmers. Most of my work isn't writing fresh code. It's finding and fixing bugs in existing code, and extending it to do new things it was never intended to do. Depending on how well organized it is, and how expressive the code is of its intent, that job can be much more difficult or much easier.
That's where a lot of the creativity comes in. Finding the write way to structure and express your code to fit the problem at hand. Writing code that will be adaptable to the future, easy to extend without introducing new bugs, easy to fix bugs in, but without including a lot of extra machinery for features that you will never need. It is easy to write code that does a single task, but will be fragile if someone ever tries to extend it to do something else. It is also easy to spend all of your time writing AbstractFactoryIteratorFunctionFactoryAbastractGenerators which are infinitely modular and extensible but don't actually solve any problems.
Great code is code which solves a real problem, and can be used tomorrow to solve five more problems that you didn't even know about today, but which doesn't suffer under the weight of being designed to be extended in ways that you thought might be useful later, but wind up never being so. And writing such software, and modifying in those five ways, takes a substantial amount of creativity.
Programming is a creative process if you actually know what is programming. Programming is about coming up with an idea of a system that could fulfill a purpose and then implementing and evolving the system over a period of time. I don't think there is anything more creative then programming, if only you understand what programming is about.
In creative writing you express your thoughts using any of the human's natural language and in programming you do the same using a programming language and both requires logical and creative thinking. Just that in programming you can see your thoughts coming to life which makes it much more cool.
In creative writing you express your thoughts using any of the human's natural language and in programming you do the same using a programming language and both requires logical and creative thinking. Just that in programming you can see your thoughts coming to life which makes it much more cool.
Creative writing is a good analogy. All artists have to be taught, even if they teach themselves. Same with programming.
When asked to say, draw a picture of this house, most trained artists, who have learnt the mechanics should be able to do a faithful rendition of that house. The same with a small program, most trained programmers will be able to make it, using their skills.
However, where both great artists and great programmers are the same is that they bring something more than the sum total of the parts to their work. This something more is what cannot be taught.
When asked to say, draw a picture of this house, most trained artists, who have learnt the mechanics should be able to do a faithful rendition of that house. The same with a small program, most trained programmers will be able to make it, using their skills.
However, where both great artists and great programmers are the same is that they bring something more than the sum total of the parts to their work. This something more is what cannot be taught.
I want to recommend "The Artful Edit".
It takes an all too infrequent approach to teaching how to edit and actually shows the before-and-after work of great authors. In this case, the reader sees quite a bit of Fitzgerald's process deconstructed. Having seen the changes required of the first draft, it left me with much higher hopes for leveling up my own writing.
It takes an all too infrequent approach to teaching how to edit and actually shows the before-and-after work of great authors. In this case, the reader sees quite a bit of Fitzgerald's process deconstructed. Having seen the changes required of the first draft, it left me with much higher hopes for leveling up my own writing.
One way in which it is comparable is you make up the program as you go along.
You do have some sense of what you are about to write. But it's not that clear. You are not exactly sure what the program will turn out to be until you sit down to start writing. Like writing, rampant thoughts pull you in multiple directions until one seduces you into following it.
It's surprising how seemingly irrelevant factors affect the program. A recent conversation with a non-programmer, a change in the weather, where you are sitting, or music are enough to set you off in a different direction. If a sense of design isn't precisely what shapes a program, a programmer would do well to pretend that it is.
The counterpoint to the binary search analogy is that there are infinite ways to avoid writing a program that needs a binary search and write a different program instead.
You do have some sense of what you are about to write. But it's not that clear. You are not exactly sure what the program will turn out to be until you sit down to start writing. Like writing, rampant thoughts pull you in multiple directions until one seduces you into following it.
It's surprising how seemingly irrelevant factors affect the program. A recent conversation with a non-programmer, a change in the weather, where you are sitting, or music are enough to set you off in a different direction. If a sense of design isn't precisely what shapes a program, a programmer would do well to pretend that it is.
The counterpoint to the binary search analogy is that there are infinite ways to avoid writing a program that needs a binary search and write a different program instead.
I once heard someone claim that reading novels is the only time the average person comes engages with a large, structured work. It takes weeks to finish reading a novel and it's crammed full of details which have a logical relationship to each other. Sort of like working on a piece of software.
As someone who writes both software and fiction, I've only found an increasing convergence between the two over the years.
Basically, fiction authors are writing obfuscated C, but doing so in Python, where the interpreter was compiled for a version of DOS intended for Windows 3.1 but coaxed to work on WINE, set inside of a virtual machine on custom-built ARM hardware with propriety drivers, with nothing but the AppleTalk protocol provided for communication between the author and the reader. If we get a buffer overflow in that environment, then we win.
Basically, fiction authors are writing obfuscated C, but doing so in Python, where the interpreter was compiled for a version of DOS intended for Windows 3.1 but coaxed to work on WINE, set inside of a virtual machine on custom-built ARM hardware with propriety drivers, with nothing but the AppleTalk protocol provided for communication between the author and the reader. If we get a buffer overflow in that environment, then we win.
Short term, he is right. Long term he's like that patent officer claiming that everything had already been invented.
http://carlos.bueno.org/2012/08/pascals-apology.html
http://carlos.bueno.org/2012/08/pascals-apology.html
What's the definition of a good programmer anyway? It seems rather vague to me. Someone who writes clean, readable code? Someone who writes efficient and elegant algorithms? Which is it?
When you look back at when you started programming and where you are now, what surprises you the most?
What turned out to be the opposite of what you originally thought it would be?
What turned out to be the opposite of what you originally thought it would be?
To continue the analogy... most sceenwriters, copywriters, columnists etc. probably did take creative writing classes.
Probably. And even self-taught creatives are taught. They only differ in kind from others in that someone (a teacher, a parent) installed - or arguably re-installed - the wetware equivalent of a compiler and headers on an otherwise consumer-orientated OS.
Hmm. I'm not so sure about his analogy with writing. Of course, most people who take creative writing don't go on to become great writers; that pretty much goes without saying, most people in any field don't go on to become "great" (the very definition of "great" is that it's exceptional). So that part is a tautology.
Now, I wonder about how many people who go on to be "great writers" received training in writing? Of course, "creative writing" as an academic discipline is rather new, but English has been around as a discipline for years. From a quick poll of the authors mentioned in http://en.wikipedia.org/wiki/20th_century_in_literature and http://en.wikipedia.org/wiki/21st_century_in_literature, almost every one had at least a college education, mostly in the humanities (which generally require a lot of writing, and train you in writing). And most of them have worked at lower-level writing jobs before becoming great writers; copy editors, journalists, corporate writers, and the like. Several of the more recent "great writers" of the late 20th and 21st centuries have indeed gone through creative writing programs.
So his analogy, at least, seems to be false.
How about in writing software? Well, as I mentioned, it's pretty much tautological that no training program can produce entirely great programmers. The purpose of training is to turn lousy programmers into mediocre. Mediocre into passable. Passable into good. Good into very good. And very good into great. You are not likely to train all of your lousy programmers into great; so claiming that training does not produce great programmers is attacking a strawman.
I have seen plenty of people who have gotten a degree in computer science who are lousy programmers. And I have seen great programmers with no formal education. But on the whole, when I've looked at programmers with equivalent amounts of experience, but where one had formal training and the other did not, I would prefer the one who had some formal training. People who have not had formal training tend to not have much experience with reasoning about algorithms, or invariants, that can make their code a lot better.
While its true that nowadays we have many libraries and tools that mean that the average programmer can just use built-in data structures and do a pretty good job, I've seen enough code that was so horribly inefficient that even a little bit of algorithmic analysis upfront would have been helpful. Or a lot of code where someone just hacked away at a problem until they had something that worked, rather than trying to formulate a model that would underly it and keep the code well-organized and understandable.
And among those programmers who are self-taught but great, they have put in deliberate practice, and deliberate study, even if its on their own.
So sure, there are some people who are just untrainable; I've worked with some of them. And there are some people who are naturally brilliant and able to study independently. But all else being equal, I think that deliberate training definitely has value in improving the quality of programmers as a whole; and so yes, training will lead to more great programmers.
Now, I wonder about how many people who go on to be "great writers" received training in writing? Of course, "creative writing" as an academic discipline is rather new, but English has been around as a discipline for years. From a quick poll of the authors mentioned in http://en.wikipedia.org/wiki/20th_century_in_literature and http://en.wikipedia.org/wiki/21st_century_in_literature, almost every one had at least a college education, mostly in the humanities (which generally require a lot of writing, and train you in writing). And most of them have worked at lower-level writing jobs before becoming great writers; copy editors, journalists, corporate writers, and the like. Several of the more recent "great writers" of the late 20th and 21st centuries have indeed gone through creative writing programs.
So his analogy, at least, seems to be false.
How about in writing software? Well, as I mentioned, it's pretty much tautological that no training program can produce entirely great programmers. The purpose of training is to turn lousy programmers into mediocre. Mediocre into passable. Passable into good. Good into very good. And very good into great. You are not likely to train all of your lousy programmers into great; so claiming that training does not produce great programmers is attacking a strawman.
I have seen plenty of people who have gotten a degree in computer science who are lousy programmers. And I have seen great programmers with no formal education. But on the whole, when I've looked at programmers with equivalent amounts of experience, but where one had formal training and the other did not, I would prefer the one who had some formal training. People who have not had formal training tend to not have much experience with reasoning about algorithms, or invariants, that can make their code a lot better.
While its true that nowadays we have many libraries and tools that mean that the average programmer can just use built-in data structures and do a pretty good job, I've seen enough code that was so horribly inefficient that even a little bit of algorithmic analysis upfront would have been helpful. Or a lot of code where someone just hacked away at a problem until they had something that worked, rather than trying to formulate a model that would underly it and keep the code well-organized and understandable.
And among those programmers who are self-taught but great, they have put in deliberate practice, and deliberate study, even if its on their own.
So sure, there are some people who are just untrainable; I've worked with some of them. And there are some people who are naturally brilliant and able to study independently. But all else being equal, I think that deliberate training definitely has value in improving the quality of programmers as a whole; and so yes, training will lead to more great programmers.
The proverbial "10,000 hours" is not enough. Here are some problems with that.
* You get 5 focused, highly effective hours in an average day, possibly 6 days per week. You can work productively for 10-12 hours in a single day, but it's not effective in the long run. As an absolute maximum, your harvest for something as difficult as programming is going to be about 1500 hours per year. So if you really max it out, you're going to need 7 years to become a great programmer. That's if you're maximally efficient and control your own schedule.
* What you mentioned about bureaucrats becoming worse writers is probably true. It takes deliberate practice. It takes feedback and interaction and exposure. It may require a mentor. In fact, one of the most important "meta" skills is knowing when to recognize people are better than you, and to learn from them. Otherwise, you might be practicing doing things wrong. Most people at their paid jobs are doing just that, because the corporate world is one of oppressive mediocrity.
* The software industry sucks. Most of the work is busywork and most of the shit being done is being done wrong. Few people get any deliberate practice at their paid jobs. In fact, I would say that most paid software work is negative toward long-term greatness, because it forces you to do things wrong.
Programming is an especially hard thing to become really good at, because (a) to become a great software engineer, you must interact with the real world, but (b) the vast majority of the real world is dismally broken, and 99% of the real shot-callers are idiots who've never even seen a line of code except in the movies.
* You get 5 focused, highly effective hours in an average day, possibly 6 days per week. You can work productively for 10-12 hours in a single day, but it's not effective in the long run. As an absolute maximum, your harvest for something as difficult as programming is going to be about 1500 hours per year. So if you really max it out, you're going to need 7 years to become a great programmer. That's if you're maximally efficient and control your own schedule.
* What you mentioned about bureaucrats becoming worse writers is probably true. It takes deliberate practice. It takes feedback and interaction and exposure. It may require a mentor. In fact, one of the most important "meta" skills is knowing when to recognize people are better than you, and to learn from them. Otherwise, you might be practicing doing things wrong. Most people at their paid jobs are doing just that, because the corporate world is one of oppressive mediocrity.
* The software industry sucks. Most of the work is busywork and most of the shit being done is being done wrong. Few people get any deliberate practice at their paid jobs. In fact, I would say that most paid software work is negative toward long-term greatness, because it forces you to do things wrong.
Programming is an especially hard thing to become really good at, because (a) to become a great software engineer, you must interact with the real world, but (b) the vast majority of the real world is dismally broken, and 99% of the real shot-callers are idiots who've never even seen a line of code except in the movies.
Does he give examples? I'm thinking of specific examples of: "An examination of books on programming suggests that most of the authors are not good programmers."
No he doesn't. I figure it's less relevant today because it's much easier to find examples of good code via open source projects, and online resources like Zed Shaw's books.
"I made the comparison of writing software with the act of literary writing; both seem to depend fundamentally on clear thinking. Can good programming be taught? If we look at the corresponding teaching of "creative writing" courses we find that most students of such courses do not become great writers, and most great writers in the past did not take creative writing courses! Hence it is dubious that great programmers can be trained easily.
Does experience help? Do bureaucrats after years of writing reports and instructions get better? I have no real data but I suspect that with time they get worse! The habitual use of "governmentese" over the years probably seeps into their writing style and makes them worse. I suspect the same for programmers! Neither years of experience nor the number of languages used is any reason for thinking that the programmer is getting better from these experiences. An examination of books on programming suggests that most of the authors are not good programmers.
The results I picture are not nice, but all you have to oppose it is wishful thinking - I have evidence of years and years of programming on my side."
What do you guys think? I disagree with his creative writing analogy because I don't think creative writing courses were taught much in the past, but otherwise I feel it's spot on.