Fog Creek Software
Discussion Board




Great Hacker != Great Hire

Eric's response to Paul Graham:
http://software.ericsink.com/entries/No_Great_Hackers.html

Btw, I'm still waiting for his article "supposedly" submitted to MSDN (few days ago).

Anon
Wednesday, August 04, 2004

Gads...

Eric says, Joel says, Paul says...

Bizarr-o.

What does hoser say?  That's what you really should be asking.

hoser
Wednesday, August 04, 2004

hoser, does this mean that you think you're bizarro-Joel?

Supe
Wednesday, August 04, 2004

I concurr.

I also drink Listerine.
Wednesday, August 04, 2004

the good thing being here is that i always thing that there are 3 forces in the it industry

1. m$
2. linux camp
3. joel-sink buddy party


Wednesday, August 04, 2004

hoser, what do _you_ say?

bpd
Wednesday, August 04, 2004

If I didn't have respect for my employees or the quality of their work, I wouldn't see the need to hire great (and expensive) hackers.

Derek
Wednesday, August 04, 2004

-urp-

Been on a bender.  Sobering up for the bike ride home.

Feel like blowing stuff up.

hoser
Wednesday, August 04, 2004

Ahhh Bizarro, my favourite Superman thread, everyone dressed like Superman and a complete klutz.  How like our own dear corporate life.

Simon Lucy
Wednesday, August 04, 2004

Additionally, Eric is more than right. 

Simon Lucy
Wednesday, August 04, 2004

To put it bluntly I thought Graham's article was crap, and insulting.  My feeling is he is completely out of touch with the reality of the software industry.

Again I am amazed at Eric's understanding of software as a business.  I thought this article was right on as usual. 

christopher (baus.net)
Wednesday, August 04, 2004


After many years in this business, I find that it is still somewhat rare to come across a developer that:

* Has a burning desire for technology. Eats it, loves it, lives it. Constantly improving their skillset.

* Understands that business is the driver; not technology. All the cool code in the world doesn't mean jack if it doesn't solve a business problem.

* Is able to communicate well and work with other people.

Mark Hoffman
Wednesday, August 04, 2004

Mark, where are you coming from?  Are you a developer or not?

Kalani
Wednesday, August 04, 2004

Mark,

What does having a burning desire for technology actually entail?

Ever since companies moved away from the closed world of the mainframe the problem has always been that is impossible for any business programmer to keep up with all the new and changing technologies and understand the business side of things too. Also, many companies fired all the techies who took the time to learn as much as they could about the company's business because management deemed these individuals as legacy programmers and believed it was too expensive to re-train them in newer technologies.

As for being a great writer and speaker, the suits are good at this because many of them don't have to keep cramming more and more complex information into their heads on a daily basis.


Thursday, August 05, 2004

Joel: Forget about the customer always being right.
( http://www.softwareceo.com/index_com_7.php )

Eric: Nothing here is more important than our users.
( http://software.ericsink.com/entries/No_Great_Hackers.html )

Paul: (paraphrase) Try to keep the users away from the great hackers.

I tend to lean more towards the Paul/Joel axis on this.  Sometimes the user is an idiot, and you have to decide whether you will pander to them, or whether you will do what they need, instead of what they want.  I also think it is a good idea to have a layer between your most productive programmers and the users. This serves not only to minimize interruptions, stupid questions, etc. which can wreck productivity, but it also acknowledges that there is a place for the person whose job is to translate business requirements into technical requirements.  This is a rare talent, in my experience, usually found in people with a little programming experience and a big love of business/strategy.

Matt Van Horn
Thursday, August 05, 2004

The two functions, nose down development and interfacing with the users are not incompatible within the same person but they tend to be  difficult to manage simultaneously.

Simon Lucy
Thursday, August 05, 2004

"Hire people who understand the difference between a job and a hobby."

Ok. But don't be surprised when they go home to spend time on their hobby. You can't have it all ways.


Thursday, August 05, 2004

Let me guess Matt, you are not technical. 

First of all I think it is silly to pretend that top software developers can not understand business.  Yes buisness is not development, but it is not somehow such an different realm that only MBAs can understand it. 
There are plenty of non-technical people that shouldn't interface with customers once in the requirements phase.  I have found the following to happen when non-technical people gather requirements:

1) They promise the impossible

2) They don't know when to lead customers away from solutions that are overly complicated.  Often they specify re-inventing the wheel.

3) The specification is ambiguous.  I've yet to meet a non-developer that really, really understands boolean logic like a developer.  They might exist, but they are extremely rare.  Almost always the developer, who must actually codify the logic, most go back and say "what about this case?" 

4) They are terrible at judging the scope and complexity of the problem, and promise customers deadlines that can't be met.

In my opinion, developers should be involved with the requirements, and any other process leads to a longer development cycle and a product that is less likely to meet the customers needs. 

christopher (baus.net)
Thursday, August 05, 2004

