After you work in IT organizations enough, eventually you build up a list of things you would really like to never see again. Sadly they never seem to go out of style.
CIO/CTO's who ignore everything said by people who work for them but believe every word from a vendor's mouth. This always leads to large dollar purchases of technology and contractors that cause no end of trouble for everyone. It's how a million dollars of Documentum winds up being used to manage one website.
CIO/CTO's who make decisions based on what makes them look good to higher management, and ignore everything else.
Working for companies that make money despite utter incompetence and gross mismanagement. The only reason they stay in business is monopoly positions or long existing contracts that actually require little effort to collect on. Working for such a company is stable but frustrating beyond belief. Management acts as if all decisions involve life and death, but in reality the company would make money even if no one ever showed up for work.
Project Managers who claim they need to know nothing of the technology being used, as "they just manage people"; yet they wind up making serious technology decisions anyway. One PM I knew forced a developer who had just written a complex SQL query but hadn't even run it once to include it in a hot fix build of a customer facing web app. Fortunately a smoke test by another developer caught the sql query (which didn't work at all) before it appeared on the front page of an app used by 150,000 customers.
Project Managers with no actually technology background. At one place we had two fun ones, their previous work experience was as a forest ranger and a maitre'd. Yet the worst PM there had a PhD and was a former customer of the company. Go figure.
Developers turned managers who spent their developer careers complaining about how management acted; then upon becoming manager immediately did everything they used to rail about.
Developers turned managers who decide upon conversion that they never need to know or learn anything new and operate as if the world had stopped when they stopped developing.
Managers of any kind with no background in technology much less programming. I worked a contract for a University where the software development manager's prior job had been cashier. The manager had resisted for 3 months allowing the developers to start using a source code repository.
Working for IT organizations where following the "process" (always a waterfall or some renamed variation like SDLC) was more important than actually producing anything. One place had a system which required 15 separate documents, meetings and signoff's before any coding was done (after which the process stopped). I should write a whole post on this topic alone. Usually in such organizations nothing was ever completed; I always thought of the process as "How to fall off a cliff and die".
Working with really smart and talented programmers who, due to the inept, stupid, moronic management or environment had to either go insane, quit, or resign themselves to not caring at all and churn out crap for a paycheck. Some people naturally can empty their brain and put up with stuff, but some can't (and I am a poster child for having to care about what I do).
Working with programmers who call themselves a "java god" but never produce anything, or if they somehow do, produce utter garbage. It's even worse when they get called "architects" and have ordinary programmers have to clean up after them (see #10) while they get the glory.
Working in IT organzations where security is either Job #0 or Job #infinity. Some places it's both; one place had policies for encrypting everything, hard drives, flash drives, pda email, etc but left the production passwards to servers and databases available for everyone in the company to use without auditing.
Working with people who control every aspect of a developers job making it a royal nightware. One place had a guy who was allowed to force everyone in the company to use his Eclipse setup, complete with 150 plugins with everything locked down (even the source code formatting was his). No testing was allowed and no complaints tolerated despite constant changes every day. Most programmers tried to ignore him but eventually you couldn't get away with it as all the checks would be applied in continuous builds and it would fail if even the tiniest difference was detected.
Going though enormous hoops to get a job, requiring proof of god-like experience; then upon working you discover that your experience is ignored as every aspect of your job is predetermined and controlled. So why not hire monkeys instead?
I could go one forever but for now this will have to do. It's not hard to imagine that every developer has a list.
GTAStud.com 10/07/2008 11:58
I can easily how you can go on forever. And its sad that this is too well know. Just look at books like Peopleware or Rapid Development. It's all too common, simple to solve, yet rarely happens. You gotta love it!
Geoff 10/08/2008 08:58
Excellent blog...sounds way to familiar.
Bill Dwyson 10/08/2008 09:36
Developers who believe that everyone above them is an ignorant idiot, yet the company (that pays them) does well.
Developers who think decisions are based upon what people think, not the best interest of the company.
Developers who think they would be better managers or project managers but who fail impressively when they try because they believe that their technical skills are all that is necessary.
Developers who think project managers need to understand every last detail of their technology, not thinking that this would generally mean knowing at least ten times as much as them for large projects.
Developers who see their team mates promoted and, when said team mates are good at management, complain that they are now just "another one of them"
Developers who think that managers should understand their skills, not realising that there is no reason to understand every detail of the technical skills as long as their developers (and other skilled workers) are of sufficient quality and have communication skills.
Developers who think architects are like managers, with less skills than them, even though the two skill sets are not remotely the same.
Working with developers who are technical prima donnas who think management should leave them alone with their god-like coding skills, even though they are slow to produce or produce low quality products.
Developers who are so caught up in their given skill set that they believe other "monkey-work" is beneath them.
AND THE LAST ONE.
Developers who haven't the imagination to see a problem from more than one angle.
Bill Dwyson 10/08/2008 09:36
Sorry, can't resist.
Developers whose blogs convert apostrophes to ' in comments...
Shafqat Ahmed 10/08/2008 11:59
Hey, Is this Bill Dwyson guy one of those Idiots you worked with? Sounds like one and seems rally pissed.
I have been working for 10+ years and I agree with in some parts but there are sometimes reasons why managers do that they do. But you can always get Idiot managers like who have never been in development before, or control freaks who is not qualified to control.
Rahul 10/08/2008 17:53
You forgot the recruiters and HR. Nothing sucks as much as them.
Chekke 10/08/2008 19:08
To be Employee, it SUCKS ass in all the fields not just IT. The new Term Employee == Slave.
Dave Schinkel 10/09/2008 22:00
hehe, I love this one. I've seen this one all too much in IT:
"CIO/CTO's who ignore everything said by people who work for them but believe every word from a vendor's mouth. This always leads to large dollar purchases of technology and contractors that cause no end of trouble for everyone. It's how a million dollars of Documentum winds up being used to manage one website."
Bill 10/10/2008 08:45
In the title, "Off" should be "Of".
Dan Creswell 10/12/2008 01:23
I've seen both sides of this coin (the original posting and Bill Dwyson's response) - each is true.
One of the toughest challenges I've found doing technical management is knowing when to roll up my sleeves and get in front of the keyboard with developers and when to leave them to it. There are always other things than code to worry about and sometimes the code is the only thing to worry about.
Sometimes a developer must learn the hard way, sometimes it's better to lead by example. Sometimes you might be able to solve the problem faster than your developers but you must leave them to learn for themselves and take the hit (which can mean facing off with the rest of management whilst the job seemingly takes forever).
At the end of the day there's rarely a developer or a manager who is perfect - each must work with the other to overcome their collective faults.
not a monkey 10/14/2008 16:00
re: "So why not hire monkeys instead?"
actually, that's been the trend in IT for the last 7 years
Ken 10/14/2008 20:45
This all reminds me of a joke:
Joe: “I never make any friends, because I always smell really bad”
Pete “Why do you smell so bad?”
Joe: “Because of my job, I work in the circus, I follow the elephants around, any time they take a cr-p, I have to clean it up.”
Pete: “Why not switch jobs, get out of the circus, do something else?”
Joe: “WHAT! and give up a career in show business!”
Radu Popa 10/15/2008 09:01
For me the worst kind are developers turned managers and the organizations that foster them. The so called "on job trained" managers. If you seen it happened you know what I mean: after some time in the company, the best (hopefully) developer in a team is made manager. Just like that. No special training, no special skills. Just seniority and good evaluation grades. From employee p.o.v: once of a sudden he needs to prove himself in a completely new role, with a different skills set without any proper preaparation, education or qualification. From company p.o.v.: take the best in what he is doing and make him do something completely different. Anybody wonders he will suck at it?! When a company hires a programmer he goes through interview hell, technical and otherwise. After a while he is just moved to a completely different job.
Ryan 11/02/2008 15:17
14 keeps kicking me. It's easy to mistakenly think that because the bar is so high to get into a place that they must be doing interesting things. I mean, wow, they want me to write a compiler to get in!
Second day on the job and you realize your life is dedicated to managing xml build scripts.