From Irritation to Tools

Pay attention to the small, recurring problems that take far too long for what they are.

Those minor frustrations are often excellent opportunities to build useful tools—and to develop the skills required for much larger projects.

One such tool I built was an oxygen calculator. It grew out of the frustration of waiting several hours after servicing an oxygen bottle before I could confidently identify a small leak. By applying the Ideal Gas Law and rearranging the equation for the measurements I had available, I was able to classify leaks of roughly 5–10 PSI per hour after only about an hour of testing.

Another tool was a geometry calculator that converted angular displacement into a linear measurement. In plain language, instead of trying to measure 15 degrees directly, I could measure 9.5 inches of travel and know that it represented the same angle. That is particularly useful when checking the travel of an aircraft rudder or another control surface.

I also built a terminal-based tool for troubleshooting a wire harness that I encountered regularly. The program accepted voltage and resistance readings from a particular connector, compared them with the expected values, and helped narrow down the likely fault. After using it repeatedly, I became much faster at diagnosing and repairing that issue.

Little Tools, Larger Problems

None of these tools was especially large or complicated. Each addressed a narrow problem that was frequent enough to be irritating and predictable enough to be automated.

But after several years of solving problems like these, I became much more comfortable taking on larger and more critical systems.

In recent years, I have written software to support workflow and inventory management, assist with shipping plans, keep online inventory current, and populate PDF forms with very little manual effort.

I did not begin by building complete operational systems. I began by noticing small irritations and asking whether there was a better way.

Each small tool taught me something: how to define a problem, identify the necessary inputs, test assumptions, handle edge cases, and build something dependable enough to use in the real world.

The problems gradually became larger, but the process remained much the same.

Notice the irritation. Understand the problem. Build the smallest useful solution. Then carry what you learned into the next one.