Forty-five times faster at programming | Hacker News Reader

Forty-five times faster at programming

imprompt.us

97 pointsmbrubeck58 comments

There's totally a selection effect going on here.

- The professor gets to pick the problems; of course he picks ones he can solve quickly and easily.

- The students are taking a class from this professor; presumably they lack certain skills or knowledge which he has, and which will be developed during the assignments.

When we normally observe '10X' differences in programmer productivity, it's not the case that one of the programmers being measured is picking the tasks for all the others, and that the others being tested are selected on the basis of not knowing (or having only recently been introduced to) central concepts required for those tasks. Even if his measurement of the students' programming time is solid, and even ignoring that he and his students have different incentives (his students don't necessarily benefit from speeding through assignments), of course you see a dramatically wider difference in programming speed in this case than in most contexts.

The tone of your comment suggests you think the guy is bragging or showing off, or something -- I really doubt it.

Maybe the guy is trying to be a better teacher? Maybe he thinks that there is a real effect aside from the selection effect you observe, and is trying to maximize his teaching? Maybe he just wants his students to do well?

I submit that the answer to all these is yes. My evidence is that fact that the article ends with questions about how people learn to program well so he can incorporate it into his course.

If the 'some programmers can be often 10x more productive than their colleagues' statistic is interesting, then this one is too. The 10x probably refers to experienced developers on both sides of the equation; this statistic is more like 'talented beginner' vs 'talented and experienced expert.' It would be interesting to see other calculations like this. If you can work out exactly what makes someone 45x more productive then maybe you can hire/freelance more efficiently for individual tasks.

> If you can work out exactly what makes someone 45x more productive then maybe you can hire/freelance more efficiently for individual tasks.

You don't need a study to figure that out. When your project needs help in a specific area, just hire someone who is an expert in the area. No matter if that person is clever or even talented: As long as (s)he is clearly experienced in that field, (s)he will work a lot more efficiently than anyone else in your team.

And of course you should have someone in your present team working with him/her or at least reading and adapting her/his code, so you get more people of your team up to speed. Also, that way you'll notice timely in case the expert status isn't justified (i.e. in case the "expert" wasn't one).

The "some programmers are X times faster than others" phrase is extraordinarily strong and in my opinion destructive meme.

The reason believe this meme is destructive is because it mostly powers the approach of "if there's a problem with the development process, it's because we have the wrong people" rather than "we have the wrong methodology, we have a broken relationship between customer and programmer" or any approach that could get your existing people working smarter.

In any case, A computer science teacher should, at least, be well aware that a post like this is feeding the meme.

Concomitantly, anything that debunks the meme is worthwhile.

I find it hard to believe that some programmers don't believe in the huge productivity differences between developers.

Of the people I personally know, there's absolutely no circumstances under which the slower developers could reach 1/5th of the speed of the fastest developers. There's just a huge gap and it's not just methodology. If you haven't witnessed it, you must have been put in very homogeneous environments.

Also, if a methodology change speeds up the slow developers by x%, it will probably speed up the fast developers by x%.

One exception to this is when workflow/task splitting is properly done. Then the "good devs" can do the hard stuff, and create the toolset/primitives for the rest to used to build the product. This split will make the "lesser" devs more productive while making the "good devs" the same amount of productive.

I certainly have seen huge gaps in apparent ability. Usually, the "slow" programmers simply don't know how accomplish certain things - for some tasks, I am infinitely faster than an "average programmer" - for example, if the average programmer doesn't understand what a recursive descent parser is or doesn't understand that a database require logical constraints.

However, a team's productivity can be made N times greater if said adopts a coherent process, including education to fill in the gaps of "unproductive" programmers.

It is certainly true that a certain percentage of unproductive programmers would rather quit than upgrade themselves. I've worked with them. But a management approach of demanding a willingness to learn will give you an environment 100x more pleasant than a management approach of shouting "we want A-players". And said approach might indeed improve the total productivity of the team.

I agree that the less productive programmers ought to be willing to learn and can improve.

But at least in some of the cases I know, the difference in productivity is based on a couple of extra decades of intensive experience (fanatic code-all-day experience) and does not get narrowed down significantly by studying new techniques.

I agree these are the outliers, though.

In my experience, there's fairly little difference between programmers in lines of code per hour. The most I've seen is a factor of about 3, measured over a couple years, and it's largely because the slower programmers are working on harder problems (that require more thinking), or the faster ones work longer hours, or the faster ones do more copy & paste.

There is, however, a massive (orders of magnitude) difference on impact that the better programmers have. And that largely comes with being familiar with high-leverage development practices, being willing to apply them, and being alert to opportunities where a process can generalize to a large scale and investments in automation are worth it. So for example, one programmer might spend a couple hours tracking down a bug, while another programmer spends a week improving the compiler's diagnostics and then a couple days writing a script that applies that and automatically fixes several hundred occurrences of the bug across the codebase. One programmer might spend a month refactoring 30 or so source files, while another programmer spends that month writing a script that fixes 5000 source files. One programmer might waste 6 years of his life writing Web 2.0 startups that nobody uses, while another might spend 6 years of his life inventing Google.

These are all teachable skills, but they can take a while to teach, particularly the ones that rely upon judgment.

I didn't think he was bragging, and I'm totally willing to believe that he just wants to teach better. I just think that he's wrong to believe that (a) the 45x difference is surprising, given the way he seems to have taken his measurements, (b) that given his observed 45x difference, we should then expect there would be a similar 45x difference in programming speed on tasks not based around the material in his course, and (c) that this is evidence of some sort of deficiency on the part of his students that he as an educator should fix. I don't think his problem is ego; I think his problem is an unusually flawed way of comparing programming speed.

You got some points. I think programming is like looking up in dictionary. It's much faster if you use an electronic dictionary. Buy it's even faster to forget that word. Using a paper dictionary is fun. It's slower but will help you remember the word better.

The students are much slower than the professor, but they may learn much more than the professor. So I don't think speed them up is really important.

I've never liked 'speed' as a programming metric because it's very deceptive. In this case we're talking about students going through some very basic training, and who will do things like blow 3 hours on a trivial-to-me syntax error... but it's "trivial-to-me" only because I, too, spent three hours on trivial syntax errors. I would expect these essentially "constant factors" to be dominating here.

I really don't like speed because there's a quality difference, too. I may not necessarily beat a fresh-out-of-college kid on some task on straight clock-time, but where theirs is bodged together, barely functional, and already extended to the maximum limit, mine will have a strong unit testing suite, be efficient, extensible, scalable, fewer bugs, probably even fewer features in places I know they shouldn't be, less code overall (despite the unit test suite), etc. And there will be tasks I can complete that they can't even get close to; what's the multiplicative difference between "I built a scalable system that serves millions" vs "I couldn't get the system to do anything useful" in the same time period? The productivity differences are really more about quality than raw speed. There are speed differences, certainly, but I think it's dominated by the quality difference.

Isn't that the whole point? If we can find a way to get rid of the "constant factor"-type problems, the students will have more time to concentrate on the overall quality rather than just handing in whatever they've been able to bodge into a working shape. Not only that, but it would get rid of the single most frustrating part of learning at a stroke.

First comment: What made me faster? Practice, practice, and a healthy dose of more practice.

What made me faster? Copy, paste, and a healthy repository of stuff to copy and paste.

Reuse of old code, familiarity with API's (other's old code).

Practice, but also starting to look at problems in a more realistic way. For example, I used to marvel at how one might make a simple 2D game. Now, I realize it's a lot of illusion and design based off of some pretty simple ideas. I think a lot of young developers are fearful of problems because the output seems magical.

Writing a 2D platformer this year was one of my more enlightening programming experiences. It absolutely made me draw the line between "Things that are theoretically correct (and impossible to implement)" and "Things that can be implemented easily and are `close enough'".

And learning from what you're copy and pasting.

Basically, his brain is a giant L2/L3 cache.

I thought 25 minutes was pretty mediocre for the bubble game, and re-did it without any copypaste etc (not that I had any bubble game libraries available) and was surprised it took me about 35 minutes. It was really a typing test more than anything though. Amazing that even bad students would need 20 hours for that.

In "Programmers at Work", Bill Gates makes a few interesting comments on programming speed and innate ability (pages 82-83):

"I still think that one of the finest tests of programming ability is to hand the programmer about 30 pages of code and see how quickly he can read through and understand it... A lot of people would say, "I want days and days to read this." A really good programmer would say, "Let me take that home with me. I'll just spend an hour tonight and go through the whole thing". The difference of ability there is vast."

Sure, but reading code is quite different from writing code. Not necessarily easier, but different enough that I think it invalidates the comparison.

I can see what he's getting at - programming involves building up a mental picture of everything that's going on in your program. Of course most professional programmers probably don't work on a single project for months that's all theirs, they have to work with modules/interfaces developed by other people - when you don't have the luxury of writing all the code yourself (even terrible programmers know what's going on in their own spaghetti), being able to comprehend complex systems in a few hours is a huge advantage. They might still write terrible code if they were never taught good practices, but at least it does show ability/potential.

