Thinking before doing

Most people don't plan. They just start.

"I'll figure it out as I go" is the default mode for nearly everyone, in nearly every field. It feels productive. It feels like progress. But it's usually just motion.

I used to work this way. Early in my career as a programmer, I'd dive headfirst into problems - writing code until something broke, then pivoting, patching, and repeating. Planning felt like a delay. The real work was doing.

It took years to realize what I was actually doing: making decisions I hadn't thought through, then paying the cost to undo them.

There's a practice in software called Test-Driven Development. The idea is simple: before you write any code, you write a test that defines what "working" looks like. Only then do you build. Most programmers skip it. It feels slow. But the ones who practice it understand something the rest miss.

TDD isn't just about testing. It's about thinking before doing. It's about planning.

Thinkin before doing (TBD) is a pattern I now see everywhere. Architects don't break ground before the blueprints are done. Novelists outline before they write prose. Bakers refine recipes before they enter the kitchen. Great salespeople rehearse before they pitch.

The best performers in any field front-load their thinking. The rest wing it and wonder why things fall apart.

This is where AI has changed how I work. It's the first tool that makes deliberate thinking practical - not as a solo exercise, but as a conversation. Before I start any meaningful work, I talk it through with an AI. I surface assumptions. I challenge my own approach. I document the reasoning before I commit to a direction.

At ZAR, I'm pushing this mindset across the company. Technical or not, the expectation is the same: think rigorously before execution begins. Surface the bad assumptions early. Challenge the approach. Capture the reasoning.

What makes this different from "just plan more" is that AI captures the session. The thinking becomes a record.

Historically, we could only audit the output - the code, the design, the document. The reasoning behind it lived in someone's head, or vanished entirely. Now, when someone asks "why did you build it this way?" the answer isn't a reconstruction from memory. It's a link to the conversation where the decision was made.

For the first time, the thought is as reviewable as the work.