Let's talk about "velocity", crunch, and old habits. There is a particular habit that inspires this note, which is a tendency to:

Sprint ahead as work begins. Use time to gather insights. Sometimes prototype solutions unprompted. Amass many questions related to unknown quantities - often referred to as "opens."

I've developed this habit by working in environments where planning, execution, and testing are all delegated to me as a "solo developer."

The term Technical Recon seems to fit best when describing this approach. In the past, this technique has helped me to build trust with non-technical stakeholders. I have also used it to encourage consideration of systems and edge-cases earlier. This has generally enhanced the fidelity of development estimates around effort.

And yet, Technical Recon can cause friction when applied out of habit. Particularly when the stakeholders for a project are technical experts themselves. You run the risk of shifting focus to non-issues which you may not comprehend. It can also be disruptive to production efforts.

Over the years, I've become more hesitant to apply Technical Recon during projects. My reasoning follows:

• It can be stressful. The phrase "save the gas for when you need it" seems pertinent. Pushing toward complexity is sometimes necessary, but not always. For example, Technical Recon can be very useful when estimating high risk implementations.
  
  

• It can derail personal focus and leave known quantities neglected. Over-application of Technical Recon has led to less-than-robust implementations of simpler systems. With attention spread too thin, more complex code becomes a "fan favorite". Known quantities become an afterthought. This is sometimes necessary - when timelines are hyper-aggressive - but it runs contrary to my love of robust software engineering.
  
  

• It can be disruptive to the greater team. Asking team leads increasingly obscure questions. Proposing esoteric problem solving during focused meetings with teammates. It feels more healthy - both socially and technically - to have a shared set of immediate problems to solve. An insular set of long-term "maybe problems" are less suited to team discussions.

The remedy for these types of issues - strangely enough, as I've found - is to do less and think less. Space can still be reserved for Technical Recon - even as projects are in mid-production - but they can become team efforts. Once complete, the focus can shift back to immediate problems.

Since recognizing the existence of this habit and making a more focused effort to relax into the process of engineering a project, I've discovered a healthier balance in my day-to-day work as a developer.

I highly recommend considering whether or not you are taking part in Technical Recon as a force of habit.

Perhaps you have a tendency towards habitual exploratory research as well? Is it perhaps a survival mechanism that developed as a result of wrestling with hidden complexities in the past? Or, maybe you are just drawn - like a moth to a flame - to the most complex aspects of a development project.

In any case, growing awareness around habits like these can be a wonderful way to unburden yourself and increase mental bandwidth.