The reason you're grinding every night

after work and still can't land a tech

job isn't because you're not working

hard enough. It's because you're working

on too many things. You're putting in

the hours, but they're pointed in the

wrong direction. When I was trying to

break into tech, I was doing everything.

I was watching tutorials at 6:00 a.m. I

was building random projects at

midnight. I was jumping between

languages every other week, and I could

not get hired. And it wasn't until I

learned how to channel my effort into

one thing that everything changed. In

this video, I'll show you why you feel

so busy, why this is actually the thing

keeping you unemployable, and most

importantly, how to point all of that

effort at the one vehicle that will

actually get you hired. But first, quick

context so you know I'm not just some

guy talking. I was a 30-year-old English

teacher, no CS degree, no tech

background. I didn't know what an API

was. I didn't know what the terminal

was. I remember staring at a JavaScript

function for the first time thinking,

"This might as well be hieroglyphics."

And today, I'm a senior developer,

former tech lead at companies doing

seven to eight figures in revenue. I've

helped over 50 people break into tech

through my mentorship program, with a

dozen more already this year landing

roles at companies like Zillow, American

Express, and NatWest. Salaries ranging

from 70k to 110k a year. And the thing

that got every single one of them there

was not grinding more hours. It was

learning how to set the right goal at

the right time. So, let me show you how.

Picture a garden hose with no nozzle on

the end. You turn on the tap and the

water just kind of pours out. It

dribbles. It barely reaches anything. It

flops onto the ground 2 ft in front of

you. Now, take your thumb and press it

over the opening. Same hose, same water,

same pressure from the tap. But now, the

water shoots across the entire yard.

Nothing about the supply changed. You

just forced it through a smaller

opening. That's your effort right now.

You have a fixed amount of time and

energy and brain power. That's your

water pressure. And right now, you're

letting it dribble out across five or

six different things. You're learning

JavaScript and Python and React and

trying to understand Docker and watching

system design videos and doing LeetCode

and thinking about starting a blog. It's

just water hitting the ground. But if

you put your thumb over the hose, if you

forced all of that same pressure through

one opening, you'd be shocked how far it

reaches.

You only have a certain number of hours

in the day, a certain amount of focus, a

limited amount of energy, but you're

splitting it across four or five

different directions, four different

technologies, four different study

tracks, four different half-finished

projects, and wondering why nothing

gains traction. And here's why this

happens. Because you got into tech by

quitting something and changing

directions. Maybe your old career was

teaching or retail or finance, and one

day you said, "I'm done with this. I'm

going to learn to code." And it felt

amazing. You felt momentum. You felt

possibility. So now, your brain has this

pattern, change equals progress. And you

start doing it again and again,

switching to a new language, starting a

new course, trying a new framework.

Rather than realizing that the original

leap, going from your old career into

tech, that was about picking a better

vehicle. It wasn't about constantly

starting over. It was about choosing one

direction and going all in. Now, here's

a word people throw around a lot in this

space, strategy. People love saying, "I

need a learning strategy." And I always

want to ask them, "What do you actually

mean by that?" And they just string

together a bunch of words because they

don't really know. Here's what strategy

actually is. Choosing where to point

your limited resources when your options

are basically infinite. It's deciding

what you're going to do and what you're

going to deliberately ignore. That's the

whole game. So right now, if I asked

you, "What are your priorities?" And you

said, "Well, first is learning React,

second is learning Python, third is

getting AWS certified, fourth is

building a portfolio." I already know

you're in trouble because you don't

actually have a priority.

You have a wish list.

Now, let me explain why this isn't just

making you feel busy. It's actively

keeping you from getting hired. You have

to understand the real cost of

switching. Let me draw this out for you.

Let's say this line represents your

current skill level, your current

trajectory toward being hireable. If you

make a change, switch languages, switch

frameworks, start over with a new

course, you're almost always going to

pay a tax. Your progress is going to

dip. In my experience, every time you

switch, you lose roughly 20% of your

forward momentum immediately, before you

even get to see whether the new

direction was worth it. Now, a lot of

you hear this and think, "Yeah, but I'm

willing to eat that 20% loss because

maybe the new thing will be better."

Okay, but think about that math. You're

accepting a guaranteed setback for a

possible improvement that may never

arrive. I don't like those odds. Here's

what it actually looks like in practice.

There's two scenarios. Scenario one,

you're learning React. You start to get

momentum. Things are clicking. You can

build components, manage state, handle

routing. But then, right around month

three, you see a video that says React

