I usually try not to write about work in this blog as part of my effort to keep a reasonable separation between my home life and work. I guess it’s also an attempt to reduce the effects of work on the rest of my life. But I’m going to make an exception now and again and today happens to be one of those.
It’s extremely, extremely, extremely frustrating when you’re trying to build world class software and there’re folks around you that just don’t get it. Having worked for about 11 years now, I’m convinced that there’re some folks, often in world-class companies who are plain foolish. They won’t listen to good suggestions / direction if it means they have to do more work; unless such a suggestion comes from their manager, since he’s the one that affects their review scores / bonuses / promotions, etc and it’s no longer a suggestion – it’s an instruction. In the software development world (not IT), it’s not the manager who typically provides such feedback; it’s the peers and more experienced developers in the team with whom one doesn’t have a reporting relationship. When peers encounter this behavior more than a couple of times (yeah, free passes for the first couple), the person gets tagged as a bozo. Jim McCarthy has written an excellent book “Dynamics of Software Development” and it touches on this precise topic. Once tagged as a bozo, it’s pretty much the end of the line for the person in that team – it’s very unlikely that folks will respond to any changes in behavior after the bozo gets on their shit list. Best bet for the bozo is to move somewhere else and try to effect a change in attitude.
I encountered such a bozo today at work. Until this day, I wasn’t quite ready to flip the bozo bit – had come close a couple of times, but not quite. Why is it not so bloody obvious that it’s hard for people to respect you when it’s clearly evident that you’re making a poor design decision to avoid work that needs to be done? Hiding behind the “I’m not sure that there’s all that much value in doing that since that same info can be found by doing a bit more grunt work later.” argument only makes you look even more LAME. Listen up! Scaffolding is VERY, VERY critical. It’s NOT an afterthought. Read “Code Complete” by Steve McConnell if you don’t understand what I’m talking about. When you have a couple of hundred servers logging to a single source, filtering out and figuring out what went wrong is a not a simple task despite having sophisticated tools – especially when you can easily get that information by looking for a precise entry in the logs. Internet scale, always-up systems are hard to build and maintain even with all the monitoring subsystems in place. No point making it harder in those situations and increasing down time of such systems coz you’re feeling lazy to write a few (and I really mean a few) extra lines of code; this just makes you one of those people that should be working in some backwaters IT department, not in a top notch software company.
The bozo bit’s been flipped. ‘nuf said.