I'm a big fan of Paul Graham. But his latest essay has me a little uneasy. Specifically, where he says:
For example, if your company wants to write some software, it might seem a prudent choice to write it in Java. But when you choose a language, you're also choosing a community. The programmers you'll be able to hire to work on a Java project won't be as smart as the ones you could get to work on a project written in Python. And the quality of your hackers probably matters more than the language you choose.
Java programmers have taken great offense at this. Specifically, when they refer to this part of the quote, almost entirely out of context:
The programmers you'll be able to hire to work on a Java project won't be as smart as the ones you could get to work on a project written in Python.
Why am I uneasy? Because Paul is flirting with
poisoning the well. So Java programmers are dumb. If you want proof, look at all the blather they have spouted arguing with Paul asserting how non-dumb they really are. (Here is a
list of links into some of this discussion.)
Now, I happen to agree with the overall message Paul was trying to convey. He has since clarified his point. It's not that Java programmers are dumb, it's that, on average, Python programmers are smart.*
And, when this essay is taken in its entirety, Paul is really saying that he doesn't know any great Java hackers personally, but his opinion of J. Random Pythonhacker is generally much higher than J. Random Javahacker.
Furthermore, Paul was trying to be provocative and get us to accept that variability of programmer skill is a fact of life. Smart companies will aim for the most skilled hackers, not the most widely accepted toolchain. Smart companies will accept that there is great leverage paying a slight premium for great hackers (regardless of toolset). That leverage that makes it very desirable to hire a small number of his so-called "great hackers" compared to a large number of middling programmers. **
But that doesn't excuse a logical fallacy, accidental though it may be.
* I read somewhere that this is not a characteristic of Java as a language, but a characteristic of its mainstream status. Some programmers don't care much about coding, and just want to collect a paycheck at the end of the week. By definition, these are not great hackers. Avoiding a mainstream language (like Java) goes a long way to avoiding these people a smart company does not want to hire. Because Python is a boutique language, it's almost impossible to hire a Python hacker who is in it for an easy paycheck. Similar statements can be made for Perl, or Perl + some CPAN modules.
** I once worked in a shop where we had a team of "star programmers". Our main tasks were to figure out the hard problems and do the heavy lifting so our projects could be shoved onto some entry level programmer's desk. Because it was dirt simple to hire a floor full of entry level programmers, our manager saw his job as getting his star programmers to fire on all cylinders all the time, and shuffle the mostly completed project onto entry level programmers. Because entry level staff was cheaper, he could afford to let them spin their wheels for a week, or just sit idle.
A smarter manager wouldn't hire by body count, and would have replaced the stable of entry level programmers with a few great hackers. Entry level programmers, when hired, would pair with their more skilled colleagues to become great hackers themselves. Keeping a bench of entry level programmers ready to spin their wheels doesn't do anyone any good, and hurts the projects as well.
LISP hackers are smart too.
brian_d_foy on 2004-08-26T16:25:01
I took his comment to mean the same thing he's been saying for years about LISP people. The higher end of the bell curve migrates to the niche tools.
Stupid Programmers, Java is for Kids!
scrottie on 2004-08-29T01:15:08
Re: smart programmers gravitating towards
niches, yes, that's absolutely
one part of it - perhaps the most
significant part.
Smart programmers working in an
environment safe from the effects of failure, separated from conflicting views,
will develop egos and fall pray to
"bad hubris".
Programmers not "held to fire" by programmers
using competing languages will tend to
assume by default that their language and
methodologies must be the best.
For lack of competing standards of excellence,
their benchmarks for quality and productivity
will drift until they're radically out of whack.
Microsoft hires the best and the brightest -
everyone knows that. Most people in the trade
know someone who has interviewed there.
People have compiled the legendary Microsoft
interview riddles.
Why is the largest softare vender also
stigmitized with a reputation for poor quality?
Lots of reasons, but reading
Anatomy of a Software Bug
the other day, I was floored by the hubris.
And no, not the good adventurous, optimisitic hubris we all love.
This hubris was a frightened, cynical hubris.
I'm going to bash Microsoft in this article.
There are plenty of software companies that
charge a lot, leave their customers in the
lurch, and feel as though they have no
accountability to anyone, but Microsoft
is the best known of these, and it was
artifacts from them that prompted this line
of thought. I's somewhat unfair that I'm not
roasting a less hated but just as deserving
company.
Chris Pratley, also a Microsoft well-known
blogging on the same, had also written an
article earlier with repeated assertitions
that Microsoft should not be held to the fire,
the readers just don't understand, and
we're no one to question Microsoft.
These assertitions were separate from the
technical information, and the technical
information was extreme interesting, as far
as looks into the quiet software giant.
The "Anotomy" article had the same theme of
asserting that Microsoft is doing a good job
but the readership of the article just doesn't
understand what it's like, and that's where
it went wrong - I do so know what it's like
working on very large projects. I've seen
hosed large projects and large projects that
stretched you every inch but were fundamentally
sane.
The "Anotomy" article asserted a lot of
things as technical absolutes
that didn't sit well with me, and
these were things I recognized from failed
software projects.
It's little wonder Microsoft hadn't opened
up before, but opening up is usually the
best way to avoid demonization, and I'm not
sure which is worse in this case.
Quotes come from the article:
"Nonetheless, the developer took a different approach. Knowing that the undo document was very likely to be involved, one could walk through the undo document, and copy the text for any pieces that pointed to the previously-saved version of the documents file to the scratch file. He coded up the solution, and handed a buddy-build off to the tester."
"very likely?" No. You don't apply "fixes" without understanding *exactly* where and why things are going wrong - even if you must refactor the whole project. If no one there
can understand why it's failing, it almost
certainly needs to be refactored.
"In order to understand this, we have to understand a basic principle of fixes. You make the simplest code change required to fix the problem. This reduces the chances that the fix will cause some other problem that is, potentially, worse than the one youre trying to fix."
No. This is not a "basic principle of fixes".
This causes cruft accumulation - especially in this case where a design limitation is being hit,
which is the case that this article describes! That goes back to my first point. The _best_ fix should be applied, with a thorough understanding of the entire subsystem or system. The system should be modular and use very little global state to make it easy to understand everything related. This guy is describing voodoo coding.
He's describing the greatest minds at Microsoft voodoo coding. That's scary.
The error they're having is a "Disk full" error, but the real problem is that the process cannot open any additional files. Users are often confused by cryptic, vague, or incorrect error messages, but that developers took 10 years to figure out that the process was running out of file descriptions is really, really frightening. As a software developer, were I to walk into a large project cold, I expect that I'd be able to diagnose a file descriptor leak within a day. Maybe two days if the first day was an off day.
"Well, you might as well ask why police departments continue to have a large number of unsolved crimes on the books. The issue is the same: the investigation stalls for the lack of any further leads to follow."
He can't debug something without a groundswell of ultra-specific reproducable steps from your users, and you get more bug reports than any other software company on Earth, and they still aren't enough? This is amazing. Free Software developers, when resolved to fix a hard problem, will take core dumps and stack back traces from the field and effectively use those to solve the hardest of problems. In a crime investigation, you can't search every location, find every suspect, and monitor every action. When programming, you most certainly _can_. This is a poor analogy - or rather, a weak excuse.
Back to hubris.
Stories of the hard-to-solve bugs are
usually intesting. They're like detective
novels. But this one reads more like a tragedy
of errors.
They can't debug something for 10 years.
Yet hubris tells them that this is a _fine_
pace to debug at, even with leigons of
programmers.
Developers, working on projects with
like-minded developers, are seldom made
aware of the limitations of their tools
or methods.
A Perl programmer is confronted daily by
PHP programmers ("PHP is easy! I bought this
book and now I make more money than you!"),
Python programmers ("You should be fired
for writing code like that"), and a host of
others, including Java programmers ("our
specifications are of the formal variety!
Want to see the UML?"), C# programmers
("C# is now the preferred language - didn't
you hear?"), and so on.
Java programs are seldom one-man efforts.
Java programs are almost always the result
of teams with year or two development timelines.
Working with a mainstream language,
your nads aren't held to the fire.
Whether or not it makes you dumb, it sets
you up to fall at the hand of your own pride.
(If I were really a Perl programmer, I'd have
been able to make that point in 1/10th of the
characters).
((Sorry to bother you all with this, but
community and software qualtiy has been
on my mind a lot lately - I see things go
wrong, as with Microsoft, and I want to know
how to it happened so I can avoid it for
myself and the projects I love)).
-scott
