I think you should give a more precise definition of the aptitude needed to be labelled has-a-gear.
I program for a living, and I would like to think that I fall among “those who can” on the bimodal distribution (if one exists). I’ve seen programmers and non-programmers of all levels of ability (except for far above mine, because those are hard to recognize). One man’s programmer is another man’s deadweight.
Individual people grow in talent until they stop (and maybe they resume later). So if there exists a test to predict whether they’ll stop at some future level, it probably doesn’t involve actual programming. (For instance, testing people’s understanding of variable semantics is pointless unless you’ve taught them those semantics first.) It would have to test something else that happens to be strongly correlated with it. So
Incidentally, this was this was recently discussed on Programmers Stack Exchange:
I think you should give a more precise definition of the aptitude needed to be labelled has-a-gear.
And the next step for a reductionist is to split this “gear” to smaller (and smaller and smaller… if necessary) parts, and design a course to teach each one of them separately. And only then teach programming.
People have some innate differences, but I feel that speaking about innate talent is often just worshiping our ignorance as teachers.
Of course, it may turn out that the innate differences in this specific topic are too big to overcome, or that overcoming them is possible but not cost-effective… but I think we haven’t tried hard enough yet.
For the record, I think programming is so measurable and has such a tight feedback loop that it is one arena in which it’s relatively easy to recognize ability that far exceeds your own.
1) Code quality is fairly subjective, and in particular novice (very novice) programmers have difficulty rating code. Most professional programmers seem to be able to recognize it though, and feel awe when they come across beautiful code.
2) Code quantity can be misleading, but if you’re on a team and producing a 100-line delta a day, you will notice the odd team member producing 1000-line daily deltas; coupled with even decent ability to tell whether or not that code is maintainable and efficient (in terms of functionality / loc), this is a strong indicator.
3) Actually watching a master write code is fantastic and intimidating. People that code at 60 wpm without even stopping to consider their algorithms, data structures or APIs, but manage at the end of an hour to have a tight, unit-tested, efficient and readable module.
I can think of five people that I know that I would classify as being in discrete levels above me (that is, each of them is distinguishable by me as being either better or worse than the others). I think there are some gaps in there; Jeff Dean is so mindbogglingly skilled that I can’t see anyone on my list ever catching up to him, so there are probably a few levels I don’t have examples for.
People that code at 60 wpm without even stopping to consider their algorithms, data structures or APIs, but manage at the end of an hour to have a tight, unit-tested, efficient and readable module.
I’ve never seen this or even imagined it can happen. I can’t even write comments or pseudo-code that fast (without pause) because I can’t design that fast.
I’ve done it, and it’s not as impressive as it sounds. It’s mostly just reciting from experience and not some savant-like act of intelligence or skill. Take those same masters into an area where they don’t have experience and they won’t be nearly as fast.
Actually, I think the sequences were largely a recital of experience (a post a day for a year).
I don’t know about you, but I can’t recall 10k LOC from experience even if I had previously written something before; seeing someone produce that much in the space of three hours is phenomenal, especially when I realize that I probably would have required two or three times as much code to do the same thing on my first attempt. If by “reciting from experience” you mean that they have practiced using the kinds of abstractions they employ many times before, then I agree that they’re skilled because of that practice; I still don’t think it’s a level of mastery that I will ever attain.
Yeah, I can pretty much recall 10k LOC from experience. But it’s not just about having written something before, it’s about a truly fundamental understanding of what is best in some area of expertise which comes with having written something before (like a GUI framework for example) and improved upon it for years. After doing that, you just know what the architecture should look like, and you just know how to solve all the hard problems already, and you know what to avoid doing, and so really all you’re doing is filling in the scaffolding with your hard won experience.
Not too long ago, I lost a week of work and was able to recompose it in the space of an afternoon. It wasn’t the same line-for-line, but it was the same design and probably even used the same names for most things, and was roughly 10k LOC. So if I had recent or substantial experience, I can see expecting a 10x speedup in execution. That’s pretty specific though; I don’t think I have ever had the need to write something that was substantially similar to anything else I’d ever written.
Domain experience is vital, of course. If you have to spend all your time wading through header files to find out what the API is or discover the subtle bugs in your use of it, writing just a small thing will take painfully long. But even where I never have to think about these things I still pause a lot.
One thing that is different is that I make mistakes often enough that I wait for them; working with one of these people, I noticed that he practiced “optimistic coding”; he would compile and test his code, but by feeding it into a background queue. In that particular project, a build took ~10 minutes, and our test suite took another ~10 minutes. He would launch a build / test every couple of minutes, and had a dbus notification if one failed; once, it did, and he had to go back several (less than 10, I think) commits to fix the problem. He remembered exactly where he was, rebased, and moved on. I couldn’t even keep up with him finding the bug, much less fixing it.
The people around here who have a million lines of code in production seem to have that skill, of working without the assistance of a compiler or test harness; their code works the first time. Hell, Rob Pike uses ed. He doesn’t even need to refer to his code often enough to make it worthwhile to easily see what he’s already written (or go back and change things)---for him, that counts as an abnormal occurrence.
I think you should give a more precise definition of the aptitude needed to be labelled has-a-gear.
I program for a living, and I would like to think that I fall among “those who can” on the bimodal distribution (if one exists). I’ve seen programmers and non-programmers of all levels of ability (except for far above mine, because those are hard to recognize). One man’s programmer is another man’s deadweight.
Individual people grow in talent until they stop (and maybe they resume later). So if there exists a test to predict whether they’ll stop at some future level, it probably doesn’t involve actual programming. (For instance, testing people’s understanding of variable semantics is pointless unless you’ve taught them those semantics first.) It would have to test something else that happens to be strongly correlated with it. So
Incidentally, this was this was recently discussed on Programmers Stack Exchange:
And the next step for a reductionist is to split this “gear” to smaller (and smaller and smaller… if necessary) parts, and design a course to teach each one of them separately. And only then teach programming.
People have some innate differences, but I feel that speaking about innate talent is often just worshiping our ignorance as teachers.
Of course, it may turn out that the innate differences in this specific topic are too big to overcome, or that overcoming them is possible but not cost-effective… but I think we haven’t tried hard enough yet.
For the record, I think programming is so measurable and has such a tight feedback loop that it is one arena in which it’s relatively easy to recognize ability that far exceeds your own.
1) Code quality is fairly subjective, and in particular novice (very novice) programmers have difficulty rating code. Most professional programmers seem to be able to recognize it though, and feel awe when they come across beautiful code.
2) Code quantity can be misleading, but if you’re on a team and producing a 100-line delta a day, you will notice the odd team member producing 1000-line daily deltas; coupled with even decent ability to tell whether or not that code is maintainable and efficient (in terms of functionality / loc), this is a strong indicator.
3) Actually watching a master write code is fantastic and intimidating. People that code at 60 wpm without even stopping to consider their algorithms, data structures or APIs, but manage at the end of an hour to have a tight, unit-tested, efficient and readable module.
I can think of five people that I know that I would classify as being in discrete levels above me (that is, each of them is distinguishable by me as being either better or worse than the others). I think there are some gaps in there; Jeff Dean is so mindbogglingly skilled that I can’t see anyone on my list ever catching up to him, so there are probably a few levels I don’t have examples for.
I’ve never seen this or even imagined it can happen. I can’t even write comments or pseudo-code that fast (without pause) because I can’t design that fast.
I’ve done it, and it’s not as impressive as it sounds. It’s mostly just reciting from experience and not some savant-like act of intelligence or skill. Take those same masters into an area where they don’t have experience and they won’t be nearly as fast.
Actually, I think the sequences were largely a recital of experience (a post a day for a year).
I don’t know about you, but I can’t recall 10k LOC from experience even if I had previously written something before; seeing someone produce that much in the space of three hours is phenomenal, especially when I realize that I probably would have required two or three times as much code to do the same thing on my first attempt. If by “reciting from experience” you mean that they have practiced using the kinds of abstractions they employ many times before, then I agree that they’re skilled because of that practice; I still don’t think it’s a level of mastery that I will ever attain.
Yeah, I can pretty much recall 10k LOC from experience. But it’s not just about having written something before, it’s about a truly fundamental understanding of what is best in some area of expertise which comes with having written something before (like a GUI framework for example) and improved upon it for years. After doing that, you just know what the architecture should look like, and you just know how to solve all the hard problems already, and you know what to avoid doing, and so really all you’re doing is filling in the scaffolding with your hard won experience.
Not too long ago, I lost a week of work and was able to recompose it in the space of an afternoon. It wasn’t the same line-for-line, but it was the same design and probably even used the same names for most things, and was roughly 10k LOC. So if I had recent or substantial experience, I can see expecting a 10x speedup in execution. That’s pretty specific though; I don’t think I have ever had the need to write something that was substantially similar to anything else I’d ever written.
Domain experience is vital, of course. If you have to spend all your time wading through header files to find out what the API is or discover the subtle bugs in your use of it, writing just a small thing will take painfully long. But even where I never have to think about these things I still pause a lot.
One thing that is different is that I make mistakes often enough that I wait for them; working with one of these people, I noticed that he practiced “optimistic coding”; he would compile and test his code, but by feeding it into a background queue. In that particular project, a build took ~10 minutes, and our test suite took another ~10 minutes. He would launch a build / test every couple of minutes, and had a dbus notification if one failed; once, it did, and he had to go back several (less than 10, I think) commits to fix the problem. He remembered exactly where he was, rebased, and moved on. I couldn’t even keep up with him finding the bug, much less fixing it.
The people around here who have a million lines of code in production seem to have that skill, of working without the assistance of a compiler or test harness; their code works the first time. Hell, Rob Pike uses ed. He doesn’t even need to refer to his code often enough to make it worthwhile to easily see what he’s already written (or go back and change things)---for him, that counts as an abnormal occurrence.