is dead. Learn Svelte or Vue is the

future or Next.js or nothing. So, you

switch. Now, you pay the switching tax.

You're back to basics. You're watching

beginner tutorials again. And just when

you start getting traction with the new

thing, someone tells you something else

is hot. And you switch again. And your

actual progress stays flat or worse, it

dips. Even though every individual

switch could have been an improvement,

you're permanently stuck in transition.

Scenario two. Some of the changes you

make actually set you back. You spend

two months learning a framework that

turns out to have no job market demand.

Or you go deep on a back-end language

when the jobs in your city are all

front-end. Now, you've lost time and

direction. And this is exactly what I

see when people have been learning to

code for two years and still can't get

hired. It's not because coding is too

hard. It's because they keep changing

course. They're spreading themselves

across too many directions at once. They

never build enough depth in one area to

actually break through. I see this with

all my mentees all the time. I had

someone come to me, smart guy,

motivated, working a full-time job,

studying on the side. He was learning

React, but he was also dabbling in

Python, watching machine learning

videos, trying to learn Docker, and

considering a cloud certificate. He was

putting in serious hours, but when I

looked at his situation, I just thought,

"Man, you're watering four different

gardens with one cup of water. What if

you poured it all into one? What if you

just went all in on React and full-stack

JavaScript and built three killer

projects? The growth would compound so

much faster. And that's why it feels so

hard right now, when you're spreading

thin across multiple tracks. It's all

manual effort. It's all brute force just

to get through the basics of each one.

But when you go deep in one thing, at a

certain point, the compounding kicks in.

You start to develop real fluency. You

start to see patterns. You start to

build faster. You start to develop a

reputation if you're building in public.

But when you split your attention four

ways, you never reach that inflection

point. Now, here's the part that really

hit me hard when I learned it. The thing

you love doing, the thing you're

comfortable with, might not be the thing

that's actually limiting your progress.

I had a mentee who loved solving coding

puzzles. She was addicted to LeetCode.

She'd solved 300-plus problems, and she

couldn't get a job because LeetCode

wasn't her constraint. Her problem was

that she had zero portfolio projects,

zero deployed applications, zero proof

that she could actually build software

in a professional context. She was

obsessing over the part of the funnel

she enjoyed, problem-solving, while

completely neglecting the part that was

actually blocking her, proof of work.

When I told her this, I could see her

energy deflate because she was like,

"I'm not good at design. I don't know

how to deploy things. I don't like

writing README files." And I was like,

"Yeah, it shows." Here's the thing, you

can only score so high on LeetCode.

There's a ceiling, and you're never

going to hit it. So, the problem isn't

perfecting the thing you're already

decent at. The problem is getting more

people, more recruiters, more hiring

managers into the top of the funnel. And

you do that with projects, with a

portfolio, with visible proof. And every

time she switched to a yet another

LeetCode difficulty tier or another

algorithm category, her time got

fragmented. She lost momentum on the

things that would actually move the

needle. She was solving for the wrong

bottleneck. So, I told her what I tell

everyone, "You have to accept that some

things are good enough when they're not

the bottleneck." And I know this is hard

to hear in a tech culture that worships

optimization, but here's the reality,

nothing is ever going to be perfect.

Obsess over the details that matter, and

keep the list of those details very,

very short. Perfecting your LeetCode

score, that's not the thing that's going

to unlock your career. You either need

projects so good that hiring managers

can't ignore them, or you need a network

and a presence so strong that people

come to you. Most people obsess about

the stuff in the middle, customizing

their IDE, debating tabs versus spaces,

perfecting their note-taking system. But

on either end, proof of work and

visibility, that's where the real

returns are. This is brutal truth of

being a career changer or a self-taught

developer. You tend to have the most

ideas of things you could learn, but you

also have the least bandwidth to chase

those ideas. You're deeply constrained.

You have so little time and so little

energy, so few connections, you can

barely do one thing well, let alone

four. Your best shot at competing with

CS graduates and boot camp grads and

laid-off mid-level engineers are all

applying for the same junior roles is to

pick one thing and execute it at a level

that's undeniable. Now,

before I give you the road map, you need

to understand the landscape because you

can't set the right goal if you don't

know what the destination looks like.

Here's what's actually happening.

Software engineer jobs listings are up

over 30% in 2026 with more than 67,000

open positions. That's the highest

demand in over 3 years. At the same

time, over 52,000 tech workers were laid

off in Q1 alone and nearly half of those

layoffs were directly tied to AI. So,

