"I'm thinking of retiring/ from all my dirty deals/ see you in the next life/ wake me up for meals."--Warren Zevon "Mr. Bad Example"
On Friday, the head of my department has his last day. As he is one of the few remaining people who still comes into my office on occasion, I've taken notice. As one of the few remaining people in the company whose hire date precedes mine, it's gotten me thinking about retirement. If you trace lineage back to the original company, prior to acquisitions, I was hired when we were around 190 people in the company. We're somewhere around 6000 now, and I'm sure at the Christmas party this Thursday, we'll be counting heads. Who's left and who's leaving? It's given the past couple weeks as I pass by his cubicle a funereal vibe.
I had been trying to avoid this sentiment, I do adhere to the advice of Chuck Noll on the issue: "If you're thinking about retiring, you've already retired." This seems like a prototype version of "the game," but I'm forced to reject it, because it's been preying on my mind. A retirement is an ending, a deadline, a stop of something without picking it up later. And I'm apparently bad at that at large scale.
Last week's bit on e-tests kind of dragged another part of that up. I made that plan for a stretch goal because there were things that I use that keep my value to the organization. When I started out testing in the company, I could rely on my knowledge of the underlying physics the code was simulating. I could rely on my knowledge of how the code works, and my ability to sight read Fortran, C, and then Perl, javascript, and Python. I could rely on my knowledge of how test plans are constructed and managed that I acquired in the first few years, when I had to farm things out to our offices abroad. But increasingly the value added I bring to this job is not what I can do in the moment of exploration, but knowing what failed before and is likely to break the code now. In the parlance of last week, I can teach a new hire how to develop their mental hardware through these guides, but their mental software is only able to be installed through experience, and I can't teach that in any formal way.
Those are the things from before I can pass on to someone starting in the field. I can't teach someone the examples of all the defects I've found, or as I frequently call it "where the bodies are buried." That would take too long, and it's not like I have a perfect taxonomy of every piece of code's failings. But I can teach them how I found the bodies in the first place, and I can document the process of finding the bugs, and what isn't useful in finding the bugs, or helping someone fix the bugs. But the gap between what I can teach them to discover and what I can show them is annoying me. The showing part is not something that they can learn this from, the showing are the examples, but they are for special cases after the rules have been established. They're the long tail of examples which they may never need. Really, they're the pieces that aren't necessary to finish this project. And I have to accept that, that the best thing I can do with this guide is not finish it where I feel it's complete, but where I feel it's most useful to someone else, so someone else can take what I'm showing them and finish the future job.
The book is turning into that. I can't impart "the knowledge" to students, but I can show their coaches where "the knowledge" is, and how to extract it quickly. I actually am much closer to having a taxonomy of the knowledge you need for quiz bowl, but I don't have a way to make the process go any faster. I keep coming up with new examples or techniques, but I've got to rein myself in, and just get the useful parts in.
When I got sick, I didn't have the moment of crisis where I got to face the possibility of not finishing what I wanted to. Things moved too fast, and I was fixed before my survival really could be a question. I was 80%...90% back before I left the hospital. The recovery was long, but I didn't have any doubts about getting back on my feet. It was just a question of how fast and how soon, and whether I'd get absolutely everything back or just most of it. As a result, I didn't get this moment of contemplating what will happen after me, and whether I could deal with a ragged incomplete ending.
Turns out, I probably can't. So I'd better find a way to cut the final edge and stick the landing.
Now if you'll excuse me, I've got more process to document.