how to progress faster than everyone else (in tech, in 2026) transcript

Most people trying to break into tech in 2026 are going to spend the next 12 months making almost zero real progress. They'll watch hundreds of hours of tutorials. They'll start three different courses. They'll tell themselves they're learning. And a year from now, they'll be in the exact same spot they are today. Not because they're lazy, not because they're not smart enough, but because they fundamentally misunderstand what progress actually is.

I've helped over 50 people transition into tech careers in the last 2 years alone. And I can tell you the single biggest difference between the people who land six-figure roles at companies like Zillow, American Express, and NatWest and the people who are still stuck has nothing to do with talent or how many hours they study. It has everything to do with how they learn. Today, I'm going to give you the exact framework for making progress faster than 99% of people trying to break into tech.

This isn't some motivational fluff piece. This is the system, step-by-step, and if you actually apply it, you'll accomplish in 90 days what takes most people a year. Let's get into it. But before I give you the framework, you need to understand why I'm qualified to teach it. Eight years ago, I was a 30-year-old English teacher. Zero coding experience, zero connections in tech. I was the last person anyone would have bet on to become a developer.

I remember sitting at my desk, grading papers, looking at my paycheck, and thinking, "This is it. This is the ceiling." I didn't have a computer science degree. I didn't have a friend at Google who could refer me. I didn't have a clear plan. What I had was a growing sense that if I didn't make a change, I'd spend the rest of my career watching other people build the life I wanted. So, I started learning to code, and I did everything wrong.

I bounced between YouTube tutorials. I started four different courses and finished none of them. I built the same generic weather app and to-do lists that a thousand other beginners were building. Months passed. I had nothing to show for it. Here's the part most people don't talk about. I wasn't just wasting time. I was actively building bad habits. Passive learning, tutorial dependence, the illusion of progress without any real skill development.

My breakthrough came when I finally understood something critical. The speed of your progress is determined by the quality of your learning, not the quantity of hours. I stopped studying more and started studying differently. I found mentors who had actually walked the path. I focused on the skills that actually mattered to hiring managers, not the ones that feel productive. Within months, not years, I landed my first developer role.

I went on to become a senior developer, then a tech lead working at companies doing seven to eight figures in revenue, earning over $500,000 in total compensation. And now, I spent the last several years helping others do the same thing faster. The framework I'm about to share with you is the distilled version of everything I've learned from my own career, from mentoring dozens of successful career changers, and from studying the science of how people actually get good at things.

Here's the uncomfortable truth that most coding influencers won't tell you. The reason most people make slow progress has nothing to do with which programming language they choose or which tutorial they're following or whether they're using the right bootcamp. Those are surface-level decisions. The real reason is this. Most people are studying, but they're not actually learning. There's a massive difference. Studying is watching a 3-hour course and feeling productive.

Learning is struggling through a bug for 45 minutes and actually understanding why your code broke. Studying is following along with a tutorial, copying code line by line, getting a working app at the end, and thinking you built something. Learning is closing the tutorial, opening a blank editor, and trying to build it from memory, and realizing you can't. Studying feels comfortable. Learning feels uncomfortable. And that discomfort is exactly why most people avoid it.

Dr. Justin Sung, a learning science researcher, talks about this concept of higher-order learning versus lower-order learning. Lower-order learning is memorizing syntax, copying patterns, collecting information. It feels productive because you're busy, but it produces almost zero retention, zero transferable skill, and zero ability to solve real problems. Higher-order learning is the opposite. It's messy. It's frustrating.

It's the kind of learning where you're constantly asking yourself, "Why does this work? And how does this connect to what I already know?" It's slower in the moment, but it compounds exponentially over time. Think of it like compound interest. Lower-order learning gives you pennies today that evaporate tomorrow. Higher-order learning builds a foundation that makes everything you learn afterward easier and faster. This is the fundamental shift you need to make.

Stop optimizing for hours studied. Start optimizing for the quality of each hour. Now, let me show you exactly how to do that. I call this the compound progress framework. Five steps, each building on the last. If you follow this in order, you will move faster than almost everyone else trying to break into tech right now. Step one, solve, don't study. The first and most important shift is this. Stop consuming, start solving.

Most beginners spend 80% of their time watching content and 20% building. Flip that ratio. You should be spending 80% of your time wrestling with actual problems and only 20% consuming new information. Here's why this matters. Right now, in April 2026, the hiring landscape has fundamentally changed. AI tools like GitHub Copilot can write basic code faster than you ever will. Companies know this. When they hire a junior developer, they're not looking for someone who can write a for loop.