I'm assuming Gates is talking about a reading comprehension test. Like the ones grade school where you needed to read a paragraph and then determine the age of Mount Rushmore. How someone did as part of the follow up (What did you think of the architecture? How would you implement feature X?) would be a pretty good gauge of their skill. Since they're discussing a real code base, it's harder to fake it for the guy who knows all the buzzwords and all that but can't deliver.

Interesting. I have heard many good programmers say that to them reading code has become more important than writing code.

The blog poster is actually only asking for help getting his students faster. He's not looking to pontificate.

But, I will. Since it's the Internet and all...

One of the things I find intensely irritating is the presumption that classroom effects significantly correlate with industry effects.

Many/most students are still learning. It takes years to really start getting on top of your game. Further, even if the students are highly competent, e.g., a typical "young hacker", the activities are very small and limited.

So studies and anecdotes (plural of anecdote is not data) regarding student or professional performance in a classroom environment just isn't realistic.

Here's some of what I've found helps make you faster.

- Learn the idioms of the programming language and problem domain(s)

- Keep your hands on the keyboard and OFF the mouse

- Get the best set of tools you can and learn to use them like an extension of your own body. If you have to stop and think how to use your tools then you lose any momentum you have thinking about the actual problem. (Pro tip: start by learning to touch type, then editor hotkeys.)

