One of the things I’m working on for this site is a set of stories about projects I’ve done for work. It’s ironic, but the more experience I’ve gained, and the more valued I’ve become as an employee, the harder it is to sum that up on a resume. It’s not just X years of Java programming experience, my ability to do something; it’s the ability to figure out what needs doing in the first place, and sometimes more importantly, what doesn’t need to be done. It’s also the ability to actually get it done, to overcome not just technical problems but organizational ones as well. It’s not just about doing my job well, it’s about helping my teammates to do theirs better and work together more effectively. It’s some combination of experience and attitude that’s hard to quantify.
Of course, I can say all that, but I need to back it up with something. The software business is full of people spewing platitudes about “innovative and practical solutions to enhance organizational performance.” So I need to tell stories. I need to talk about the time I redesigned my company’s core product in a way that not only improved performance and added features, but also made it easier to train staff and to plan and manage projects. I need to talk about how a configuration tool grew into a mini-IDE, and the huge boost in productivity it provided. I need to talk about how a task automation tool brought a better understanding of best practices and made everyone’s jobs more interesting.
These all started out as stories for interviews. I was thinking about all this the last time I was job hunting, and quickly realized that I couldn’t just wing it. I’d start talking one of these experiences through in my head, and suddenly discover that half an hour had gone by, and I’d gone down some rabbit hole of detail and missed the main point of the story. So I started actually rehearsing and timing them.
At first, I’d just talk through the story, pacing back in forth in my living room, and see how long it took. I’d make notes of where I got hung up, what bits I could leave out, and gradually whittle it down to a reasonable size. I also had to tailor the stories to my audience. Mostly, I’d expect be interviewing with other programmers, but I need to be able to explain myself to managers. So I’d have a version of the story that focused on the things managers care about: My ability to self-manage, the project ROI; the less tangible organizational benefits, like taking little bits of knowledge that people have squirrelled away in their heads and turning it into policies and software.
Now if I’m actually going to get a chance to tell the stories, I need an elevator pitch for each of them, a thirty-second hook to draw people in, to make them want to give me those 5 or 15 minutes. That’s essentially what you got a few paragraphs back: one or two long-winded sentences.
Of course, I didn’t write any of this down at the time, and now I’m coming back to try to reconstruct it all. We’ll see how that goes. Here are the stories I have so far:
It’s worth mentioning that before I posted these stories, I ran them past the co-workers who were involved, to make sure I wasn’t mis-remembering anything or mis-representing myself. They were cool with it.