Programming Zombies Will Crush You

This post on the "Creating Passionate Users" blog really sums up what makes a Dead Programmer, well....dead!

http://headrush.typepad.com/creating_passionate_users/2006/10/knocking_the_ex.html

A colleague of mine once quipped, "Why is it that at some point in most people's career, they suddenly decide that they now know everything and don't have anything else to learn?". That is around the point that they are past the point of no return converging on the "micro-manage every detail" side of the "Zombie Function" graph.

So what happens to these poor middle managers? Is it the tribal "showing the size of one's beak"? Or is it a kind of post traumatic stress disorder, brought on by being way into the "anxiety zone" (I will post about the state of flow soon).

Odd that the very factors like creativity and free-thinking that can most stimulate success, are the ones most likely to be blocked by management at many companies.

So what can a poor, Dead Programmer do about it? Speaking truth to power is both difficult and dangerous. If you really think you are ready to take on a monoculture within your organization, you had better prepare. Once you finally get your chance to pitch them, you will only get one chance. Writing down your ideas well in advance of this can refine them down to the size of information packet that management will be able to digest.

Focusing on new solutions instead of dwelling on the mistakes of the past is also a good idea. This is particularly true when speaking to the individuals who got the company into whatever mess it is in, in the first place. Be very diplomatic, but still take a firm stand ("tough love"?), and keep it far, far away from anything that can be taken personally.

Lastly, keep in mind that only benefits that will really impact the business are important enough to risk the firestorm that sometimes arises when confronting a zombie organization. When I say impact the business, I mean either bring in major new sources of revenue, or dramatically reduce the cost per running tested feature.

Small incremental improvements to the organization are best implemented from the bottom up in a "stealth mode" project. More about that next time...