Passive-Agressive Developer Personalities - which one are you?

If you don't follow Ted Zuiba's blog, I recommend you check it out.  I love his sardonic sense of humor.  He can be pretty brutal with this commentary.  But, really, that's what's great about it.  Also, he's got some pretty cogent advice.

As per usual, there's some interesting work afoot on the Agile Web Operations blog.  The latest is a great one on development team motivation.  Or rather, the supposition that development teams don't need motivation (they're already motivated when they come onboard, that's why they accepted the job offer).  We simply need to actively stop de-motivating them.  You might say this is just arguing semantics, but I think the difference in perspective is illuminating on many fronts.  At its heart is the notion of developer as thinking individual who takes an active interesting in learning new things and advancing their capabilities.  Developers who don't treat training as a 'let me just sit back and let the teacher wash this know-how over me' but rather 'this is a chance for me to learn - learning is the active verb here more so than teaching'.  I think you want to weed the passive 'teach-me' types out of the organization in favor of the 'let-me-get-in-there-and-learn' sort.

But that's just me.  If you disagree, perhaps we can start a developer exchange program.

Group Captain, please make me a drink of grain alcohol and rainwater - Gen. Jack D. Ripper

What really smokes my rhino these days are guys who should know better that keep insisting on adding more and more fine grained configuration to our provisioning and deployment processes - We need more moving parts! We need total control! We need a binary editor so we can change byte 935 from 0110 to 0111 within dickcheney-Version666.jar in test888 because it's Tuesday at noon and my aunt has bursitis in her shoulder!

Yes, and our people can handle this so well! God forbid we be allowed to create a small set of complete machine images with all apps, configs, data, everything - type install and *nothing more*. No 'runbook' or 'manifest' with a bazillion manual steps and two hail Marys. If anything needs to change, you change it in source control and create a new build (which kicks off your unit tests, deploys the image, and then kicks off the functional, integration, and performance/scalability tests). All without any more dumbitude than automation can have. Granted, automation can certainly have dumbitude if its creator has it, but those pesky automated unit tests will kick in and raise the dumbitude detector flags in the form of red bars and if they miss it, the integration tests catch it, and the functional tests after that. At least it gives us a fighting chance.

I'm not bitter - and it is Friday. Amen.