I don't know if they actually teach "management" anywhere, but I've never worked for a manager that was professionally trained. Especially in Silicon Valley, the managers are just engineers who had the desire to herd others. Maybe its the lure of power, or maybe they weren't on top of their game technically, or maybe they were just in the wrong place at the wrong time. Whatever the case, now they're the manager, and things are definitely heading downhill.
While 1 in 10 managers realize they work for their staff, the others think they work for the executives and make the staff miserable. If the job was to shovel coal, they'd give us a bigger shovel -- forget the fact that they proved over 200 years ago that one is more productive with a smaller shovel. Of course they're not even thinking about getting us a steam shovel.
At Bethlehem Steel they tested two of the company's best coal shovelers to determine how much material they were able to move: the men moved about 20 tons of coal per day with scoops that weighed 38 pounds each. Reducing the scoop load to 34 pounds, the men were able to actually shovel more coal than before. By reducing the shovel load and tracking the results, the men were able to average shoveling 60 tons of coal per day with a 21.5-pound shovel scoop.Luckily I'm not in the coal or steel business. Unfortunately I'm in the software engineering business where we're repeating the same age old mistakes. Electronic Arts has been repeated hammered recently for instituting what is a common occurrence in the software industry: mandatory overtime. They're typical schedules start at 60 hours and go up from there, typically up-shifting to 87.5 hours for the last two months. The workers are miserable, the spouses are unhappy, but management keeps on planning new projects that way.
The experts keep doing studies showing that putting in overtime is counter-productive, and the software industry keeps doing it anyways. It's like they're not even paying attention. Even just one extra hour is a disaster, as the studies show that total output is 16-20% higher for a 40 hours a week vs a 45 hour week. There's some things I can still do after working 12 hours in a day, debugging is just mindless enough that I can follow the dots. But writing new code requires a fresh mind.
The long schedules are even worse when they impact the sleep schedule. Then your brain goes way downhill. The cool thing is, that like drinking, you have no idea what's wrong.
In our study, FDC [artillery Fire Direction Center - ER] teams from the 82nd Airborne division were tested during simulated continuous combat operations lasting 36 hours. Throughout the 36 hours, their ability to accurately derive range, bearing, elevation, and charge was unimpaired. However, after circa 24 hours they … no longer knew where they were relative to friendly and enemy units. They no longer knew what they were firing at. Early in the simulation, when we called for simulated fire on a hospital, etc., the team would check the situation map, appreciate the nature of the target, and refuse the request. Later on in the simulation … they would fire without hesitation regardless of the nature of the target.Sure I can write another line of:
edata_tlist<table>::ipointer istep(m_tables) ;
while (++ istep) { istep-> clear() ; }
but I'm sure not going to be thinking about the consequence of calling clear() at that point. And complex designs are all about consequences.
So what's the answer? Manage the manager is the best I can offer. Know your limitations and stick with them no matter what. Keep a notebook or file of links to reports like: Why Crunch Mode Doesn't Work: 6 Lessons. Don't write new code in the middle of the night (unless that's your most productive time, like it is for me). Find tasks to do that are important, but that don't disturb the code: debug, write unit tests, do code reviews, search for public libraries, file bug reports, automate repetitive tasks, clean-out your bookmarks (hehe).
Most importantly, have some backbone. The economy is coming back, jobs are starting to be there, most everyone has a black-eye from outsourcing overseas and has learned their lesson for the time being. If you're part of a project, and are already contributing, you have some leverage. Use it to stay sane.
Alaric Comments,
Regarding lame managers:"It's much the same over here in the UK. I'm the head of technology at a marketing firm (amongst other things...), and the main problem there is that I'm the most senior technical person, so I sometimes have marketing people handing 'specifications' to me with the expectation that I can implement them in the timescale they have given the client.
He. He. He.
Oddly, I find debugging is something I can only do with a clear head - perhaps because most of the bugs I have to invest much effort in fixing occur in highly multithreaded code? :-)"