AI handles that. They're looking for someone who can think through problems, debug unexpected behavior, and make decisions about how systems should be designed. A recent survey of 400 engineering leaders found that AI increases developer productivity by an average of 34%. But this boost doesn't apply evenly. It widens the gap between strong and weak engineers. Strong engineers who know how to think are worth three times their compensation.

Weak engineers who just follow instructions, they're being replaced. So, here's what step one looks like in practice. Pick a real problem that matters to you. Not a weather app, not a to-do list, something connected to your life, your previous career, your hobbies, or your frustrations. Were you an insurance agent? Build a tool that automates the quoting process you hated doing manually. Were you a teacher? Build a platform that solves a real problem that you experienced in the classroom.

Were you in retail? Build an inventory tracking system that addresses pain points you personally witnessed. This does two things. First, it gives you domain knowledge that separates you from every other junior developer. Second, it forces you into problem-solving mode from day one because no tutorial is going to show you how to build your specific thing. When you hit a wall, and you will, that's not a sign you're failing.

That's where the real learning happens. Every wall you push through builds the problem-solving muscle that hiring managers are actually testing for. Step two, build the mental model, not the notes. Here's where most people go wrong with their learning process. They watch a tutorial on React, and they take notes. They highlight syntax. They bookmark documentation pages. They create color-coded Notion databases of everything they've learned.

Then they try to build something from scratch, and they can't do it. All these notes, useless in practice. This is because they built a collection of isolated facts instead of a connected mental model. Think of learning to code like learning to navigate a city. You can memorize every street name and intersection, but if someone drops you on a random corner, you're lost because you memorized labels, not relationships.

The person who actually knows the city, they understand that the river runs east-west and the neighborhoods stack north to south. They can navigate anywhere because they understand the structure, even if they don't remember every street name. That's what a mental model is. It's understanding how the pieces connect, not memorizing each piece in isolation. Here's how to build a mental model when learning to code. After you learn a new concept, close the tutorial and explain it out loud.

If you can't explain it simply, you don't understand it yet. When you learn something new, immediately connect it to something you already know. React components are like LEGO bricks. Each one is self-contained. You snap them together, and the combination creates something bigger. That analogy does more for your brain than memorizing the component life cycle API. And most importantly, test yourself constantly. After every learning session, open a blank file and try to recreate what you just learned without any reference.

The struggle of retrieval is where the neural connections actually form. This approach takes longer per concept, but here's the thing. You learn 20 concepts and actually retain all 20. The fast approach learns 50 concepts and retain three. The math is obvious once you see it. Step three, master what AI can't do. In 2026, if your entire skill set is writing code that works, you're competing directly with AI, and you're going to lose.

Here's what's actually happening in the job market right now. Software engineer jobs listings are up 11% year-over-year. AI-related job postings have grown 74%. Companies are expanding engineering headcounts, not shrinking them. But, and this is critical, they're not hiring people who can only write code. They're hiring people who can do things AI still can't. There are four specific skills that companies are desperate for.

These are the skills that separate candidates who get multiple offers from candidates who get ghosted. Focus on these deliberately. Skill one, system design thinking. This is the ability to architect a solution before writing a single line of code. How should the data flow? What happens when 10,000 users hit this at the same time? Where are the failure points? AI can write a function, it cannot design a system. This is constantly the number one skill gap hiring managers identify in junior candidates.

Start practicing this now, even at a basic level. Before you build any feature, sketch out the architecture on paper first. How do the components talk to each other? Where does the data live? What happens when something breaks? Skill two, debugging and root cause analysis. When something breaks in production, AI can suggest fixes, but it can't systematically isolate a problem. Understand why it happened and prevent it from happening again.

This requires human reasoning and context. Most people avoid debugging practice because it's frustrating. That's exactly why it's so valuable. Engineers who can calmly and methodically diagnose problems are worth their weight in gold. Practice this by intentionally breaking your own code and then fixing it without looking at what you changed. It sounds simple, but it builds a skill that most junior developers completely lack.

Skill three, technical communication. Can you explain your code to a non-technical product manager? Can you write a pull request description that another engineer can understand in 30 seconds? Can you walk through your technical decisions in an interview clearly and concisely? When new hires don't work out, study show it's because of soft skills, not technical ability, 89% of the time. Start practicing technical communication today.