- Anytime you solve a new problem. Spend time afterward making a more general solution. Then file that solution in a snippets file, utility library, or wherever is the first place you're likely to look for it when you need it

I think there are a number of possible sources for the observed phenomenon. Students find it very difficult to get started. Students also find it hard to abandon code preferring to try to make poorly structured and thought through code rather than starting over. Finally, students find it hard to invent the abstractions that they need to solve large problems from whole cloth. Programming classes often concentrate on the details of expression and ignore the issue of using them to create patterns and abstractions to solve real problems.

One way you can improve things is to provide a framework for each of the assigned problems, either a program with stubbs or a working program which can be adapted to solve the assigned problem. I don't know how you teach students to throw away code rather than trying to make it work. Finally, teach programming rather than the programming language.

I also have found that having many small assignment works better than having a few larger projects. When I taught beginning programming I assigned on or two small programs per class meeting whereas the other sections had three larger projects. It is also useful to have the small assignments provide a library of abstractions (procedures) which can be used in later assignments. I also think it is useful to teach test focused programming where student need to present tests which validate their program as well as the program. These days I'd be tempted to require students use one of the source code control systems, probably Mecurial.

Given the included JAR files, I'd be interested to know if the author measured only his performance in coding Java against his students.

Although I usually code in a basic text editor, Java is one of those languages in which I personally found setting up and getting familiar with a good IDE makes a huge difference. Back at University, my pure CS professors initially discouraged us from using Eclipse, Netbeans, etc. They certainly didn't want to teach us how to use them.

