Why I write code at work

I quit coding at work for a while—couldn’t remember what the point of it was. I used to play around and make things in VBA or DXL or Python for both fun and utility. Mind you, I work in a job function that doesn’t require code. In fact, systems engineering, especially in a larger company, is a kind of untechnical position. It’s not an insult—it just that being an engineer isn’t required anymore. The engineers design and the systems engineers integrate.

No, it goes a little farther than that. Systems engineering isn’t just an untechnical position—one is unwelcome when one starts getting involved in technical work. And writing software tools on the side is doubly unwelcome because it’s not even a flight part. And it wasn’t just that I couldn’t remember the point of coding, it was that I had actually received negative marks on my 2017 performance evaluation for “doing non-value added work without managerial permission”. Never mind that it saved time and money.

A few weeks ago the same manager that screwed me on the performance evaluation asked me to come back to the old team and show him how the tool works. Imagine. Negative evaluation marks means a smaller raise and no chance at a promotion. Money out of my pocket. And then what does he want? To get the goods for cheap. Someone needs to study the opening scene of The Godfather.

Nope. No deal.

And then I hit a low spot on the road for a few weeks.

I’m in a better spot now. Better team, better management, etc. So why let it bother me? But it did. For a while. Then I opened my eyes and paid attention—why do [some work process] manually all the time? That’s stupid. Frustrating. There Has To Be A Better Way™. So I hunkered down and put together 1000+ lines of VBA to replace the frustration. (Not that more lines of code is better, just indicating there’s a lot going on.) I don’t have access to database servers, so I worked with loading/saving csv files. Used buttons to pull in info from other Excel worksheets. Allowed some weak form of configuration control by saving the csv files off to the side. &c.

VBA is a commodity, and my code looks like it was written by an enthusiastic 12 year old. But so what? It’s fun to create it. It produces better work, even when it isn’t appreciated. And the most important but least measurable reason: turning a manual process into code means no bullshit. There’s no papering over bits of the process that don’t work but can be handwaved through with a little human intervention. One must understand how the whole process works from tip to tail in order to code it. Understand that and then start improving it, pruning useless branches, fixing things that never worked anyway. Solve problems, build a library, solve more problems, build more libraries, etc.—it’s a ratchet.

Fix enough things and become a rarity in systems engineering: one who knows how things work. I’ve got my own problems, but that’s not one of them anymore.

“Almost nobody’s competent, Paul. It’s enough to make you cry to see how bad most people are at their jobs. If you can do a half-assed job of anything, you’re a one-eyed man in the kingdom of the blind.

—Kurt Vonnegut, “Chapter 22,” Player Piano, 1952.

When we get comfortable with procedures, we may stop trying to develop more skills. Why bother, if the procedures usually get the job done? The result may be an erosion of expertise in organizations that rely too heavily on procedures. That’s what the Accuweather executive was finding.

Research supports this idea of eroding expertise. A number of studies have shown that procedures help people handle typical tasks, but people do best in novel situations whey they understand the system they need to control. People taught to understand the system develop richer mental models than people taught to follow procedures.

—Gary Klein, “Procedural drift”, Streetlights and Shadows: Searching for the Keys to Adaptive Decision Making, 2009.

Leave a Reply

Your email address will not be published. Required fields are marked *