Archive for April, 2010

Any Interest in the 700-page Abridged Version?


Me: We've still got the frying pan to clean.
Michelle: I always forget that.
Me: I know, it's on my list of complaints about you.
Michelle (unimpressed): Really?
Me: See chapter 3, "Domestic Disappointments".


Week 133

"[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.


True Love: A Play in One Act


A nice April night, game is in the middle innings, Kevin Youkilis coming up to bat.

Michelle: After this at bat, I'm going to the bathroom, no matter what Youk does.
Me: What if he cries out your name?
Michelle (pensively): I'm still going to the bathroom


Week 132

"Well, the Devil made me do it the first time/ Second time I done it on my own."
Billy Joe Shaver, "Black Rose"

Never got around to the last couple of weekly updates. There wasn't much of interest, technology-wise, and they burned the hell out of me. It's twice as fun to be burnt-out busy when they paychecks are weeks or months away. Every 4-6 months I go through a transition period where one or two big projects is winding up and new work is starting to trickle in (including a Django project for Frontline). The trick is dealing with the maintenance work and one-off edits for clients during this period. I'm really struggling with the continuous stream of interruptions. When I started on my own I was mad to reply to everything as fast as humanly possible and get the work done in much the same time. Not a great idea. While I've gotten better about resource planning, I still can't shake the feeling I need to reply rightawayohquicknow or lose a client. I know none of my clients stick with me because I can turn around an email quickly. Anyone could do that. I know it's for the quality of my work and I know I have credit in the bank with (most of) them, but I still drive myself nuts.

Email's the problem right now. It's always the first tab in my browser and then I have a Gmail plugin/ setting that updates the tab with an inbox count, in the interests of further self-abuse. When I worked for someone else and email became a problem, I'd just shut it off. Someone wanted me, they could call. And if that got to be a problem, I set the phone to make-busy. Not the thing that sends 'em straight to voicemail (I probably checked my voicemail less than 20 times in 8 years-- never occurred to me), the thing that dumped the call. Walk over if things are that bad. But now that I'm my own boss, I can't do it. I need to find some way to shut off email without obsessing over it. Still working on that. It's not an original observation (I think it's the theme song of the freelancer), but I want to make more days lie Saturday. Michelle works on Saturday morning, so my work week is from late morning Monday (theoretically— it's been more like early morning Monday recently) through 1pm on Saturday. And it feels like 50% of the work I do gets done in the quiet of Saturday when no one expects a response out of me (and don't start emailing me now). All I need is two of me: one to do the communicating and one of me to do the work and keep them away from each other before they go out drinking and get in a fight.

On a different subject, it's always interesting to be on the other side of the fence like I am right now on a project for Big Financial Institution. We've done a lot of work to paper over some of the cracks in their data team's process, but we're running into Newton's Fourth Law: "For every effort you make to hide the incompetence of someone you depend on, they will redouble their effort." This is a Big Company. I'm not mentioning it to impress anyone. I'm mentioning it because I can't imagine working for their data team and sleeping more than an hour a night. We've been (theoretically, mind you) getting the same thing delivered quarterly for almost a year now. Counting all the test runs, we've probably had a dozen data drops from them. And it's painfully clear this stuff is not delivered by script. It's 12 XML files with the same data fields every time for the same funds. Is it scripted? Hell no. Best I can tell, there's a guy with a button somewhere. And best I can tell, he was dropped on his head as a child. Maybe that's what makes me decent at my job, because I always hear Jim Clancy in my head: "There's a difference between a job done and a job done right." At some point, stay late. Whether they pay you for it or try to kick you out for being there late, stay and figure out all the questions in the process, find the correct answers one time and then make a damn computer do it. Because then you'll never have to look up the answers again, which means you won't have a chance to mess it up. And if you tell me there are too many moving parts to script the process, that just means you don't understand the process. Break it down into a bunch of steps, write some God-awful-looking code that works and be done with it. No one's ever going to see it, they're just going to be happy with you. And if they fire you because you made yourself redundant, good. I guess some people can work at a job where everyone agrees not to work too hard, but that's a Devil's Bargain: you grow fat and lazy and dull and then the only jobs you can work are ones just like it. And they don't hire much. Because people don't leave and because the company isn't growing.

It pains me some people are (theoretically) in the same industry as me but have no curiosity about it. True anywhere, I just happen to see it here. Which is why when people ask what I do, I tell them I'm a valet at the drive-in.