Great observation. Java requires masses of scaffolding just for Hello World and for this reason is not IMO a decent introductory teaching lesson. I taught an introductory programming course and I was required after several semesters of using Perl to switch to Java. It was awful to lose the ability to do one-liner scripts.

I also taught an introduction to the Korn shell and Unix environment. Since shells have a REPL, you can make an easy shift from entering commands to putting a list of commands in a file and running it. Super helpful for learning. Not possible with Java.

Both I and they used NetBeans.

What is the goal of the class? Is it to become a professional programmer or more of an introduction to programming?

If the answer is the first, nothing beats hours of hacking and curiosity to learn in their free time.

However, if the answer is the second, maybe another approach could be used. For instance, is it really important to know the syntax of all small details if those students won't even use it? (Remember, I'm assuming it's more of an introduction).

Maybe, something more educational, would be to have a bigger view of what software engineer is. Talking about the re-usability of modules, the different platforms/languages/patterns/paradigms or real world example huge projects. This way, the student will get a way better "feeling" of what programming is rather than trying to get a theoretical/trivial program to compile due to lack of experiences in that field.

Another suggestion would be to give the students a better set of high level tools to solve bigger problems. Let them have the role of a software architect working for Apple which is working on the next version of iPhone. So, instead of focusing on the small details, the student choose the features, carefully design the UI, think in terms of money/time, etc.

> If the answer is the first, nothing beats hours of hacking and curiosity to learn in their free time.

Why need that be true? There's nothing in the nature of the problem to prevent there being a method for improving skills at a rate faster than hours spent hacking would. I just don't know what it might look like.

It's definitely the case that small study groups can accelerate learning, but it's so dependent on the composition of the groups that I don't think it's generalisable reliably. Dedicated one-on-one tuition can be astonishingly effective, but it's highly dependent on the tutor and again, not generalisable until we can figure out how to efficiently train tutors.

Programming is a lot like learning to run. It takes about a year for a baby to walk; and another 2 before they learn how to run. In another 4 years (age 7) most kids are fairly good at running. Programming takes years of practice to get good at it.

Another analogy. Poetry & Programing have a lot in common. Once you learn to write it, creation is easy; good creations take practice & skill. Iteration is key.

I would reiterate the practice and practice mantra. But I think it's more of knowing where to find information. Being a professor and many years of experience, the information you need to look up to compete your task is just a thought away. If not, you know where to go find the information online quickly. Whereas, the student struggle with IDE, looking up information from the book that you assigned and google. On top of that, you are confidence that your solution is correct, versus the student may not be as confidence; lacking confidence slows down your progress tremendously I believe. But that's another topic. I think even with google, the student still have to look for an example that is similar to what they are trying to solve, understand the example, and assimilate to their solution. All of that takes much more time than you having the knowledge in your head. To better compare, you should ask them how they go about solving the problem and you try to do similar steps. Now, are you still 40X faster?

Is programming speed something that a university lecturer really needs to dwell on like this? I would have thought speed is more a natural by-product of familiarity than something that can be actively taught. And even if it can be taught, is there merit in actively working on it rather than on, say, ensuring correctness?

Speed can be taught (ask any pro athlete).

Speed is worth teaching (ask any manager).

Being able to solve small problems fast makes one capable of solving complex problems (divide and conquer).

A reformulation of the question as "What contributed to improving your programming speed?" would be nice. Concentrating on why or how the professor is faster is only indirectly useful, coming up against tips that helped people improve in real world scenarios is much more useful - at least to me.

I suggest that it is rather absurd for the professor to expect the students programming speed be on par with his own--unless he's asserting that he himself is a poor programmer.

The one thing a professor aught to have in spades above his students is experience. And the only thing that speeds up a programmer, simply, is past experience. Being able to recognize patterns and problems and having a general idea of their solutions is 90% of the programmer's ordeal.

It's only reasonable to expect students to require a non trivial amount of "working it out time" as it's something all programmers go through. The first time you experience a problem of a specific nature you need to contemplate, research and explore the subject trying to flesh out the underlying logic of the problem. After which, you can finally devise a proper solution.

