Are My Programmers Interested in the Job or the Work?
Some military historians have made the claim that Vietnam was lost in part because many commanders had become more concerned with the job and less concerned with the work. Those who are job-focused are essentially career focused, and their every move was calculated with a selfish thought towards “what’s in it for me?” Those who are work focused tend to be driven by the quality of the output of their labor.
Being career focused is a bad thing for your work–instead of spending time figuring out how to improve your product, you spend your time trying to hone your skills. Unfortunately, when you get too obsessed with honing your skills, you never actually apply them. It’s sort of like my basketball skills: I’m great shooting hoops in my driveway, but I never get my ass to the court to play in a real game. But I know I’m great because I’m so good in my driveway. But at gametime, I’m never there. So what’s the point? Entertainment, escape, delusion.
Some programmers in my group, when presented with a trivial requirement, whine incessantly about how much easier it should be to make the change. “Why can’t we just get a workflow system?” gripes one of them (answer: because they cost thousands of dollars, lock you into their storage database (or at least their schema model), require an additional administrator, and take large amounts of training. By the time all that’s taken care of, your customers have fired you). “That would break the gestalt of the system!” exclaims another (yes, things change–and that is why we have jobs).
Finally, I am able to break some of them down and get them to appreciate that the new feature is actually a great thing for the users. Then they start groaning about how much annoying typing they have to do, and start looking at languages like Groovy and Ruby (we’re a Java shop). Why, I ask them, are these other languages so nice? Their answer always seems to be “less typing”. This is a ridiculous reason to change languages.
Object oriented languages (or semi-object oriented languages, as the purists would have me call java) let you encapsulate things. So if you hate typing things like new BufferedReader(new FileReader(new File(foo))); to read a file (plus all the Exception handling), you can just make your own three-line class which isolates all of this for you. There you go–less typing, and it’s in the same language! Amazing.
Lately I have been spec-ing a new module which requires a decent number of if-then statements and compound predicates to figure out what to do. There are some if statements which have about a dozen predicates in them. It’s kind of ugly, sure, but it’s easily understood. “Ugh”, whines one of my developers, “why can’t we get a rules engine?” Apparently when you have conditional logic which has more than three predicates, you need to bring in a massive rules engine, so that instead of writing if statements, you can write Prolog. Prolog has its place, as do rules engines. But just because you have a few thousand lines of code with lots of if statements doesn’t mean that you need to bring in a whole new pile of technology. Actually, Prolog would be great, but some of the cracked-out rules engines that my guys and gals want to use encode your rules in…wait for it…XML. Ugh.
Finally, my developers have started whining about how un-sexy some of our older modules are. When raw APIs are first developed, the first thing you do is write a better version of the API–for example, JDBC. Or Servlets 1.0. So when these APIs come out, the first thing you do is make them a bit better. Five years pass, and version 2.0 of those APIs arrive, and they’re much better (and they might, if you’re lucky, look like your improved APIs from five years ago). Now your old code, based on the five-year-old improvement, looks lame, and people start to use this as an excuse. I, being the guy who knows this old code, end up pigeonholed. “Oh, that bug is in the old part of the system–only DingoZombie knows how to fix it.” I’m flattered and I appreciate the job security, but the truth is that the unsexy old code is dead-easy for anyone to understand. Any new hires who go into the old code to make improvements or bug fixes immediately get on my “to-promote” list–they’re the work-centric killer assets. Those who whine and claim that it’s too obtuse I figure are job-based dead weight.
