The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

My critique of "Hitting the High Notes"

I wrote a critique of Joel's "Hitting the High Notes" in my blog:

I'd live to hear your comments, and you can post them either on LiveJournal or here.
Shlomi Fish Send private email
Friday, September 02, 2005
I actually agree with you regarding Joel's emphasis on coding speed as an important attribute of high-note-hitting software developers. Personally, I think coding speed should be relatively low on the list.

But you and Joel both failed to mention what I think is the single most important quality of an excellent developer: Problem decomposition and solution modeling.

It's the ability to decompose a new and complex problem into multiple potential solutions and then to mentally evaluate the advantages and disadvantages of those solutions. In cases where the problem is too complex, the developer should be able to identify which types of complexity can be reduced or discarded without significantly affecting the correctness of the solution.

When the rubber hits the road, the most successful programmers are going to be the people who can solve problems. Not the people who memorize the documentation or who learn new APIs quickly or who can write their code slightly faster than the next guy.
BenjiSmith Send private email
Friday, September 02, 2005
Actually, it has *nothing* to do with actual coding speed.  It has to do with the depth of understanding.

For example, after a year or two of high school Spanish, you can probably muddle your way through a front-page news article and get the general idea... even if you didn't get the specifics and had to skip entire paragraphs.

If you are *fluent* in Spanish, not only will you get the general idea, but you'll get the specifics AND do it in a much shorter time.

SPEED is an effect of the understanding and therefore can serve as an INDICATOR of such understanding.
KC Send private email
Friday, September 02, 2005
Indicator yes, but if you proof read you have to have even deeper knowledge and it is even a slower process. i.e. if a good programmer with deep knowledge is a little on the slow side maybe he is going over it and veryifiying and validating his work before he unleashes out for general consumtion.
Take a guess.
Friday, September 02, 2005
I work in an industry where writing code fast is essential and the people truely are brilliant. I think writing code fast shows that you understand the problems and how to solve them and the code part is just secondary.
Tom Vu
Friday, September 02, 2005
All things being equal, I'll take the fastest developer/programmer/coder/problem solver/whatever-word-or-phrase-you-want-to-use-for-the-person-that-expresses-the-solution-to-a-problem-in-code any day of the week and twice on Sunday.

I think that was the point of taking the data from the top 25% of the grades. There was still quite a disparity in speed, even among those that all got the problem. The range of the highest scorers was from 15 to 50 hours.
Bart Park
Friday, September 02, 2005

Excellent critique.  I don't believe there's an empiric axis to measure a programmer's "goodness" on, as programming positions vary so widely in personality demands.

Some jobs require you to be spec and detail oriented, others require a visionary.  Some require an outgoing nature, others are solitary.  Some code has to be maintained over years, other code is a one-off.  Does the person need business savvy or only technical skill?

Joel has a set of things that he asks out of the position of "programmer".  My company has different needs, as does yours.

Linus Torvalds is a great programmer, but I wouldn't want him maintaining my CRM system.

Some of these discussions risk becoming a "what is the nature of intelligence?" debate.  Yes, some people are smart and good at a lot of things.  Others are dumb and good at very little.  But there's a lot of grey area.

My personal #1 skill I want to see in a developer:  The ability to reduce a problem to the smallest, cleanest, most elegant solution with the least amount of code.  Someone who doesn't want to "solve" a hard problem, but wants to break it into a set of easy ones.
Bill Carlson
Friday, September 02, 2005
As is being pointed out, the core problem with "High Notes" is the fallacy of establishing a "best" criteria, as in "the best programmer". It's like saying "the best camera" but with even more dimensionality.

I guess it works for Joel; to my ears it sounds like the socially elitist culture of the former "big seven" consulting companies with the emphasis on "best school", best GPA, etc.

I think it comes down to looking for clones of yourself. Joel wants to staff with people just like himself.
Bored Bystander Send private email
Friday, September 02, 2005
<i>Someone who doesn't want to "solve" a hard problem, but wants to break it into a set of easy ones.</i>

