So I have been packing and preparing to move (which may be why I have been remiss in posting lately). This involves packing a lot of boxes, and then moving said boxes into moving trucks (or more accurately, in my case moving-truck-sized shipping containers sitting on my driveway). I spent a recent Saturday packing a shipping container, and during that time a lot of random thoughts came and went from my mind. One of the thoughts was particularly interesting.

At the start of the day, I had an empty container, and 50 packed and taped boxes, with the desired end goal of the 50 boxes moved from the garage where they were sitting into the container. As time went on, I found myself continuously trying to design queueing and sorting algorithms, and trying to devise optimal ways of moving multiple boxes using hand trucks and bungee cords. But at the end of the day, you know what I discovered? The simplest and most straightforward way was to just pick up a box, carry it into the container, set it down, and repeat until done.

As programmers and engineers, we love to problem solve. We love to come up with clever and innovative ways to do things. But sometimes, the reality is, there’s a simple and straightforward way to just get the task done. I remember one time, I was leading a software development team that was very innovative and forward-thinking. The entire unit testing and system testing process was automated in a CI pipeline, complete with dashboards and HTML-based output reports. But the legacy-minded configuration manager insisted on the test reports being delivered in a Microsoft Word template with a very specific cover page. The lead developer, getting visibly excited, started talking with me by the coffee machine one day about adding the Word output to the CI pipeline, automating the entire process. But after I asked a couple of questions, I discovered this was probably several developer-days’ worth of work. To be honest, the product was on a bi-weekly release schedule, it took me all of 5 minutes to copy/paste the HTML web page into the body of the Word document, and I knew the CM manager’s days were limited. It just didn’t make sense to spend time and money to automate it when I could just perform this simple brute-force task for 5 minutes twice a month.

We eventually (within a year) convinced the CM manager’s boss that an automated dashboard was a perfectly acceptable alternative to a Word document. In retrospect, I’m glad we did chose not to take that week to automate the Word report output.

As a leader or manager, keep this in mind. Sometimes trying to automate or optimize everything is not needed. Instead, make sure you’re thinking of the big picture…instead of automation is it a one-time task? Is it a task that can be completely refactored or even eliminated anyway? Finding these small ways to get back valuable developer time will help your team stay focused on tasks that provide true value.