Try Your Process Before Tooling Your Process

I’ve known a lot of programmers who give a lot of concern to making the best product they can. They follow best practices, create amazing programs and demonstrate both quality and accuracy. It’s quite amazing. But when you look at their internal tooling, it’s garbage. What gives?

I think part of this comes from developer’s desire to script and programmatically handle processes that aren’t interesting. Or, perhaps it’s because those processes are annoying or are distracting from the true desire: to create something amazing. I think too many times programmers rush in to scripting and developing tools before they understand what the problem is.

Most developers don’t like developing software if it’s not thought out and there’s no clear goal. Why do you allow yourself to do this with your tooling, then?

The way around this is to examine, document, and be honest about the annoying process. Quantify it. How often does it happen, is it really that annoying, and do you always do the process the same way. Then, and only then, create tooling.

Said in another way: try your process before tooling your process.

Instead of experiencing a tiny bit of pain and then freaking out and building a dumpster-fire worth of scripting and tooling, experience the pain a bit longer. Experience the process and define your expectations - kind of like you’d want your projects given to you. Then, solve the problem after you’ve received enough information and done the process enough to be certain your solution works. Simple as that.