Umm... that is how you solve a hard problem. Breaking into a set of easy problems is hard.
John Eikenberry Send private email
Friday, September 02, 2005
Hi guys!

Very nice comments, I'd say.

Right now, I'll just note that I'm not sure that it is necessary that a person who understands the technology well will write working code quickly. Some people can have a very solid and thorough understanding of their programming environment, and yet simply be slow coders.

Possible reasons for slow coding despite a good understanding are a slow typing speed, old age (I know a hacker in his late 70's who still works on projects), lack of intuitive "programmer's sense", lack of experience, making lots of stupid mistakes, becoming diverted by various factors, etc.

Some good programmers are much faster than other good programmers, but the latter also produce good, working results eventually.
Shlomi Fish Send private email
Saturday, September 03, 2005

I agree with you that what you describe is very important. And it is possible that there's a large variation in this between programmers.

I did not mention it in my critique and probably wouldn't have thought about it, so thanks for bringing it.

Again, while this is an important factor, there are also other parameters that at certain circumstances can prevent a programmer with exceptional skill at this, to be considered unsuitable for hire.
Shlomi Fish Send private email
Saturday, September 03, 2005

oh and I forgot to mention that what you say may already be accounted for in the analysis Joel mentioned.
Shlomi Fish Send private email
Saturday, September 03, 2005
I think raw coding speed is a terrible measure, especially if this is interpreted as "lines of code per unit time". Similarly, I've never understood the fascination with evaluating people to stand up and code on their feet at a whiteboard. I prefer to code sitting down with a nice monitor and a decent IDE myself.

However, efficient defect fixing or feature implementation with minimal defect introduction. Perhaps that is a better metric.

Saturday, September 03, 2005

"I think raw coding speed is a terrible measure, especially if this is interpreted as "lines of code per unit time"."

I don't think what the Joel analysis measures is that exactly. By all means smarter programmers can write less code that will do more. But programmers vary on the time that it takes them to write good, modular, working code.

"Similarly, I've never understood the fascination with evaluating people to stand up and code on their feet at a whiteboard. I prefer to code sitting down with a nice monitor and a decent IDE myself."

Well, I'm not using IDEs, but naturally also prefer using gvim ( )and being able to run and debug the programs I am writing. But I believe that people who on job interviews expect you to write your code at the board, don't expect you to produce perfect code but rather see that you get the general idea. Often, they just expect you to write pseudo-code and some data structure diagrams, and not real C or whatever code.

I recall an interview I had in a company for a Linux developer position. The first part involved a standard written exercise which was pretty easy, and I passed. In the second part, I was seated next to a Win98 laptop and was instructed to write a complete C library. I had to use MS Notepad (%-) and the laptop's keyboard gave me a lot of trouble. But I suppose it was still easier than trying to write working C code using on a whiteboard.

Whiteboards, however are very useful for brain-storming and for sketching out pseudocodes, data structure diagrams, etc.
Shlomi Fish Send private email
Saturday, September 03, 2005
Speed of coding or "speed of *developing*?" The synopses in the good programmer's brain start devouring the task requirements and parameters at lightning speed and he or she has mapped out a huge detailed solution landscape before someone even finishes describing the task...
Anon and anon
Saturday, September 03, 2005
' I think raw coding speed is a terrible measure, especially if this is interpreted as "lines of code per unit time".'

For that professor's statistics, coding speed was measured by the amount of time to do a given assignment, not the LOC per hour/day/whatever.  Most other studies of programmer productivity also do the same thing... time per task, not LOC.

Fast programmers are faster because they write fewer lines of code to get the same thing done, not because they write more LOC per unit time.

Look at the varying amount of LOC in that thread about the C numeric comparison.
T. Norman
Sunday, September 04, 2005
Shlomi -

I like your critique a lot.  I think that a programmer's value comes down to far more than raw programming ability.  For almost any project, it doesn't matter how good you are, if your customer/peer/boss can't deal with you, you fail. 

But I think Joel's point is just the rockstarness of coding.  There's a huge difference between great performers and average performers.

My way of looking for the "best" is different from Joel's.  Personally, I avoid the elite schools, under the theory that equally smart, but better work ethic kids went to good state schools.

This is partly due to everyone's tendency towards self-flattery (if you didn't figure it out, I went State).  But I also think to some degree, people are better at discerning among people that are more similar to themselves.  I would expect that you are better at finding good developers from people that were at Technion/elite units of the IDF/whatever.

