Friday, August 19, 2005

The truth about USELESS people? Hacker Attitude?

Paul Glen wrote The truth about "useless" people, which is very interesting. Paul Glen, as you might know is the author of the award-winning book "Leading Geeks: How to Manage and Lead People Who Deliver Technology" (Jossey Bass Pfeiffer, 2003) and Principal of C2 Consulting.
With all due respect to Paul, I'd like to add a little something about The truth about these "useless" people.
Paul clearly mentions more than one time, that these "useless" people are intelligent and talented! They are good at technical analysis, documentation and strategy, but unfortunately not at delivery!
Paul catagorizes these people under "people who are seemingly paralyzed by ambiguity and are incapable of moving forward until every possible question has been answered".
From my experience, I would like to induce another notion here and catagorize these people under "Hackers" (not "Crackers")!
Now before you start running about screaming, perhaps you should take a look at the Hacker FAQ which talks about managing Hackers. Also, check out How To Become A Hacker!
All those who are planning to sue me for trying to make hackers out of people, pls do read the above mentioned papers which are very possitive and helpfull in understanding people.
Note : I didn't say Hackers are useless, I am merely suggesting catagorizing those "useless" people Paul talks about under the category of "Hackers"!
Why do I catagorize those "useless" people under Hackers?
Consider this : These useless people are undoubtedly talented, but they are unable to deliver! Why? Perhaps because their energy is not focused to the right direction?
Most of the students who like programming want to start off as programmers. But for most of them, "too much" programming at some point becomes mundane! They are so good at programming by this stage that programming does not pose the same challenge to them as it used to in the begining. They need more! More challenge!Consider the Hacker Attitude mentioned in How To Become A Hacker :1. The world is full of fascinating problems waiting to be solved.2. No problem should ever have to be solved twice.3. Boredom and drudgery are evil.4. Freedom is good.5. Attitude is no substitute for competence.
Clearly the third point takes effect - Programming becomes 'Boredom' from 'Challenge'!
Similary consider EmployeeA engaged in a project yeilds excellent results in analysis and stratergy, but when he is required to do coding, his performance suddenly goes slump!
So what's the solution?
Enter 'Project Manager'!
Paul mentioned the importance of Project Managers and I totally agree.
As you can see in the above scenario, the Project Manger should be able to see this performance slump of EmployeeA and assign him something that he will focus on with enthusiasm thus, boosting his performance. After all, as most of you would agree, a good Project Manager manages people well!
I've been in a similar scenario in the begining of my career, the CTO is happy with my performance, all projects sped up, I introduced time saving methodologies and framework, now the whole company is settling down and just doin projects, so my next task? Programming! And there is comes, drudgery! My head started screaming "Lord, Save Me!". I even bought this upto the CTO, but the company at this point simply had nothing to be done, but programming for the numerous projects running simultaneously!What happened? I quit!It was an obvious choice, either I quit, or suffer the drudgery... 'Have Road, Will Travel'...
Another question raised would be "Who will do the programming then?". Well, there are always people around who love programming, if not there is Mr. Project Manager,to provide incentives and apply other stratergies to make people do programming productively! :)
Any comments appreciated...

Comments:
For me, one of the solutions I have found if for me to do a couple of
things.
1. Work on small "things" (components, utilities, etc.). This way I get
done quickly before I get bored with it, and move on to something else.
2. Change the type of work I am doing. If I have been doing components for
a while, then I change to doing UI stuff. If I am totally burnt out with
the project, I find a small single purpose utility that is interesting to
me, and then work on that. Also, I can work on adding "utility" functions
to my "common" assembly (saving data to a file, creating a UI for displaying
exceptions, etc.).

Finally, if I really need a break, then I search through the MSDN library
and find some cool looking library that I haven't used before, and that
might be useful in the current project or in the future, read up on it, and
then write a little "test" program using the features of that library.

EricB

Wm. Eric Brunsen
MCSE Windows NT & 2000, MCSD, MCDBA, NT-CIP, CTT, MCT-Retired
Computing Systems Engineer
Dynicity, LLC
 
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?

© Copyright 2005, Rohan Thomas
Disclaimer
This Blog contains findings that are self-explored and expressions that are self-evoked. They are by no meanss representions of my employer's view.