Today at work I gave a presentation to our division-wide systems engineering group at work about the why and how of automating some regular tasks that we do in our every day jobs. Over the past two years I had written some code (DXL, Python, VBA, etc.) to make some of the horribly boring and periodic work I do get itself done so I could work on other things I'd prefer to do. So many systems engineers turn into button-pushers and process jockeys. So many know the process but forgot all about the content. I don't want to be like that. Train some software to do the work, and you know the process and how to write software. Win-win.

It took a few years to learn how to code, and now I can use it. It was a painful—a terribly jarring experience for my ego. Kind of like getting out of shape physically. And like getting out of shape it's not hard to get back into shape. You just have to do it. Any idiot can do it—sometimes my life feels like an living testament to the ability of idiots to do things—but it takes time to do it. Unlike getting in shape, it's not clear where to get started. It's pretty clear how to run, but code? Where do you do that?

Anyway, the larger point is that it's not just that I don't want to be like a zombie, I don't want others to be like that either. At Big Corporation, when you start carrying that flag your life is a strange mix of being disliked by your manager (I got a below-average score on my performance evaluation for writing the automation code that saved the project and company money because it wasn't value-added to the project) and getting affirmative feedback from your peers (who know better than to rock the boat, but want the boat to be rocked a little).

I had some fun with the presentation. I can't post the whole thing here because it has some internal info, but I would like to share one slide that might be my masterpiece:

Look at that beautiful transition, from the depths of Lumbergh to the heights of what would you do if you had a million dollars.

And then there was this beautiful transition (you'll just have to imagine that the first three pictures were after a statement of the problem, and the fourth after the statement of the solution).

So it's a fine line between being clever and making a point. I've always tried, in these Big Corporate settings, to catch people a little off guard. There's a kind of protocol: stodgy, predictable, don't make me think too hard just give me some bullet points. Instead I'd like to kick in the door and let them know: there's a different way to do things. I'd like that to be my niche. I don't think one presentation establishes that, but I hope I planted a seed.