"[T]here's something splendid waiting for you to go and find it, far out yonder. I wonder if I'd feel it now, or if it happens only when you're young, and have no thought for the ill things that may lie along the way."
Flashman, Flashman and the Redskins

This week's notes start last week, but Saturday was after my last post and it's appropriate this beings with an ending because that's where I want to begin. I was lucky to learn a Universal Truth in my first job. There was a woman who'd worked at Putnam for years when my class of newbies rolled in. As far as we could tell, she was one of the engines that made our department go: knew everything about her specialty, did a ton of work (at 34 instead of 22, I can tell you all she'd done is carve out a fiefdom by working on one thing and spending the rest of her time fighting to avoid the rest). She managed to miss a month of work with a back injury. Upon returning, someone had an uncomfortable conversation with her about how part timers didn't get sick time so they were going to have to take from her vacation time (leaving her with something like -97 hours to spend on beaches around the world). She walked out on the spot. Well, she made a scene and then walked out.

Shock. Desperation. Visions of insane workloads, late hours and less fun than we were already having danced in our heads. What we discovered instead: she talked a much better game than she played and her work was easy. In a couple of weeks, with no new hires, it was like she never existed. Since then I've always reminded myself no one is irreplaceable and no one is the keystone. When I left Putnam, I slunk out a couple of hours before quitting time just as the part-time ladies brought my cake in. Maybe a little cold, but they wanted the cake, not a goodbye and I've always been addicted to that feeling of freedom that only comes from leaving. Anything.

But all of that is a bit of a lie and I'm a lot of a hypocrite. Make no mistake, I am not a team leader. I'm too prickly and I can't modulate my expectations for people. Expecting less of others than I expect of myself feels like an insult. Completely unfair and maybe a little pathological, but there it is. I fancy myself more like a point man: you might not see much of me, we might not be best friends, but you're never going to get blown up on my watch. While I tell myself nobody makes a lasting impression unless they jump from a great heightr[1], I've always had it in the back of my head I lead by example, I leave places better off than I found them. Which is a damn fool illusion to walk around with. Because on Saturday I ran into some code from a place I used to work. And it took me a half hour to calm down enough to fix the worst of the mistakes in the code. You can see why I'm not a team leader. Calming down involved emailing a couple of former coworkers to grouse. We decided the secret ingredient when we were there were the small smattering of complete incompetents who made everyone work double-time because they knew they had to carry the load. In the hope of reducing the sum total of complete incompetents in the world (at least for the next 10 minutes), I'm going to talk about how not to write the code I came across. So if that sounds like nerdery, jump off now. It won't get any better in the next graf.

The first time you code something, it is the most rickety thing you'll ever come across. Various labels exist for this genus of code: "twine and baling wire", "duct tape", etc. You're basically speaking a foreign language and the fist time you get an acceptable response, you stop everything and call it done. The form submits and anything shows up in the database? Success! Don't anyone touch it. Assuming you're not completely put off by the process, at some point you realize your code can break. But even after cleaning up all the mistakes, there are still any number of ways a user can break the thing. Exceptions. So you write your first exception handler[2].

The first step to exception handling enlightenment (keeping in mind your narrator is an unreliable one) is to start using them. That's something. It shows a beginner's mind. It shows humbleness, a realization of the imperfection inherent in all works of man. But you've barely gotten anywhere, because all you do when you first start trapping exceptions is "Please catch anything that happens. Eat it, swallow it and pass it without ever making a sound. I don't want to know about what happens down in the guts of this program." Having a Beginner's Mind doesn't mean being ignorant. You need to know what's going on in there. Instead of saying, "This could blow up. I better set a trap here", you need to think of how it could blow up and trap that. Because if you don't know how it'll blow up, you don't know how you should be handling the exception. If the fire alarm in your house goes off, it could be that the batteries need changing. It could be dust got into the sensor. Or it could be your house is currently engulfed in flames. You don't want to handle all those cases the same way. Because there's only one way to handle those cases the same: run away screaming. It'll keep you alive, but it won't make for good code.

If all you're going to do is set up an anonymous try/ catch (i.e., one that traps every error), don't. You're better off without them. At least then when things go wrong your users find out and they can tell you. With anonymous try/ catches, no one knows what happened. Things just don't work. Ignorance is an enemy of good work in any field. Self-imposed ignorance . . . I don't even have a metaphor here. Don't do it. Here's another hint: the Warnings panel in your compiler? It contains warnings. Yes they are not errors. Yes you can ignore them. Yes there are a couple of things that it warns about that aren't necessarily so. But they're warnings for a reason and the compiler is smarter than you. So figure out what they mean. "I can always ignore 'Unreachable code detected' because someone told me to in this one specific case" isn't knowledge. It's faith. It's ignorance. Investigate everything, even when someone tells you to ignore it. Worst that happens is you learn something before you're done.

As pissed as that left me, it was nothing compared to dealing with one of my bigger clients this week. This big client has a big data team. The data team sends us big files full of chronological data. I got killed by QA this week for two major issues that revealed a troublesome problem: some of that chronological data ain't. When I pointed out their chronological data was sorted "alphabetically" by date (where dates run 3/2009, 3/2010, 6/2009) in one case (and apparently randomly in the other), this did not cause anyone to jump up and fix things. We're a small client for the data team. There are plenty of other clients they serve. The problem with that is no one could be relying on the current order of the data. It didn't exist. So, as is their wont, they paid me to work around it. Authorized a day's worth of work for me to deal with it instead of authorizing 15 minutes of work on the data team's side to fix the problem permanently across all existing and future projects that consume the data. Please don't sing me sad songs of how I don't understand big systems and all of the interactions and the need to QA and how many eyes have to look at the problem. Somewhere on some server there's a bit of code that pulls this data out without bothering to sort it like the rest of the data it pulls out. At the outside that's a 3 line fix. My 15 minute estimate gives you 10 to sit on the john.

1. Shamelessly stolen from The Old '97s

2. An aside here for the non-technical minded (though you were politely asked to leave): an exception handler is (wait for it) a way of handling an exception. But the important thing is what you consider an "exception". A good example of a handled exception is asking a user where to save a file and they provide a path that doesn't exist. The handler fires and gives you a chance to yell at the user rather than just crashing your program.