The month where nothing satisfying happened, and the lesson I almost missed
Teaching people how to think is the hardest thing I've done. Harder than the code. Harder than the architecture. Harder than anything technical.
🔧 Field Notes · 🧠Mindset Shifts · From the field, no filters
This week’s challenge: find one moment this week where you followed instructions without questioning whether the instructions were right. Write down what question you should have asked instead.
This edition was the hardest to write.
I sat down, opened the doc, and tried to write about what I got wrong this month. That was the plan: a Field Notes edition about mistakes, vulnerability, the things I learned by getting it wrong. Honest and raw.
The problem is that nothing broke this month. The month was slow and incremental, without a single clear failure I could point to or a story with a satisfying turning point. The kind of progress that doesn’t make for a good opening paragraph.
I nearly forced it. Manufactured drama. Turned small things into big lessons so the edition would have the shape readers expect: conflict, insight, resolution.
Then I realized the forced shape was itself the thing worth writing about. Because the pressure I felt, the urge to package a month of quiet, grinding work into something clean and teachable, is the same pressure I’ve been fighting in a different context all month.
The pressure to turn thinking into steps.
Two mentees, one pattern
I mentor several developers. Two of them taught me something important this month, the same lesson from completely different angles.
Miguel is entering the software development market. He’s early in the journey, building foundational skills, and I’m preparing him to work as a developer in the AI era. Not the era that’s coming. The one we’re already in.
Alexandre is an entrepreneur. Already running things, already dealing with real business pressure, trying to use AI to navigate situations that don’t have clean answers.
Different profiles, different goals, different stages. And both, in the same month, showed me the same thing: they wanted me to tell them exactly what to do.
Miguel’s version was subtle. I had a feeling he was expecting to practice the way every developer resource teaches: write code, solve coding challenges, follow a curriculum. He never said it directly, but the expectation was there, and it made sense, because that model is everywhere.
But that’s the model this whole newsletter argues against. So my job wasn’t to give him harder coding challenges. It was to create exercises where the code wasn’t the point, where he needed to think, question what the AI produced, identify what was missing, give context, connect documentation, push back. Exercises where the answer wasn’t in the syntax but in the judgment around it.
That took real energy to design. Any mentor can hand someone a list of coding challenges and move on. Building exercises that trained his mind instead of his muscle memory was a different kind of work
I found the way. It took more from me than I expected, but the exercises landed. Miguel started questioning AI output instead of accepting it. Started noticing gaps. That shift is worth more than a hundred solved algorithms.
Alexandre’s version was louder.
We entered into several deep discussions because I noticed a pattern: he was jumping steps. Consistently. He’d encounter a problem and reach for AI immediately, without sitting with the problem first. Without understanding it. Without refining what he was actually trying to solve.
The loop I kept pushing was: understand, question, refine, learn, then use AI. Build clarity before you build speed. Every time he skipped the understanding phase, the AI output looked useful but missed something fundamental, because he hadn’t given it (or himself) the context it needed.
He resisted this, and I needed real effort to understand why.
Why entrepreneurs skip the thinking
Alexandre wasn’t being lazy. He wasn’t ignoring the process because he didn’t care. He was ignoring it because of something deeper in how entrepreneurs operate.
I’ve worked with entrepreneurs before, across different industries and stages. There’s a pattern that shows up consistently: the idea is more motivating than the path. Entrepreneurs are energized by possibility. The vision of what could be, the optimism that this time it will work, the momentum of a new direction. That’s the fuel.
When you ask them to slow down, define the problem precisely, question their assumptions, refine their understanding before acting, that process feels like it’s killing the idea. The clarity they gain comes at the cost of the excitement that was driving them forward. And for someone like Alexandre, who has real financial pressure to accelerate, every hour spent on clarity feels like an hour not spent on results.
I get it. The pressure is real. But the Outcode Thinking program isn’t built for speed. Learning to think is a skill that takes time to absorb and develop. There are no shortcuts, because the shortcuts produce the exact problem the program is designed to solve: people who can follow instructions but can't figure out what to do when the instructions don't exist.
The conversation with Alexandre pushed me to articulate something I’d been feeling but hadn’t said clearly: the hardest part of this work is holding the line when the person you’re helping is uncomfortable. His discomfort wasn’t a sign that the process was wrong. It was a sign that the process was working, because it was forcing him into the part of thinking that he’d been skipping.
The tension that runs through everything
The thread connecting Miguel, Alexandre, and this edition is the same one that runs through the entire newsletter: the people who need to learn how to think are the same people who expect to be taught in steps.
This is the tension I underestimated when I started writing Outcode Thinking. Developer content has been tutorial-shaped for so long that the format itself carries expectations. A weekly newsletter from an experienced developer should give you frameworks, checklists, specific actions. Step one, step two, step three. Follow this and you’ll get there.
I feel that pull every week. The pressure to turn every edition into a tutorial. To give you five steps to evaluate AI output, three rules for better communication, a roadmap for career navigation. That format is comfortable. It’s familiar. It gets clicks and shares. And it completely misses the point, because the developers who follow those steps without understanding why they exist will be lost the moment they face a situation the steps don’t cover.
The irony is that this is exactly what I was fighting with Miguel and Alexandre. They wanted steps. I kept redirecting them toward thinking. And here I am, writing a newsletter, feeling the same pressure from the other side.
Every edition I’ve published has tried to balance this: enough structure that readers have something to apply, enough depth that the application requires their own judgment. Some editions landed that balance better than others. I’m still calibrating. This month made me realize that the calibration itself is the work, and there’s no final version where the tension disappears.
What the quiet month actually taught me
The month where nothing broke taught me more than a month full of dramatic failures would have. The lesson wasn’t in any single event. It was in the accumulation of small, difficult moments where the easy path was to give someone what they wanted instead of what they needed.
Every time Miguel wanted a coding exercise and I gave him a thinking exercise instead, I was choosing the harder thing. Every time Alexandre wanted to jump to AI and I pulled him back to the problem itself, I was choosing discomfort over speed. Every time I sat down to write this newsletter and resisted the urge to turn it into a listicle, I was making the same choice.
None of these moments felt like wins at the time. They felt like friction. The satisfying version of this month, the one where I could write a clean story about a mistake I made and a lesson I learned, didn’t happen. What happened instead was a month of holding positions that are easy to argue for in an essay and hard to hold in real life.
The developers who grow the most are the ones who can sit with the discomfort of not knowing what to do next and use that discomfort to think harder. I’ve written that sentence in different forms across five previous editions. This month, I had to practice it myself, not as a writer but as a mentor, over and over, with real people who were counting on me to help them.
The work of learning how to think is slow and uncomfortable and rarely produces a good story. That, maybe, is the most honest thing I’ve written in this newsletter so far.
Try This
The exercises from previous editions built external artifacts: a delegation map, a judgment breakdown, a learning target, a decision analysis, an evaluation document. This week, the exercise turns inward.
Think about the last time someone asked you for help. A colleague, a friend, someone you mentor. Think about what they asked for and what you gave them. Were those the same thing?
If you gave them exactly what they asked for, the answer, the solution, the step-by-step, ask yourself whether that was the right call. Sometimes it is. Sometimes people just need an answer. But sometimes the request for steps is a signal that the person hasn’t thought enough about the problem yet, and the most helpful thing you can do is redirect them toward the question they should be asking.
Write down one instance where you gave someone the answer when you should have helped them find it. And one instance where you held back the answer and helped them think instead. The comparison between those two moments will tell you something about your own defaults, whether you lean toward giving steps or building judgment.
If you’ve been collecting the artifacts from previous editions, this one connects directly to Edition #4 (the skills that don’t expire). The ability to teach thinking instead of giving answers is a skill that compounds, and it starts with noticing when you’re defaulting to the easier path.
The Deeper Cut
The moment I understood Alexandre’s resistance, something clicked about a broader pattern. The people who push back hardest against learning to think are often the ones who have the most to gain from it, because their instinct to move fast is strong, and the discipline to slow down and understand first would give them a leverage most of their competitors will never develop.
The entrepreneurs who learn to think before they act don’t move slower. They move fewer times in the wrong direction. And in a world where AI can execute faster than anyone, the quality of the thinking before the execution is the only real advantage left.
Paid subscribers get the mentoring reflection template: a format for reviewing your own teaching and mentoring interactions, designed to surface moments where you gave steps instead of building thinking. It’s the same practice I’m building into my own mentoring process after this month.