
Forty-five times faster at programming - mbrubeck
http://imprompt.us/2011/forty-five/
======
abeppu
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.

~~~
sophacles
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.

~~~
joe_the_user
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.

~~~
Peaker
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.

~~~
joe_the_user
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.

~~~
Peaker
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.

~~~
nostrademons
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.

------
jerf
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.

~~~
regularfry
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.

------
edw519
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.

~~~
yesimahuman
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.

~~~
Tiomaidh
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'".

------
sayemm
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."

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

~~~
kgo
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.

------
pnathan
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.

------
Sukotto
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

------
drallison
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.

------
rodh
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.

~~~
bcaulf
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.

------
d0m
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.

~~~
regularfry
> 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.

------
mikeytown2
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.

------
Dnguyen
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?

------
philbo
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?

~~~
HelloBeautiful
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).

------
dman
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.

------
giberson
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.

~~~
sophacles
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.

~~~
giberson
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.

~~~
sophacles
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.

------
kaffeinecoma
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.

------
extension
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.

~~~
bcaulf
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.

------
LMDenys
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?

~~~
pmb
<http://www.manhattan.edu> \-- Manhattan College

------
jarin
I actually got _slower_ as I got better, because I started writing more tests
:)

------
w00t
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.

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

~~~
pmb
38 for arkanoid. The bubble game was 26.

~~~
Tichy
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? :-)

~~~
pmb
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.

------
rorrr
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.

~~~
lyudmil
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.