Its also important not to forget that as an experienced programmer you have the discipline to break problems down into smaller manageable components. Students, on the other hand, often are stuck blinded from the trees by the forest. Rather, they are daunted and intimidated by the entire problem set.

I also have to reluctantly point out, that the education for programming at Jr. and Sr. level classes is quite poor. It's kind of a scam. It's paradoxically too brief, too broad, too specific too general all at the same time. From experience, anything sub 400 level classes were simply credit padding courses. For programmers, real programmers that are actually curious and excited by programming who actually invest personal time to explore and enrich their knowledge of the subject as a hobby will get very little out of those courses. They have to sit through instruction on conditional programming, worse sit through hours of insane questions of incomprehension on simple if, else, for and while loops. By the end of the course, you get to do one interesting assignment, it's what the entire course was building up to, and all it is is a generic useless implementation of some common design pattern. The apex of those courses for me were doubly-linked lists, stacks, and knowing how to implement Huffman encoding. All of which I could have figured out on my own. The other type of programmer, the programmer by career appeal--the programmer who thinks I'll just take a couple college courses and land a cushy high paying job, these courses offer them basically nothing aside from an introduction to language syntax. The ugly truth of the matter is that the language portion of coding, the syntax and grammar is the smallest most inconsequential portion of programming--It's simply the tip of the ice-burg. What lies beneath is a solid understanding of logic, how to identify, adapt and apply reasoning. It's problem solving.

Overall my point is simply this, unless you figure out how to compress the sum total of you X++ years of experience as a professor [obtained from industry and as a teacher], and then figure out how to impart all that knowledge to your students there is no feasible reason why they could or should be as apt at programming as you as a professor.

The impression I got from that article was a concerned teacher, wondering if this gap was normal, and how he can increase his teaching prowess to help the students better. Basically the guy was looking to do better at his job.

As for how smart you are: wow thats great -- have a cookie for having interest and aptitude above and beyond other students who may also have that interest and aptitude, but did not discover that fact on their own.

Don't get me wrong, I'm not trying to elevate myself or be self promotional. I'm by far not one of the smartest programmers. I'm a good programmer, I "get" programming but I'm far from even thinking about trying to teach others how to program. I'm simply identifying two typical sides of student population for programming. From my own experience there were two very apparent groups of students. Aptitude wise, there were those that were cut out for it and those that aren't. I was in the group of students who was [and I'm not even insinuating I'm at the top of that group] and it was in common agreement that the pacing of the courses was inappropriate for either group. It was too slow for us, and too fast for them. It's just not possible to strike that balance. The first year or two of college programming classes is really for weeding out the batch of people that aren't cut out for programming. The people that make it through this selection have yet to really enter into serious programming topics. My point for stating this, is to make it clear that Jr or Sr level students aren't seasoned, they are simply the selection of students are are capable and ready to be turned into good programmers. They are still seedlings though, and can't be expected to compete against some one at a professional level.

Perhaps my wording was a little to aggressive in my comment, I wasn't trying to attack the professor, I was only trying to make it a clear point that being comparative between a seasoned professor and naive programmer is well, absurd.

To determine the people "cut out" or "not cut out" for something, based on a single class or two ignores a host of problems which have nothing to do with aptitude nor interest in the material. The way it is taught, the teacher, the fellow students, all contribute to success in an academic endeavor.

Further, some people struggle with subjects for a long time, then one day "get it" and surpass those who were obviously in the good group all through studies. Some people thrive under one teaching methodology and curriculum and others thrive under different conditions.

Basically the thing you describe only selects the subset of people who represent the intersection of the sets (people with an aptitude for proramming) (people who thrive under this curriculum) (people who get it quicly/incrementally). There could be plenty of other people in the (people with and aptitude for programming) set.

Another vaguely related bit of thinking: A lot of the best programmers I know come out of non-cs curriculums like math, music, geography, philosophy and so on.