Bankstrong Send private email
Sunday, September 04, 2005
On raw speed: I once worked with an MIT graduate who would have fulfilled all of the rock star attributes that the "High Notes" was speaking about.

The guy was an insufferable PRICK. Absolutely impossible to work with. He tended to sling out shit really, really fast that "mostly" worked. Short attention span, condescending, no documentation, a "drop & run" type who would zip through the fun stuff and leave a bunch of rubbish for someone else to clean up some day. And, a completely solo act - nobody would work with him.

I suppose that other "rock stars" reading this would assume that the management of such a person are complete retards and a-holes who were unworthy to value this guy's brilliance, who "deserved" to have the rock star treat both the work and his co-workers with contempt. That was this guy's attitude: he was in a second tier job so he'd do anything he liked.

I know Joel's a successful guy, but decades of "value of teamwork" wisdom do have their role. I tend to see the kind of programmers that Joel wants as superficially desirable but essentially unusable over the longer haul in most businesses. For starters, most of them want either huge salaries and/or an impressive title - things that a microISV does not have in abundance.
. Send private email
Sunday, September 04, 2005
I think Joel is often deliberately vague and open-ended in his essays, because the ensuing debate and parsing of semantics echoes throughout the community and thus spreads his vision.

Joel's essay is what it is.  He does not lay out in gory detail what is "speed"; in general there is a "je ne sais quoi" that is associated with effective people, and one such aspect of great developers is at least a FEELING of speed.

We've all seen it.  People who just make their craft look easy.  Just watch professional chefs cook, or great minds debate.  They make it look easy; they do in a blink of an eye what most of us can barely comprehend.

I'm not sure what the actual breakdown of ability is as it relates to speed.  Some people are very good designers, but mediocre implementors.  Others, vice versa.  Yet the two very often balance each other out in practice; a great design, for example, can often quickly overcome the hurdles of a poor implementation.

But for both types of people, I would wager there is a general feeling of speed when watching them work, and measuring their results (with real-world customers, especially).

Joel's point is, to me, quite obvious and lucid, but deconstructing and quantifying it is very hard.  That's why this is a tough business--hiring great developers is hard, and so is finding the right criteria to measure. :)
indeed Send private email
Monday, September 05, 2005
Speed is central to "best programmer" in this case.  Why?  Because this case is based on money.  Joel is hiring people for his company.  It is in his own best interest to hire people who are fast (get the same job done in less time) because he can either pay them less (less hours if hourly) or get more out of them (higher rate, same hours) for the same amount of money.

Speed is so central that you might take someone who is faster but not as eligant.  Getting the same job, or even close to the same job faster is where you make your money.  If someone is even 1% faster at the job, that adds up pretty quickly.  Joel is also arguing that the truly rockstar people are something like 100 times faster than your average programmer.  I have witnessed this, so I believe it to be true.  Speed factors into "best" because the game we are playing is always time dependent (we have limited life spans).
Joshua Volz Send private email
Monday, September 05, 2005
I don't agree with Joel's argument completely, but I do think you missed the point. The claim is not that you use speed as the only criteria to judge a good programmer, but the observation that good programmers are much more productive than average. I don't think anyone has solved the problem of identifying a good programmer without extensively working with someone. Otherwise he would be really rich.
LarryL Send private email
Monday, September 05, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz