 | ||||
|
|
| Developer Hell Test
 Reposted by John, 13th November 2003 Fed up at work? Frustrated? Think you're in DilbertCo? You might be experiencing Developer Hell. We've developed a simple set of tests to quickly check your working conditions. All tests can be answered with a simple yes or no... 1. Do You Have An Open Plan Office? The book Peopleware investigated in detail the productivity of developers. This book was published in 1987 and is widely acknowledged as a classic. Basically, Peopleware puts forward strong evidence to demonstrate that your working environment has a significant impact upon your programming productivity. If you've ever been crowded into a open-plan office with a bunch of needy support staff, you'll be able to guess the result; questions and requests for help every twenty minutes. This, of course, is just fantastic for JohnnySupportBoy sitting next to you. Having a developer close at hand to remind him about how to ping a remote PC, which socket to plug the mouse into and how that pesky Excel calculates figures saves him absolutely heapsof time. Unfortunately, programming is a thinking task requiring extreme bouts of continuous concentration. Dozens of variables and routines get stashed into your short-term memory as you immerse yourself into a complicated program. Then, you're in the 'flow' - with your brain capable of figuring out the best way to screw up the code (just kidding). Seriously, though, this is the point at which you're capable of safely changing the code. Well, at least until JohnnySupportBoy pipes up with 'Was it F8 or F10 to boot up into safe mode?'... Being housed in an open-plan office leads to other interruptions as well; people having meetings 2 feet away from your desk, people having loud telephone conversations, etc. As a rough rule-of-thumb, any interruption could knock a developer out of the flow. Then they have to spend another fifteen minutes getting back into it - a complete waste of fifteen minutes for each and every interruption.
2. Are There Any Motivational Posters? When walking through the corridors within an office building, pay attention to the walls and noticeboards (this may be quite a novelty for you since most people tend to wander around with blinkers on, but it's worth taking a look). Check to see if there are any motivational posters or sales graphs. If you see any, run (preferably screaming) from the building as quickly as you can - it's a clear sign that employees are thought of as nothing more than numbers in the machine. A poster on the wall is no substitute for good management. Good companies simply don't put cheesy motivational posters up, because they motivate their workforce through effective management techniques. These motivational gimics provide no inspiration or guidance - in fact, they are often laughed at and parodied: http://www.despair.com/motivation.html
3. Are Your Computers Museum Pieces? What specifications of PCs does the company provide for the developers? Considering the relatively low costs of decent PCs these days, it is simply crazy to torture the programmers by giving them low-end PCs. I've had the misfortune to work on poor specification machines where the development environment has outgrown the power of the PC. It is extremely frustrating to sit around twiddling your thumbs while the PC creaks along slowly compiling your code, or the GUI appears to be drawing a pixel at a time. Even small delays in the development environment can be incredibly annoying. This area is a real morale killer. Developers tend to keep up-to-date with the latest PC specifications and will know when they have sub-standard, archaic equipment.
4. Is There An Abscence Of 'Classic' Computing Books? The type of books you see on developer's shelves (or on desks, under desks, etc - developers aren't the tidiest of creatures) can be very revealing about an organisation. For years, working within a VB-based environment, I used to look for the existance of this particular book as a clue to a developer's ability:
If a developer had this book, I was generally fairly sure they were better than average. If they'd never heard of it, I'd generally sneak away quietly and avoid them... Perhaps it was a bit unfair, but I found this technique to be surprisingly accurate. Those people who just tinkered with VB or never got very deep into it wouldn't go near such a book. Those who wanted to know how everything worked would chain a copy to their desk.  Over the years, though, I've changed this approach somewhat. As a rule, I generally recoil in horror whenever I see a '????? For Dummies' type of affair - especially if it is for the primary language used within a department. These books are okay for a quick introduction to a subject, but you have to wonder if there are no more in-depth books sitting next to them. I've been lucky enough to discover some more generic, less language-orientated books that have replaced Mr Appleman's API bible in my eyes. Here are some of the more enlightened books that you should look for:
If you see one, or all, of these superb volumes, then you can breathe a sigh of relief because you've probably found at least one decent developer, someone who has the capability of looking beyond just the syntax of a language, and can take on board the wider concepts involved in software development.
5. Is There A Clear Desk Policy? Advocated by an alarming number of organisations, this is one of those 'favourites' that simply makes no sense at all to me. You spend the majority of your waking hours sitting at a desk and you have to clear everything useful off it every single night? All those bits of paper with scribbles of algorithms and useful charts, the specification you're currently working on, the code printouts, the whole lot has to magically get stuffed into drawers every night? Erm...why? Is a balaclava-clad competitor going to break into the building during the early hours and be nuts enough to read through application-specific documentation that litters your desk? Is it so that the cleaners can wipe away your sandwich crumbs and spilt coffee? The truth is that you spend longer at your desk than any other activity apart from sleep. Why not decorate it as you wish? It's a clear sign of Developer Hell if this isn't allowed.
6. Are There Poor Performance Appraisals? Management knows it's important to communicate with the workforce. One convenient way to do this is through performance reviews. It's a way of enforcing regular meetings and discussions. Hey - they can even be scheduled into busy appointment schedules, and ticked off a little list after they're done. But just having performance reviews doesn't mean you have good management. It's like the Cargo Cult phenomenon in Pacific Islands after WWII - building a runway doesn't mean planes are going to start landing and bringing you supplies. Managers should regularly interact with their team, regardless of review processes. The best managers I've worked for never needed a review to know how everyone was doing. They were fully aware of what we were working on, how we were doing, what problems we'd experienced, and exactly what we needed to do our jobs. They could have made salary recommendations without any review sessions at all. So, if a good manager can make a salary recommendation without a review, what happens when a poor manager hosts a review? Unfortunately, it seems to be significantly related to perception and can be easily abused: • How hard have I seen you working? • What good results of yours have been called to my attention? • What have you screwed up that I've been told about? Performance reviews could be a great way to increase motivation but, sadly, they are often not backed-up by effective management practises and this can significantly decrease motivation.
Results Simply add up your Developer Hell points. If you have 3 or more...sorry, but you're definitely in Developer Hell! |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| [Home] [Products] [Downloads] [Support] [Articles] [About] support@wibbleware.com © Wibbleware 2003-2009 Privacy Policy [Java™ Trademark Disclaimer] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
