Saturday, October 31, 2009

Advice for new programmers: The art of "change management"

(In case that it's not immediately obvious a couple seconds from now, there's a whole lot o' sarcasm going down here.)

  1. First and most importantly, make sure you're the programmer who complains most loudly about the existing system being a "waste of time," with the "proof" being your passive-aggressive, obstructionist "use" of it.
  2. While you're at it, also make sure that, were it a contest, you'd be voted "Programmer Least Likely to Comment Her/His Code."
  3. After considering exactly zero input from your co-workers, find a tool on the internet that seems to best suit your notion of "How things should be done around here."
  4. Install it on the local network.
  5. For pete's sake, don't actually test it!
  6. Create user accounts for everyone.
  7. Set the software to spam everyone every time you do something that "involves" their account.
  8. With neither heads-up nor--perish the thought!--documentation, launch the software in prime-time.
  9. Sit back and watch your co-workers drop everything to help your project succeed.

(Okay, seriously now.) The takeaway for both programmers and non-programmers: It's not the technology that matters, it's the underlying real-world relationships modeled by the technology in question. If you've spent years blowing off those relationships...well...don't be surprised if the Field of Dreams premise doesn't quite work out.