Brute force isn't grit. It's the bill for a plan you skipped.

Brute force isn't grit. It's the bill for a plan you skipped.

We've turned grinding into a personality trait. The all-nighter, the heroic debugging marathon, the Slack message at 1 a.m. that says "still on it, almost there." It photographs like dedication. Most of the time, it's a planning failure wearing a cape — and someone is paying the bill for it, usually the company, often the engineer's weekend.

I want to make this concrete, because "plan more, communicate better" is the kind of advice that's true and useless at the same time. So here's a real shape of it.

Three days against a locked door

An engineer I worked with lost three days to a pipeline that kept dying mid-run. Day one, he threw a bigger instance at it. Day two, he added retries, then a queue in front of it to smooth the load. Day three, he was tuning JVM memory flags at 11 p.m., exhausted, and — this is the part that matters — completely convinced he was close. Every hour of effort made him more certain the next hour would crack it.

The data was malformed upstream. One bad export from a source system, three days earlier. A single thirty-second question in Monday's standup — "hey, did anything change with the export job over the weekend?" — would have ended it before lunch on day one.

He didn't have an effort problem. He had the opposite. A mountain of effort, aimed with total commitment at a door that was never going to open by force. Because the door wasn't stuck. It was locked. And no amount of pushing opens a locked door — you have to stop, notice it's locked, and go find the key.

That's the whole job, the part that never makes it onto a résumé.

Why we do it anyway

Brute force feels productive in a way that thinking doesn't. When you're grinding, you can see the effort — commits, log lines, instances spun up. It looks like work and it feels like virtue. Stopping to think looks like nothing. Walking to someone's desk to ask a question feels like admitting you couldn't figure it out yourself.

So we optimize for the thing that looks like work instead of the thing that is the work. And the engineering culture cheers it on — we tell war stories about the heroic 3 a.m. fix and stay quiet about the thirty-second question that would have made the fix unnecessary.

Here's the reframe I'd burn into every junior engineer: the question you're avoiding because you'd rather just solve it yourself is usually the fastest path to the answer. Not the weak path. The fast one.

What "planning" actually means here

When I say planning, I don't mean a Gantt chart. I mean three small, unglamorous habits that prevent almost all of the heroic grinding:

→ Measure before you move. Before you optimize anything, find out where the time or the failure actually is. On the pipeline above, ten minutes of looking at which records were failing — instead of three days assuming it was a compute problem — would have pointed straight at the bad export. Profile first. Force later, if at all.

# The cheapest planning tool there is: look before you push.
# Instead of "the job is slow, make the cluster bigger," ask "slow WHERE?"
import time
for name, fn in [("extract", extract), ("transform", transform), ("load", load)]:
    t = time.perf_counter()
    fn()
    print(f"{name:<12} {time.perf_counter() - t:6.2f}s")

Three lines. They turn "the pipeline is slow" — an opinion — into "the transform is 90% of the runtime" — a fact you can act on. Most heroic optimization is solving a problem nobody confirmed existed.

→ State the assumption out loud before you build on it. "I'm assuming the upstream export hasn't changed." The second you say that to another human, half the time they go "...actually, it did." Assumptions die fast in conversation and live forever in your head.

→ Define done before you start. "This is working when the job completes under an hour with zero malformed records." Without that line, you don't know if you're three days from done or three minutes — so you grind, because grinding is what you do when you can't see the finish.

Communication isn't the soft part

This is the thing the bootcamps skip. We file communication under "soft skills," as if it sits next to the real engineering. On a hard problem, it is the engineering.

The thirty-second standup question wasn't a nicety. It was the single highest-leverage technical move available, and it was free. The engineer who asks "what am I missing here?" on day one looks slightly less impressive in the moment than the one who emerges triumphant on day three — and is worth ten times as much, because they shipped the same outcome and kept three days.

I teach this to MBA students who are mostly not engineers, and it lands the same way for all of them: the senior move was never pushing harder. Seniority isn't measured in how much force you can apply. It's measured in how quickly you can tell whether force is even the right tool — and how willing you are to stop and ask when it isn't.

Nobody remembers the all-nighter you didn't need to pull. They remember the thing shipped on time, by someone who looked at the door, saw the lock, and went and found the key.

When's the last time you ground for days on something a single question would have solved in a minute? Be honest about it — that memory is the most useful teacher you've got.

I'm Vinicius Fagundes — principal data engineer, independent, and an MBA lecturer in São Paulo. Seventeen years of fixing pipelines taught me that the slowest ones are usually a thinking problem before they're a compute problem. That work lives at vf-insights.com.