what does that mean? Jobs aren't

disappearing, they're shifting. The

roles that AI can replace are going

away. The roles that work alongside AI

are exploding. Engineers are doing less

routine coding, they're spending more

time overseeing AI code assistance,

designing system architecture, and

making high-level decisions about what

to build and why. The job looks

different. That doesn't mean it's going

away. So, for someone trying to break in

right now, companies want three things.

Number one, builders, not students. They

don't care that you finished a course.

They want to see that you built

something. A deployed app, a real

project, something with a live demo.

Three to five strong portfolio projects

is the sweet spot. One polished deployed

project with real metrics beats 10

half-finished apps every single time.

Number two, AI fluency, not AI

dependency. This is massive. Companies

want developers who use tools like

Copilot, Claude, Cursor, but who

understand what the AI is actually

producing. They want you to use AI as a

power tool, not a crutch. The developers

getting hired can say, "I used AI to

scaffold this, but here's why I

restructured it. Here's why I chose this

architecture. Here's the trade-off I

evaluated." That's the difference

between a developer and someone who

prompts. Number three, depth in one

stack with the ability to move across

it. The T-shaped developer. Wide general

knowledge, deep expertise in one area.

You might be front-end focused, but you

need to be able to set up a database,

write an API, deploy to the cloud.

Employees are increasingly hiring based

on demonstrable skills and portfolio

work over degrees. Open source

contributions, personal projects, proof

of production experience. That matters

more than where you went to school. So,

here's what to do instead.

Step one, identify your one constraint.

Right now, you probably have a list of

things you think you need to do. Learn

React, learn TypeScript, get AWS

certified, build a portfolio, do

LeetCode, start networking. Let me ask

you this, if you had 100% certainty that

you could accomplish just one of those

things one year from now, which one

would get you the furthest? Think about

it. Even if you cracked TypeScript, you

still need projects. Even if you learned

AWS, without a portfolio, there's

nothing to show. But if you built three

deployed full-stack projects, you have

proof of work. You have something to

talk about in interviews. You have

GitHub repos that demonstrate real

engineering. Everything else you want to

do becomes easier once this is done. So,

that's your priority. Build three

production quality portfolio projects.

You can ignore everything else because

until this happens, nothing else moves

the needle. Now, some of you might

think, "What if I learn TypeScript while

building the project so that by the time

I'm done, I have both?" The problem with

this, in my experience, is that you have

limited resources. People actually

finish things faster when they do them

one at a time than when they run them in

parallel, especially when all of your

energy is concentrated on one objective.

Because when you know there's only one

thing on your plate, you attack it

differently. Every hour feels like it

matters. But when you've got five things

going, nothing feels urgent and nothing

gets finished. Step two, pick one stack

from real job postings. Go to LinkedIn,

Indeed, Built In, search junior software

engineer or junior full-stack developer,

pull up 15 to 20 real job postings,

write down the technologies that keep

showing up. I guarantee you'll see a

pattern. JavaScript or TypeScript, React

or Next.js, Node.js, PostgreSQL or

MongoDB, Git, basic cloud deployment,

and increasingly AI integration or AI

tooling. That pattern is your

curriculum, not some influencer's top 10

languages list. The actual market

telling you what it needs. Pick that

stack, write it on a sticky note, put it

on your monitor. This is your short

menu. That's how you should think about

your stack. If mastering TypeScript,

React, Node, and PostgreSQL is enough to

get you hired, and it is, then why are

you spending time on anything else? And

the hard truth is that a lot of the

other things you want to learn are

genuinely interesting. Python is useful.

Docker is valuable. Machine learning is

fascinating.

But none of them will get you hired if

you can't execute on the fundamentals

first. Good ideas don't fail because

they're bad, they fail because you

spread yourself so thin that nothing

gets done properly. And every single one

of them will fail if you're chasing all

of them simultaneously. Yes, including

the one that just popped into your head

while I was saying this. The side

project, the new framework, the shiny

thing you bookmarked last week. Yes,

that one. Put it on the list and close

the list. Step three, build three

projects that can prove you can work.

Not tutorial clones, not to-do apps,

real projects that solve real problems.

Project one, a full-stack CRUD app with

authentication, user registration,

login, create, read, update, delete

data. Deploy it. This is your

foundation.

This proves you understand the full life

cycle of a web application.

Project two, an AI-integrated tool. This

is 2026.

Build something that calls an AI API, a

content summarizer, a code review bot, a

meal planner powered by an LLM. It