Re: Don't listen to the customers, vs The customer is the most important thing...

I don't see these as being at odds at all. Joel's point was just that customer input is one dimension of input when determining product direction. Eric's point was that a business is focused on its customers, both current and future. These are not polar opposites and both of them are true.

Re: Hackers vs developers

I side entirely with Eric on this. Hackers are more of a headache than they are worth. And lots of people who present themselves as hackers are simply mediocre programmers who can't/won't work with others...

Jeff Kotula
Thursday, August 05, 2004

O hear me messianic followers of Eric, Joel, and Paul:

The one true messiah is Tron (one of Dave Chappelle's comic sketch characters), and I should know who the real messiah is, since I've followed a few.

Python, Monty
Thursday, August 05, 2004

"Ever since companies moved away from the closed world of the mainframe the problem has always been that is impossible for any business programmer to keep up with all the new and changing technologies and understand the business side of things too."

Nobody said anything about keeping up with *all* the technology. You'd be a fool to be an expert in every technology, but most people already know that.
I'm talking about keeping up with your chosen niche. I'm a MS centric developer, so I spent a substantial amount of time in that arena, keeping up with the latest developments. Contrast that with the guy who learned VB 6.0 and Access 5 years ago and that is *still* all he knows.

"Also, many companies fired all the techies who took the time to learn as much as they could about the company's business because management deemed these individuals as legacy programmers and believed it was too expensive to re-train them in newer technologies."

Well, that's not a trend that I've seen. What I have seen is employees who refuse to invest their own time in learning new skills and demand that their employer train them. These employees frequently get the boot.

"As for being a great writer and speaker, the suits are good at this because many of them don't have to keep cramming more and more complex information into their heads on a daily basis. "

That's a pretty simplistic evaluation and ignores the countless technical speakers and writers who have mastered both communication and technical skills.

Mark Hoffman
Thursday, August 05, 2004

Chris -
Actually, I consider myself pretty technical, although I am not a great hacker by any stretch.

I never said that only MBAs can understand business, I never said technical people should meet customers. I did say that you should isolate you most productive programmers - those who can output large quantities of useful code - from outside distractions.

Also in my opinion anyone who makes a promise during requirements gathering is an idiot. You should be getting requirements, not offering solutions at that point. If the requirement sounds impossible, think about why it is a requirement, and see if either it is, in fact, possible - or what the real requirement actually is.

There is also a problem if your customers are suggesting solutions - that is what you are supposed to be doing. If you are suggesting overly complex solutions and your customers are liking it, then you both have a problem.

Third, the people that are good at digging out requirements are not always that good at writing specifications. Team them up with a developer if you like. Most developers I've met don't really like the task, but Joel's articles on the subject make a good case for why they should be interested in doing it.

Lastly, how could anyone judge scope and complexity in the requirements phase, and why in God's name would you be trying to establish a deadline before you have even defined the problem?

It sounds like you have a lot of experience working in some pretty screwed up places. (As we all have) There are companies out there that actually know what activities should happen, and at what point in the process.

I do agree that developers should be involved in every stage of the project - but usually the best developers are not the best people for dealing with the fuzzy, touchy-feely, customer intenaction stuff. Other developers, like myself, may not code as well, but we make up for it by having a better sense of what the customer actually needs.

I think this is relevant:

A novice programmer was once assigned to code a simple financial package.

The novice worked furiously for many days, but when his master reviewed his program, he discovered that it contained a screen editor, a set of generalized graphics routines, an artificial intelligence interface, but not the slightest mention of anything financial.

When the master asked about this, the novice became indignant. ``Don't be so impatient,'' he said, ``I'll put in the financial stuff eventually.''

From: http://www.canonical.org/~kragen/tao-of-programming.html

Matt Van Horn
Thursday, August 05, 2004

>> 3. joel-sink buddy party

I feel I am a force in the software industry.

Alex
Friday, August 06, 2004

Read all three of them; Joel, Eric and Paul.

1) Customer is always right vs. Customer is not.
2) The Boss/Manager is always right vs. Not.
3) The Coder is always right vs. Not.

In all the three statements above, I hold the LHS true, given that the Customer is always right about the Why and What, the Boss is always right about the Who, Where and When and the Coder is always right about the How. Of course, given a (negotiated) "how much".

Paul's article is totally focussed on the "How" of the end product. What tools, what language, what platform to use and how to mix 'n' match them to generate the required output.

Eric's rejoinder is focussed on the end product as required by the cutomer. The What. That is non-negotiable.

My understanding of Joel's remarks ("Forget about the customer always being right.") is that, "Do not fret over when and who and how that information is passed onto others. In fact, do not even worry about whether that information is passed on at all. You want bugs fixed and your product to be ready for shipping Tuesday month? Ok. Leave the implementation to us (our product).".

All three are right. No contradictions.

My 2 paise.

KayJay
Friday, August 06, 2004

*  Recent Topics

*  Fog Creek Home