It‘s okay to be in awe of these great hackers. But as a practical matter, small ISVs would be much better off hiring professionals.
Eric Sink said this, and he's right. However, there are some comments I'd like to respond with to that, and they're a little bulkier than usual comments, and I can't find a place to add them on his site...
...and I can't just shut up...
...so, er, here we go.
We sell products to users. We have learned to value the needs of the users over our own preferences.
There's a certain amount of 'selling' done because of product features, and a certain amount of 'selling' done because you've got a slick marketing department/person/goat. Minimum features aside, the grand bulk of users have nothing but "other people are using it" to determine what they need.
The forces that shape what tools the users need are driven by these people Paul refers to, IMHO.
Here again, I am sympathetic. I like interesting stuff too. My To-Do list tells me that I am supposed to be working on some enhancements to our online store website. Frankly, that programming task doesn't interest me very much. I'll confess that I'm procrastinating on that particular task.
and then:
I worry that lots of small ISVs will read his article and believe that they need to hire great hackers. When great hackers are as fussy as Graham says they are, they're not worth the trouble.
Hold the phone -- someone who might comprise, say, 1/1000th of a customer base is worth having around even if they're fussy, but someone who can create 1/10th of the product those customers are buying isn't? This seems contradictory, somehow.
We sell products to users. Nothing here is more important than our users.
The users will want it as fast as possible, and you're going to want to produce it as quickly as possible. This can be facilitated with the people Paul speaks of.
I wish I could tell you that I'm advertising for myself, but I'm not. I'm just another guy who hopes he's Professional, and knows he is no Genius.
All the same, I don't just stand in awe of these people. They're more useful than I am, and I defer to their judgment in matters of technology. In matters of people, I'm willing to tolerate a little more crap, perhaps, but I don't feel that's anything to be proud of. I consider it a vice.
Profile
![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1)
chaoticset- chaoticset
Page Summary
- (Anonymous) : Our company hired a hacker [+1]
- b0rg : (no subject) [+1]
- (Anonymous) : v [+1]
- (Anonymous) : Thank You for site [+0]
Comments
Instead of interfacing our existing library, he rewrote it so that he can continue to develop in linux. He is very fast, but it is about 40 man-years that went into the library, and he'd have to code very very very fast to justify his higher productivity level. It's like saying, oh we'll just rewrite X-windows in Java. He's clever, but doomed to fail.
I think realism should prevail over zealotry.
I feel it is quite common for programmers to try to force their view on the world onto a project/customer although it isn't beneficial to do so from the customer point of view.
It is a good argument, but I usualy use "hit-by-the-bus" counter argument: what if your 1/10 of product person suddenly dissapears? I can tell you: your 1/10 of the code base becomes practically useless. Based on my experience - those people won't go extra length to produce readable code - the code that can be fixed, reused and taking further by other not-so-great team members, therefore in a "hit-by-the-bus" situation you're left with no choice but to hire another hacker. And the chances are your new hacker won't like code of your old hacker, so you're in a rewrite situation.
Having worked in a bunch of software shops producing not-so-complex commercial software with not-so-tight deadlines, I would easily trade that extra productivity of one person for maintainability of code base.
At the end I think it's a matter of personal preference - whether you choose to have a superstar programming diva in your team, or just a bunch of normal people who get along with each other very well :) I finally found the company where I have the latter and I'd stick with it :-)
The problem is the sifting.
A greater number of agents means a greater amount of chaff and not necessarily a greater amount of wheat. If you could modify wheat plants to only produce useful material at the cost of making them fragile enough so that they could only be grown/handled in a clean room, would that be worth it as an experiment?
Sure, from a metastrategy of Making Money, Honey, it falls flat. From the metastrategy of Let's Do Neat Stuff And See If We Can Sell It, it sounds more feasible.
I'm not suggesting that the most temperamental of coders has nothing to learn from making things easier; I'm suggesting that those people focused on code to the exclusion of social programming, which essentially (forgive the horrid metaphor) makes them a tool instead of a person. Sure, you can view them as a horribly destructive, destabilizing element -- or you can treat them like a piece of hardware. They'd probably prefer the latter anyway.
No, I don't know where I'm going with this.
I guess my point is that there are people who are harder to get along with than others, and they tend to have advanced skills in various things. If you want those skills, you can get them from those people. If you want people skills, you get people who have less of them, generally.
If you have to decide between hacking and sociability, the question isn't really Do I Want To Hire People I Get Along With?, it's really Is This Person In The Club Of The Sociable? and that really doesn't say anything specific about their skills...just whether you get along with them.
I hate the idea that I might not get a job just because the interviewer found me slightly annoying. I realize it happens, and I can even find good reasons -- but I still hate the idea.
.Good luck!
Good site ! ;)