← Blog
How You Do Anything Is How You Do Everything

How You Do Anything Is How You Do Everything

careergolfengineeringopinion

I heard this phrase years ago and dismissed it as motivational poster nonsense. Then I started playing golf seriously, and it hit different.

Golf has this thing called a pre-shot routine. Before every single shot. driver, iron, putt, doesn’t matter. you run the same sequence. Stand behind the ball. Pick your target. Visualize the shot. Address the ball. One practice swing. Set up. Go.

Every shot. Every time. Whether you’re on the first tee feeling fresh or grinding through the back nine after three straight bogeys.

The routine isn’t about the mechanics of the swing. It’s about creating the conditions for the mechanics to work. It’s a reset button. A way to approach every shot with the same level of intention, regardless of what just happened or what’s coming next.

The best golfers in the world all have one. And they never skip it.

The Routine Is the Point

Here’s what non-golfers don’t understand: the pre-shot routine isn’t preparation for the shot. The pre-shot routine is the shot. Everything that matters happens before the club moves.

When you watch a tour pro, the swing takes about 1.5 seconds. The routine takes 30-45 seconds. That’s not wasted time. that’s where the work happens. Target selection. Commitment. Visualization. Alignment. By the time they swing, the decision-making is done. The swing is just execution.

Skip the routine and you’re guessing. You’re standing over the ball thinking about three different targets, second-guessing your club selection, worrying about the water on the left. The swing falls apart not because your mechanics broke down, but because your process did.

I see this in engineering constantly.

The Engineering Pre-Shot Routine

Every good engineer I’ve worked with has a routine for how they approach work. It’s not always conscious, but it’s there:

Before writing code:

  • Read the ticket. Actually read it. the acceptance criteria, the context, the edge cases mentioned in the comments.
  • Look at the surrounding code. Understand the patterns already in use. Don’t invent a new one because you didn’t look.
  • Think about what could go wrong. Not every edge case. just the obvious ones. The null input. The empty list. The concurrent request.
  • Write the test first, or at least know what you’d test.

Before deploying:

  • Read the diff. All of it. Not just the files you changed. the generated files, the config changes, the migration.
  • Check the environment. Is anything else deploying? Are there dependent services?
  • Know your rollback plan. If this goes sideways, what do you do? If you don’t know, you’re not ready.

Before sending the PR:

  • Review your own code like someone else wrote it. You’ll catch half the issues before anyone else sees them.
  • Write a description that respects the reviewer’s time. What changed, why, and what to look at.

None of this is revolutionary. It’s all obvious. And yet. how often do you skip it? How often do you push code without reading the diff? Deploy without checking what else is in flight? Open a PR with “fixes bug” as the description?

That’s the equivalent of walking up to the ball and swinging without a target.

Consistency Beats Intensity

In golf, the difference between a 10 handicap and a scratch player isn’t the quality of their best shots. It’s the quality of their worst ones. The scratch player doesn’t hit it 50 yards farther. they just don’t hit it 50 yards sideways. Their misses are smaller because their process is tighter.

Same in engineering. The difference between a good team and a great team isn’t the brilliance of their architecture. It’s the consistency of their fundamentals. Tests get written. PRs get reviewed. Deploys follow the process. Every time, not just when someone’s watching.

I’ve seen teams with incredible senior engineers who still ship buggy code because their process is inconsistent. And I’ve seen teams of mid-level engineers who ship bulletproof software because they do the boring stuff right, every single time.

The routine creates consistency. Consistency creates quality. Quality creates trust.

When the Routine Breaks Down

Every golfer has had this moment: you’re two under through twelve holes, playing the best round of your life, and suddenly you start thinking about the score. You start protecting instead of playing. Your routine gets rushed. or worse, you add steps. An extra practice swing. One more look at the target. You’re trying harder, which means you’re doing more, which means you’ve abandoned the process that got you here.

In engineering, this looks like crunch time. A deadline is looming, so you skip tests. You deploy without review. You merge without reading the diff because “it’s a small change.” The pressure makes you cut the routine, and cutting the routine is exactly what creates the problems that add more pressure.

The whole point of a routine is that you don’t abandon it when things get hard. That’s when you need it most.

The Small Stuff Is the Big Stuff

“How you do anything is how you do everything” isn’t about being a perfectionist. It’s about recognizing that quality is a habit, not an event.

The engineer who writes clean commit messages also writes clean code. The one who names variables well also designs APIs well. The one who takes time to write a good PR description also takes time to think through edge cases. These aren’t separate skills. they’re the same muscle.

And the reverse is true. The engineer who says “I’ll clean it up later” never does. The one who skips the test “just this once” skips it next time too. The one who doesn’t read the ticket carefully writes code that doesn’t match what was asked for.

Your habits compound. The small decisions you make fifty times a day. whether to read the diff, whether to write the test, whether to take ten seconds to pick a good variable name. those are the decisions that define the quality of your work. Not the big architectural choices you make once a quarter.

The Carry-Over

What I love about the pre-shot routine is that it works everywhere. Once you internalize “approach this with intention and consistency,” it bleeds into everything.

How I review a PR is the same as how I read a green. Slow down. Look at it from multiple angles. Commit to a read. Execute.

How I plan a project is the same as how I plan a round. Assess the conditions. Know where the trouble is. Have a strategy, but stay flexible.

How I handle a production incident is the same as how I handle a bad hole. Don’t compound the mistake. Reset. Run the routine. Hit the next shot.

The specifics change. The discipline doesn’t.

Next time you’re about to push code, deploy a service, or open a PR. pause. Run your routine. Check the diff. Think about what could go wrong. Approach it with the same intention whether it’s a one-line fix or a major feature.

How you do anything is how you do everything. Make the routine automatic, and the results take care of themselves.