Where Graham gets it wrong
Everyone and his brother has commented on this essay by Paul Graham. Most of the commentary has been positive; Eric Sink is one of the few who's had a contrary opinion. I've been looking at the essay, and I have to say that I've got a few problems with his essay myself. Let's have a look at his notion of why you want hackers (as he descibes them, top notch developers):
It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs. Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.
Ok, let me be extremely clear here - he's full of crap on this. What he's saying is that problems that actual users care about are uninteresting. This doesn't really jive with his assertions that startups are a great place for hackers. Why not? The best startups (you know, the ones that succeed) - pay attention to their early clientele. In fact, they often build stuff more or less exactly to the specifications of their early clientele. The minute you stop fulfilling end user needs is the minute you stop making money.
Now, Graham's assertion is that you can "protect" your great hackers by having them build "tools". That sounds nice - until you ask: "Who are these tools for"? Well, they are going to be for some set of users (Internal or external). If your hackers aren't paying attention to the users, then they are going to end up building a bunch of over-architected crap that no one wants or needs. Trust me on that last point - I was at ParcPlace, and got exposed to plenty of "hackers". We had some really brilliant people back when I joined ParcPlace in 1993 - and the ones who Graham would call "hackers" were typically the least useful developers. They would wander off and build things they thought were highly interesting - and that no one else wanted.
I recall one of our hackers touting some great browser extensions he had in 1994. I publically ripped him a new backside - because he had done all the work on the legacy browser, not the new one that was coming out for VW 2.5 (in the then new GUI toolkit). This would be the equivalent of one of our (Cincom's) engineers proudly touting some additions to the GUI builder (current) after Pollock had shipped. Cool? Maybe. Also completely useless.
That's the trouble with Graham's idea of a hacker. He elevates the sort of developer that lives off in the clouds, building their own idea of perfection without regard to what anyone else might need. You know what? I don't need that kind of guy on my team - Graham can keep him. I want the kind of people we have on the Cincom Smalltalk team now - extremely bright, highly motivated developers - who listen and respond to customers. Are they perfect? Heck no, no more than I'm a perfect Product Manager. We know who pays the bills though. I'm not sure Graham gets that part.
Here's exactly where he gets it wrong:
The distinguishing feature of nasty little problems is that you don't learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn't teach you anything, because the bugs are random. So it's not just fastidiousness that makes good hackers avoid nasty little problems. It's more a question of self-preservation. Working on nasty little problems makes you stupid. Good hackers avoid it for the same reason models avoid cheeseburgers.
Bull. I'd actually say it's almost completely the other way - if you go in and fix the nasty, stupid UI bugs you learn something about what your users (you know, the people who pay your salary) want. You learn the difference between adequate work that people accept and great work that makes people happy. Look at the difference between the VW tools in VW 5i.2 and every release since then, for instance - the "polish" that's been added (mostly by Vassili) has been more important in many respects than the added functionality. Appearance matters - a nice UI differs from a bad one in the same way that a person with a shower differs from the one without - while a shower doesn't make you any smarter, it certainly makes you easier to be around. Save me from developers who don't want anything to do with the user community. I'll happily load down any of my competitors with them.
Comments
I'm not sure Graham is talking about UI
[] August 4, 2004 18:36:42.950
My read was that he was talking about building an interface between one piece of software and another, clunky, piece of software.
[Charles Miller] August 4, 2004 19:01:04.715
Of course, stereotypically, great hackers neither shower nor care what they look like. :)
Graham is, of course, talking rubbish. All programmers are well aware of the difference between tools that were built by some "great hacker" who didn't like solving the nasty little problems, and those that came from a programmer who had experienced the nasty little problems, solved them, and wanted to share that solution.
Put a great hacker in a room by himself to produce tools, and the tools he produces are going to be baroque, and will most likely solve the wrong problem entirely, since that problem was much more interesting than the one the "lesser" developers wanted solved.
Another alternative to Graham's point of view lies in the collection of stories from the original Macintosh team at folklore.org. Here were a group of exceptional hackers, dedicated to solving not only the big problems, but all the nasty little ones too.
Re: Where Graham gets it wrong
[ James Robertson] August 4, 2004 19:10:35.000
Comment on Where Graham gets it wrong by James Robertson
It actually doesn't matter what he was talking about. The point I made applies either way
The proof is in the pudding
[] August 4, 2004 21:12:31.213
As you presumably know, Paul was a key member of a startup (ViaWeb) that succeeded. Given you assertion that "he's full of crap" about successful startups, please explain how that happened.
Where Graham gets it wrong?
[Dennis Decker Jensen] August 4, 2004 21:50:32.975
Given some of Paul Graham's other essays explaining how he solved some user's nasty little problems (in your sense of the words), it is clear that you mean something rather different when talking about a "hacker" than Paul Graham does. When Paul Graham talks about a "hacker", he is clearly not talking about a cowboy coder or a designer-in-the-ivory-tower that you describe. He is talking about a smart programmer doing difficult tradeoffs all the time, given what he knows or doesn't know (and about to find out).
I think you missed his point. When Paul Graham talks about "nasty little problems", he is talking about routine, weary, repeating and tiresome trivial problems: A company I worked for had programmers working on just correcting the semicolons in some language everybody around here knows all too well. You, yourself, have been talking about the "nasty little problems" that the curly-brace-crowd has to deal with all the time!
Given Paul Grahams other talks about relations to customers I actually think you and him would agree.
Re: Where Graham gets it wrong
[ James Robertson] August 4, 2004 21:54:44.546
Comment on Where Graham gets it wrong by James Robertson
His assertions in the article are just wrong. I'm sure it's possible to succeed with his ideas; heck, people succeed with EJB for goodness sakes. Doesn't make it a good idea though. If you hire developers who's fondest desire is to avoid users, you almost certainly won't like the results.
He's right about buggy software
[Ian Bicking] August 5, 2004 2:04:39.299
Interfacing with buggy software sucks. Any programmer knows this. And what do you get for your effort? Nothing. You can't fix the bugs. They aren't your bugs. And it doesn't help that someone else's shitty software tends to make your software stink too. You don't learn anything from handling shitty software, you just slowly learn the various quirks. There's no wisdom in those quirks, there's no master concept to understand. This is why most good web developers work on the server side -- it's a pain in the ass to work on the client side, and most of the challenge is because of unpredictable browsers. It's very dissatisfying.
Buggy software is another reason good programmers are attracted to open source (or heck, even shared source). Then you actually can fix the bugs, even if they aren't yours. Or if the software you are interfacing with is poorly specified, you can look at the implementation and figure out the real behavior. I spend a lot of time reading source code that isn't the responsibility of my company -- except insofar as it's our responsibility to make a working system, regardless of where the software comes from.
As for customers, Graham has a point, though I think there's a middle ground he doesn't identify. Customer interaction is partly about implementation, but it's also about marketing and business and all that crap. Well, maybe it's not crap to someone in sales, but from the perspective of a programmer it's crap. I don't want to have to coddle some customer for business reasons. Generally the project managers I work with do that for me. I interact with clients, sometimes directly, sometimes not. I respond to their desires, as best we can divine them. I understand that they often can't articulate their desires, or imagine a realistic solution. But I don't want to work directly with them, I don't want them calling me. I like some insulation, because handling customers isn't mostly about technical implementations, and I'm good at technical implementations. Maybe this isn't as big a deal when you are dealing with programmer customers (which is probably most of Cincom's customers), but it's a big deal when your customers aren't technically oriented.
The whole point of being in a company is having people with complementary skills. There's a place for non-programmers. A real hacker appreciates those non-programmers, because they do work the hacker doesn't want to do. There's nothing wrong with preferring not to do some work. I don't ask those other people to take on programming projects. But if those other people slack off, or if a manager transfers responsibility without authority, or some of those other stressful, unproductive situations occur, the hacker will rightfully be displeased.
That said, I find Graham's suggestion of an R & D department to be a bit too extreme. The best work is done by people who are working across boundaries. Working in web development, I have little trust in people who build web frameworks without having first built a lot of websites. Or for people who build frameworks without actively using the resulting product. The same goes for any any domain. You have to have empathy with your customer, be it another programmer or some other user. But great programs are built from empathy, not obedience -- the customer is not always right, but you should always do right by the customer.
startup that succeeded
[bryan] August 5, 2004 4:07:17.519
' As you presumably know, Paul was a key member of a startup (ViaWeb) that succeeded. ' well I have a lot of respect for Graham so I guess I won't point out that this success was in a period of time when the success to failure ratio was perhaps somewhat skewed.
mostly positive?
[Sencer] August 5, 2004 5:13:50.602
Hi,
> Most of the commentary has been positive; > Eric Sink is one of the few who's had a contrary opinion.
That depends of course, on where one reads. There has been at least a dozen dozen negative responses linked to from http://www.thauvin.net/linkblog/ , which is not very surprising since it's quite Java-centric. However the some of the arguments are IMHO valid beyond just being defensive.
If it is ok, I'll link a couple of them (if not feel free to remove this):