From the article, he wouldn't have been surprised at even a factor of 10x, he clearly wasn't expecting them to perform as well as him.

A lot of the speed difference comes from having spent one's time learning the basics. After you've spent 5 hours debugging a mis-placed semi-colon, you tend to remember that kind of mistake and avoid it in the future.

But if the idea is to prevent wasted time while learning, there's a simple solution: have the students do pair-programming, preferably with someone who's already learned the basics. Or at least let them all do it in a lab, and have the prof walk around to help out students who are stuck. Not for their entire college career, but perhaps for CS 101.

Generally speaking I'm not a fan of pair-programming, but this seems like a good application for it.

What makes one programmer an order of magnitude faster than another is the ability to intuit an algorithm to solve a novel problem. Where one programmer struggles to wrap their head around a problem and the other immediately sees the solution, that's where you will find such a huge difference in productivity. This intuition comes from experience, but some learn much faster than others.

Mastery of tools, languages, libraries, posture, etc. are significant but not to the same degree.

Agreed. Or better, the ability to easily see a number of approaches all of which would work (algorithm designers love to publish improvements on the state of the art), then go about selecting perhaps the simplest. If performance is an issue, one that meets the performance requirements. If future changes are anticipated, one that won't make that too difficult. Doing all this without the need to do time consuming research is what makes for productivity.

If you would like to retrieve that old facebook conversation, it might be possible with greplin (https://www.greplin.com/), a search engine for your online personal content. It's nice to see a professor be so devoted! At which university do you teach?

http://www.manhattan.edu -- Manhattan College

I actually got slower as I got better, because I started writing more tests :)

This guy obviously spent too much time in academia. It's things exactly like this that make CS graduates less and less prepared for real software development carriers.

What do the jar-Files mean, did he program an arkanoid clone in 26 minutes? That would be impressive.

38 for arkanoid. The bubble game was 26.

I'll try that exercise myself asap, but my estimate would be more on the order of 3 hours or so.

Of course I'll have to look up a lot of things (I'd do it in HTML 5, so I'd have to double check the API for either Canvas or DOM). I suppose if you know the API mostly by heart it would help a lot.

In fact your article inspired me to put more effort into knowing the APIs. Could be because I was a Java developer for the most time that I got into the habit of always looking stuff up, even if I already knew it - I just felt like double checking a lot. Or maybe knowing the API could be substituted by a good IDE that suggests everything?

What are the rules for speeding up the ball in Arcanoid? :-)

It speeds up when it hits the paddle. If you do this exercise, make sure to actually time yourself, rather than guesstimate it afterwards - time slips away when you program.

I remember when I went to programming competitions ACM, Topcoder and like, we would have to solve 5 to 8 hard problems in like 4-5 hours. After that most homework CS assignments seemed like a joke, yet most students would spend days just to compile something half-working.

Most CS students are not trained to solve problems. They are taught algos, some language basics, but they only have to code 2 or 3 small programs per week.

We had a programming club where we would solve 4-5 problems in one hour, and only like 5 people attended it, out of ALL CS majors of ALL years.

And that's, kids, why it's so damn hard to find good developers.

Agreed, that was similar to what I've seen with other programmers and with my only education. I profited greatly by taking engineering courses for a while, and they teach how to problem solve. I've also observed that others who have had a similar experience do well with problem solving (but also those with math background, which is counterintuitive to me). Small sample sizes for both, but they have been pretty consistent.

I also did CS competitions in college, but I always felt they over-stressed speed. They are for quick problem solvers, who are also comfortable with the languages the competition accepts. However, the way I see it, merely being sharp and knowing a language well isn't good enough to be a good programmer. Programming to me is a strange mixture of problem solving, technical knowledge, design, writing, and typing and a good programmer is good at all of them (throw English in there as well if you're not a native speaker). Problem solving and typing are things they teach you to get a CS degree, and it's what those competitions measure, but most of our submissions were really poor code, even by my standards at the time.

[Edit] Add discipline to my long list of essential virtues for a good programmer. Discipline is a big one.

Reply on news.ycombinator.com