Now other people hold hackers in high esteem. They are the demigods of the software world. Everyone should be more like them. If you can't think in cryptic code and obscure, complicated methods, you're just a lowly code monkey only ever to update the software that they wrote.
Well, like Ryan said, I'd rather be a great Software Engineer. I guess it's like in baseball I'd rather have a team of people who always go out and hit singles, than having a so-so team with one star player who hits home runs. I think that it's a better investment to teach people how to hit singles all the time rather than to point to the person hitting home runs and say "be like them!".
Maybe I'm just too new the the software world, I don't know. But the software world is pretty new itself. We'll see how it plays out, but I hope that the focus is about everyone being well trained and capable of producing stable, consistent sw that solves the customer's problem. Sure, the industry still have it's stars, but if you don't need to have a star to deliver a well made product, I'll be happy. We'll have the tools to be able to manage and monitor the work (not the people!) to ensure that we are doing what we should.
Listening to: Massive Attack - Risingson
When I first read Paul's essay I interpreted it to mean exactly what you said: that without this star person, the project would fail. That's probably what this star person thinks.
ReplyDeleteThe hackers that Paul talks about like sexy problems to work on. Projects as a whole aren't sexy, only the challenging parts of them are and they are a small percentage of the total work of the project.
It's true that the the project may hinge on the completion of these challenging problems, but without the rest of the project infrastructure the project is doomed to fail too.
Project managers appreciate this because they have to worry about the whole project, not just one challenging bit of code. PM's have to worry about the long term health of the project. After digesting Paul essay I realised he's advocating making "hackers" happy so that these challenging problems are solved smoothly.
True, it's about stroking egos ... but management is often about giving people what they want to get something you want in return. Real hackers don't want to be rich, they want to be renowned for their great hacks. So give them what they want while keeping them in control and you can have your cake and eat it too.
If the project fails because of a wayward hacker it's not the star hacker's fault (though he might complain that he was too tied down to "save the project"). It's the PM's fault that he couldn't channel the hacker's energy to benefit the project.
The hacker has to know what the PM's rules are, and the PM has to give the hacker enough freedom to do his thing. Ironically the PM can give people freedom through a good testing/metric/monitoring policy. If the PM knows when things break, he can slow people down and keep the project in control.
At first I thought Paul was saying "hackers rule", but really he's just trying to give the PHBs out there a window into the hacker's mind so they can channel their hackers' energy better. Hackers don't want to manage projects and people, they want to hack code. Hackers need projects just as much as PM's need them.