doesn't need to be groundbreaking. It

needs to show you can work with an AI

API, handle async operations, and build

something that feels useful. This is the

project that separates you from 90% of

other appli- Project three, a

collaborative or real-time app. A

project board with live updates, a chat

application, something that demonstrates

WebSockets, complex state management,

multi-user functionality. Bonus, if it

has a CI/CD pipeline you can explain.

Each project gets a live demo link, a

clean GitHub repo with proper readme,

and a short case study. What problem you

solved, how you built it, what you

learned. That's it. Those three projects

done well will get you more interviews

than 50 tutorials ever could. Step four,

learn in public and network with intent.

Post about what you're building. Share

your progress. Write about bugs you

solved. Record walkthroughs. This builds

your brand and creates a body of

evidence that you're serious. And

network like this, not 200 cold DMs

saying, "Hey, any openings?" Three to

five genuine touches per week.

Thoughtful comments on posts from

engineers at companies you want to work

for. A short message saying, "Hey, I saw

your talk. I'm building something

similar. Would love your thoughts."

That's networking. Step five, prepare

for interviews like it's a separate

skill. Two sessions a week on coding

challenges. Focus on arrays, strings,

hash maps, basic algorithms. You don't

need hards, you need mediums. Clean with

clear explanations. Practice behavioral

questions with the STAR method.

Situation, task, action, result. Have

three stories ready and run mock

interviews. The gap between I know this

and I can explain this under pressure is

where most people fail.

Now, here's the part that's going to

hurt, and it's the most important part

of this whole video.

Make a list, write down everything you

want to learn. Rust, machine learning,

Kubernetes, system design, mobile

development, GraphQL, Web3, whatever.

Write it all down, name the list

something ridiculous like Phil's fantasy

curriculum or things I'll learn when I'm

a staff engineer, so you can remind

yourself how absurd it would be to be

able to try all of this right now. I

keep a version of this list myself. It's

long, well over 100 items, technologies

I want to explore, side projects I want

to build, certifications I could chase.

And you want to know how many things

I've actually pulled off that list and

acted on it in the past year? Two, just

two.

And I have more time, more resources,

more technical debt than most people who

are just starting out. I'm telling you

this because doing less sounds easy, and

it's actually one of the hardest things

you will ever do. And here's what's

wild, when you finally give yourself

permission to stop chasing the list, you

feel lighter immediately. Because so

much of the stress and anxiety you carry

around comes from this backlog you've

invented for yourself. This mountain of

things you think you should be doing,

and all you have to do is take the

entire backlog and say, "This is not my

job right now. My job is to take the

things I'm already doing and do them so

well that they can't be ignored." And

I'll tell you what's going to happen.

You'll make more progress than you ever

have. And it's going to frustrate you

because you'll realize that's the thing

holding you back this entire time.

Wasn't lack of time or knowledge or lack

of ambition. It was the fact that you

kept diluting your effort across 10

directions instead of channeling it into

one. That realization stings. I know

because it stung me, too. And I'm

telling you now so you don't have to

waste as much time as I did learning it.

A lot of you won't actually follow

through on this. The pull on something

new is too strong. But the ones who do,

and I've watched this happen with my

mentees, will be stunned by how fast

things move when they stop

overcomplicating it. Every time a new

framework drops, every time someone on

Twitter says, "This changes everything."

Every time YouTube recommends a video

about the next hot language, you're

going to want to open a new tab and

start chasing. Don't. If you've been

watching this and thinking, "This makes

sense, but I need someone to actually

walk me through this, review my

projects, prep me for interviews, and

hold me accountable." That's exactly why

I built my mentorship program. Last

year, over 50 people went through this

program and broke into tech. This year,

we've already had a dozen land roles.

Real people, career changers, and

self-taught developers who went from

exactly where you are right now working

at companies like Zillow, American

Express, and NatWest. I'm saying this

because I was you.

I was a 30-year-old English teacher who

thought it might be too late, who

thought maybe I wasn't smart enough,

maybe I didn't have the right

background. And now I've been a senior

developer, a tech lead, and I've helped

dozens of people make this exact same

transition. If you want help figuring

out the one thing you should be focused

on right now, the one bottleneck that's

keeping everything else stuck, check the

link in the description. I'd love to

help you with that. And if nothing else,

take the framework from this video and

go execute. One stack, three projects,

learn in public, prep for interviews.

I'll see you in the next video. And just

remember, if I can do it, you can do it,

too. Coding saves lives.