Technical Difficulties from on Top of the Mountain
  Do we really want these people in charge?
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? :-)"

Comments: Post a Comment

<< Home
Life in the middle of nowhere, remote programming to try and support it, startups, children, and some tinkering when I get a chance.

January 2004 / February 2004 / March 2004 / April 2004 / May 2004 / June 2004 / July 2004 / August 2004 / September 2004 / October 2004 / November 2004 / December 2004 / January 2005 / February 2005 / March 2005 / April 2005 / May 2005 / June 2005 / July 2005 / August 2005 / September 2005 / October 2005 / November 2005 / December 2005 / January 2006 / February 2006 / March 2006 / April 2006 / May 2006 / June 2006 / July 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / February 2007 / March 2007 / April 2007 / June 2007 / July 2007 / August 2007 / September 2007 / October 2007 / November 2007 / December 2007 / January 2008 / May 2008 / June 2008 / August 2008 / February 2009 / August 2009 / February 2010 / February 2011 / March 2011 / October 2011 / March 2012 / July 2013 / August 2013 / September 2013 / October 2013 / November 2013 / December 2013 / December 2014 / February 2015 / March 2015 / July 2016 / September 2016 / December 2016 / April 2017 / June 2017 / July 2018 /

Paul Graham's Essays
You may not want to write in Lisp, but his advise on software, life and business is always worth listening to.
How to save the world
Dave Pollard working on changing the world .. one partially baked idea at a time.
Eric Snowdeal IV - born 15 weeks too soon, now living a normal baby life.
Land and Hold Short
The life of a pilot.

The best of?
Jan '04
The second best villain of all times.

Feb '04
Oops I dropped by satellite.
New Jets create excitement in the air.
The audience is not listening.

Mar '04
Neat chemicals you don't want to mess with.
The Lack of Practise Effect

Apr '04
Scramjets take to the air
Doing dangerous things in the fire.
The Real Way to get a job

May '04
Checking out cool tools (with the kids)
A master geek (Ink Tank flashback)
How to play with your kids

Powered by Blogger