Record yourself explaining your code. Write documentation for your projects as if someone else will maintain them. Skill four, business context awareness. For every feature you build, ask, "Why does this matter to the business? How does this create value for users? What's the cost of getting this wrong?" Engineers who understand business context don't just get hired, they get promoted. They become the person in the room who can bridge the gap between what the business needs and what the technology can deliver.

This is what product-minded engineer means, and it's one of the most sought-after profiles in 2026. Step four, use AI as your multiplier, not your crutch. Here's the nuance most people miss completely. The solution to AI isn't to ignore it, and it's not to depend on it. It's to use it strategically to multiply your own abilities. Companies are now asking candidates in interviews, "How do you use AI tools? When do you choose not to use them?

How do you validate AI-generated code?" The engineers who thrive are the ones who use AI to handle the boring parts, boilerplate code, writing tests, generating documentation. While they focus on the hard parts that AI can't do well, like designing the architecture, making product decisions, and debugging complex issues. Here's my rule. Use AI to go faster on things you already understand. Never use it to skip things you don't understand yet.

If you can write a for loop, but it's tedious, let Copilot complete it. If you don't understand how a for loop works, write 50 of them by hand until you do. The moment you use AI to bypass understanding, you're building your career on a foundation of sand. The first technical interview will expose it. The first real production bug will expose it. The first time you need to debug AI-generated code, and you will, it will expose it.

Be the developer who uses AI because they're strong, not the developer who uses AI because they're weak. Step five, compress your timeline with structure and accountability. Here's the final piece, and honestly, it's the one that makes the biggest difference. Everything I've described so far, solving real problems, building mental models, mastering AI-proof skills, using AI strategically, this is the what. But the what doesn't matter if you don't have the how and the when.

The number one reason career changers or CS students fail isn't lack of knowledge, it's the lack of structure. They don't know what to focus on this week versus next month. They don't know if they're making real progress or just spinning their wheels. They don't have anyone to tell them when they're wasting time on the wrong thing. And here's the hidden cost that nobody talks about. Every month you spend learning inefficiently isn't just a month of lost time, it's a month of lost income.

If a developer role pays 70k to 110k per year, every month of delay costs you $6,000 to $9,000 in potential earnings. Three months of unfocused learning, that's potentially 27 grand left on the table. This is why structured mentorship isn't an expense, it's the highest return investment you can make in your career transition. I'm not saying you can't do this alone. Some people can, but the data is clear. The people who have structured guidance, clear milestones, and someone who has already walked the path consistently get there faster.

It's the same reason elite athletes have coaches, not because they're weak, because they're serious about getting results as fast as possible. Let me bring this all together. If you want to make progress faster than everyone else trying to break into tech, here's the system. One, solve, don't study. Spend 80% of your time building and wrestling with real problems. Pick a project tied to your personal experience. Two, build mental models, not notes.

Connect concepts to each other. Test yourself constantly. If you can't explain it from memory, you don't know it yet. Three, master what AI can't do. System design, debugging, technical communication, business context. These are the skills that get you hired and keep you employed. Four, use AI as a multiplier, not a crutch. Automate the parts you already understand. Never skip the parts you don't. And five, compress your timeline with structure.

Get clear milestones, expert feedback, and accountability so you stop wasting months on the wrong things. This framework isn't theory, it's the exact system that my students use to go from zero to hired at companies that most people dream about. And speaking of that, if you're serious about making this transition, I want to tell you about something. Last year, 40 people went through my mentorship program and broke into tech.

This year, we've already helped a dozen more land roles. These are people who are exactly where you are right now, career changers with no coding background wondering if they could actually pull this off. They landed roles at companies like Zillow, American Express, and NatWest with salaries ranging from 70 to 110k a year. Not because they're geniuses, because they followed a proven system with real support, real accountability, and a mentor who has actually done what they're trying to do.

I'm not going to pressure you, but I will say this. The people who joined this program have one thing in common. They stopped telling themselves, "I'll figure it out later." and started taking action today. If that sounds like you, there's a link in the description. You can check out the details, see the results from real students, and decide if it's the right fit. And if you're not ready for that yet, that's totally fine.

Take this framework, apply it today, and start making real progress. But don't let this video be another thing you watched and forgot about. Pick one step from this framework and implement it before you go to bed tonight. If you found this valuable, leave a comment telling me which step hit hardest for you. And if you know someone who's been stuck in tutorial hell trying to break into tech, send them this video. It might be the thing that finally gets them moving.

I'll see you in the next one. And just remember, if I can do it, you can do it, too. Coding saves lives.