DCSIMG
The Good, the Bad and the "Bad Hair Day". - OneMustCode

The Good, the Bad and the "Bad Hair Day".

Published 03 November 06 09:07 AM | OneMustCode

So let's kick things off with some non-original content: Joel Spolsky from Joel On Software has written a nice piece about recruiting delevopers.

Now, I know I have a tendency to agree with him, but nonetheless - this article has nicly divided the deleveopers crowd in to four distinguishable groups by two parameters: Smartness and "Get Things Done"ness. Go read it.

I agrue that there's a another group: the lying basterds. They come in two varieties, the Highly Paid Consultant and the Brilliant Paula Bean. My beef is with them both and I can influance the hiring of none.

The consultants may often promise clients unimplementable stuff that we would later have to actualy implement, and when failing to do so (or do so promptly) will be the ones who have to provide answers (or be taken outside and shot). And yes, pre-sale is important; no, I don't think they should write all the application themselves; yes, some are WAY too smart for me to understand what they're talking about. Other times these HPCs just do a half ass work writing specs, and when the client is surprised by the end result - All I can say is that I was only following orders...

The "Paula Bean" kind is something that presents me with one of the biggest things I don't understand about the software industry: How the *** do these people manage to keep their jobs for more than a month at a time? I can guess we've all encountered a useless developer whose contribution to a project was null. Now, I can understand that the interaction between a team leader and the developer could "produce bad work" which results in... well, whatever. This is usually a one time thing and a brand new team lead will get better results from this programmer. But what about the inherently useless coders? When can we decide that a certain someone does more damage than good ("You ARE the weakest link, Goodbye!")? Why is it that usually after there's a consensus amongst the developers that this person is rubbish and should be let go, he is given a second chance by management? Joel has talked about the hardships in actually firing someone, but I think these reasons apply almost exclusively in the American scenario. Managers should be bolder in making these kind of personnel decision, in my mind.

 

Serenity Now!

Comments

No Comments

Leave a Comment

(required) 
(required) 
(optional)
(required) 

Enter the numbers above: