Stop following roadmaps. Start thinking in opportunities.
The developers who followed the checklist are now competing with AI. The ones who learned to think are using it.
🧠 Mindset Shifts · For developers rethinking how they grow This week’s challenge: separate what you learned from experience from what you learned from a checklist.
In 2005, becoming a developer was hard in ways that no longer exist, and easy in ways nobody remembers.
Hard because the resources weren’t there. Documentation was incomplete or outdated. There were no bootcamps, no polished YouTube channels walking you through every framework. Stack Overflow didn’t exist yet. If you got stuck, you read source code, asked on a mailing list, and waited. Learning was slow because the infrastructure for learning didn’t exist.
But it was easy too. The cognitive load was smaller. You didn’t need to learn twelve tools to get a job. The systems were simpler. The ecosystem was smaller. And most importantly, you had time. Time to absorb concepts gradually, build things, break them, understand why they broke. Time to develop intuition alongside knowledge.
Nobody called it a roadmap. You just built things and figured it out along the way.
Then the profession got popular.
The hype wave changed who enters and how
Software development became one of the most talked-about career paths in the world. High salaries, remote work, the promise of building the future. It attracted millions. And for good reason. The demand was real.
But decades of accumulated knowledge can’t be compressed into a twelve-week bootcamp. The field needed developers faster than the field could train them. So the market adapted. Bootcamps, tutorials, roadmaps, certifications. Structured paths that promised: follow this, and you’ll get there.
And people followed. They completed the React roadmap. Checked off the JavaScript fundamentals playlist. Finished the full-stack bootcamp. Got the certificate.
Then they showed up to work.
What the roadmaps didn’t teach
The last few teams I trained revealed a pattern I keep seeing. Developers who could build a feature from a tutorial but froze when the problem didn’t match one. Developers who couldn’t resolve a merge conflict in Git — not because it’s difficult, but because no tutorial had walked them through what to do when things go wrong.
The worst version of this: developers who introduced massive complexity into simple problems. Not because the problem demanded it, but because the only approach they knew was the one they’d learned from a tool or framework. They had the vocabulary but not the understanding. They could use the abstraction but had no idea what was happening underneath.
The system shaped them this way. It optimized for output over understanding. The roadmap said “learn Docker,” so they learned Docker. It didn’t say “understand why Docker exists and when you shouldn’t use it.” So they didn’t.
The industry tolerated this
For years, the gap didn’t matter much. Demand was so high that companies hired anyone who could ship code, regardless of how deep their understanding went. Junior developers with surface-level skills found jobs because the market couldn’t afford to be selective. The shortage was real, and the business needed bodies.
That era is ending.
Companies didn’t raise the bar. AI did.
AI fills the gap and exposes it
Here’s the uncomfortable truth: every skill gap that tutorials created, AI can now cover. Can’t write a Docker config from scratch? AI can. Don’t understand what a merge conflict actually means? AI resolves it. Need boilerplate code for a new feature? AI generates it in seconds.
The developers who were trained to follow instructions now compete directly with a tool that follows instructions better than any human.
But the developers who learned to think — to understand systems, to question decisions, to see the problem behind the ticket — those developers aren’t competing with AI at all. They’re using it.
That’s the divide. And it was always there. The roadmaps just masked it.
The gap between learning and knowing
I’m not against structured learning. I’m against the illusion that structured learning is enough.
A developer who learned React from a roadmap knows how to create components, manage state, and call APIs. A developer who understands frontend development knows when React is the wrong choice. They can look at a project and say: “This doesn’t need a framework. A few pages of HTML and vanilla JavaScript will ship in half the time and be easier to maintain.”
That second developer earned it through building, mistakes, and judgment about what works.
A roadmap gives you vocabulary. Experience gives you fluency.
And fluency is what lets you see opportunities.
Opportunities come from problems, not from plans
Every meaningful career move I’ve made started the same way: I noticed a problem that nobody was solving, and I put myself in a position to solve it.
The health tech company from Edition #1 — the one that grew from 500 to 80,000 users and got acquired — didn’t happen because I followed a career roadmap. It happened because I looked at a struggling app and asked a question nobody else was asking: “Why isn’t this business growing?”
The Slack agent from Edition #2 didn’t come from a learning path about AI tools. It came from a daily frustration — wasting thirty minutes on context retrieval that should take thirty seconds — and the realization that I could build something to fix it.
Roadmaps tell you to learn Kubernetes. Opportunities show you that your team wastes four hours a week on manual deployment and maybe you should fix that. Kubernetes might or might not be the answer.
The difference is direction. Roadmaps point you toward skills. Opportunities point you toward outcomes. The best developers I’ve worked with always started with the outcome and worked backward to whatever skills they needed. They were always looking at the landscape. The developers who followed roadmaps were always looking at the checklist.
The skill that matters most now
The developers who will thrive aren’t the ones with the longest list of completed courses. They’re the ones who can look at an unfamiliar situation and figure out what to do.
That’s not a skill you can put on a roadmap. It’s a skill you develop by building, failing, questioning, and paying attention. By treating every project as a chance to understand something deeper, not just to add a bullet point to your resume.
AI makes this more urgent, not less. When AI can follow any set of instructions, the person who decides which instructions to follow becomes the most valuable one in the room.
The roadmap told you to learn. The opportunity is asking you to think.
Try This
If you didn’t do the exercises from the previous editions, go back and do them. Edition #1 asked you to list the tasks you’d delegate to five clones of yourself. Edition #2 asked you to pick one and break it into judgment versus execution. It sounds simple. Don’t underestimate it. Learning how to think is different from learning execution steps. This sequence is building that muscle.
If you did them, you have a list and a breakdown. This week, pick one execution task from that map — the kind where your time goes but your judgment doesn’t — and ask yourself:
What would I need to learn to build a tool that handles this for me?
Don’t look for a course. Don’t search for a roadmap. Look at the problem. What does it actually require? Maybe it’s an API you’ve never used. Maybe it’s a way to connect two tools you already have. Maybe it’s something simpler than you think.
Now notice: whatever you need to learn, it didn’t come from a syllabus. It came from a real problem that’s costing you real time.
By the end of this exercise, you should have one sentence written down: “I’m going to build [tool/automation] that solves [problem], and I need to learn [specific thing] to do it.”
And the solution isn’t just learning. It’s an asset. A tool, a workflow, an automation that keeps working after you build it.
This is how builders scale. They compound assets. Every solved problem becomes something that keeps working for them. Every problem you solve for yourself becomes something that works for you tomorrow, and the next day, and the next. The developers who figure this out early won’t just be faster. They’ll be operating at a different scale entirely.
Edition #1 gave you the map. Edition #2 gave you the target. This week, you start building toward it.
The Deeper Cut
The irony of roadmaps is that the people who create them usually didn’t follow one. They built things, noticed patterns, and wrote down what they learned. Then they published it as a sequence. And the sequence became a shortcut that strips out the most important part: the messy process of figuring it out yourself.
I use a tool for this. I call it a process log: a structured way to capture what I’m building, what decisions I’m making, and what I’m learning along the way. Not a journal. Not a retrospective. A living document that turns every build into a thinking artifact.
It’s how I wrote this edition. It’s how I built the Slack agent from Edition #2. Every building block I create starts as a process log before it becomes anything else.
I’m sharing the process log template as an artifact for all subscribers. Process Log Pattern.
Use it this week when you start working on your Try This exercise. Write down what you’re building, what you decided, and what surprised you. That document becomes proof that you’re thinking, not just executing.
Paid subscribers get the artifacts that go deeper — the actual tools, the AI agents, the decision frameworks, and the building blocks behind every edition. The process log shows you how to think through a build. The paid artifacts give you a head start on what to build.