I struggle sometimes relating to people who are just learning the ropes in development. If you are a junior developer and you ask me what resource I would recommend to learn some hard skill (SQL, coding, etc), I am probably the last person you should be asking. The path I took was weird. Like, REALLY weird. I have only met a small handful of people who have had a similar path.
I have been writing code since I was four years old. I had my first software business before I was ten. By sixteen I was tutoring adults working toward their master's degrees in computer science. I never studied it formally. I did not need to. I do not remember not knowing it. Which means I have no idea how to evaluate the resources that exist to teach it. I can look at something and tell you whether it is accurate. I cannot tell you whether it would have helped me learn it from scratch, because that is not a thing I can remember doing.
That is just what an unconventional background gets you. It sounds impressive until someone asks a simple question and you realize you cannot answer it from experience. But, AI has changed things quite substantially. Now everyone is getting into development in an unconventional way. Everyone entering the market has to deal with the Swiss cheese effect of knowledge that is missing because you just never had a reason to learn it yet. If you are entering the world of development now... your problems are similar to my problems in theme, but very different in shape.
What I can do is have a lot of conversations. I mentor juniors (Lord help them). I work alongside them. I review their work and watch them grow.. and sometimes watch them stall. And over time, a pattern has emerged that I keep coming back to.
The One Thing I Can Tell You About Learning
There is actually one answer I can give to the learning question, even if I cannot give it from the angle most people expect.
Find a reason to need to know the thing before you try to learn it.
Do not learn a technology because it is on a job posting or because someone told you it is cool and/or important. Figure out what you want to build first, and then learn whatever you have to learn to build it. The gaps will show up on their own. When they do, fill them.
I taught myself trigonometry because I wanted to build a 3D engine... I wanted an operating system that behaved like Doom. Program groups would be rooms -- icons would be objects you could run around (I was 12... I wanted to build a game engine and use it for productivity... I was a weird kid.) I had a fully working 3D engine four years before school got around to teaching me trig. I remember sitting in that class completely bored, not because the material was beneath me but because we were doing the thing to learn the thing. There was no engine. There was no reason. Just concepts floating in the air disconnected from anything I wanted to make exist.
Knowledge for the sake of knowledge has never worked for me. What works is needing to know something in order to do something I actually care about doing. That is not a learning style. It is closer to a philosophy. The technology is not the point. The point is what you can DO with the technology. Purpose before tool, always. I say that here because it is directly relevant to everything that follows. The juniors who struggle most right now are not struggling because they picked the wrong resources. They are struggling because they are trying to learn how to use AI without a clear picture of what they are trying to accomplish with it. And a tool without a purpose has a way of becoming the point... which ironically... isn't the point.
Someone will reasonably object that this is easy advice if you already have a project in mind and harder if you do not. Fair. But I would push back on the framing. If you are pursuing a career as someone who builds things and you genuinely have no idea what you want to build, that is worth sitting with. A dry spell is real and it happens to everyone. But if there is nothing you want to make exist, no problem you want to solve, no thing that irritates you enough to want to fix it, then the career path itself might be worth questioning. Software development is not an abstract credential. It is a practice in service of something.
If you are in a dry spell, the answer is simpler than most people make it. Find something that annoys you. Something in your life or your work that is tedious or broken or slower than it needs to be. Then try to automate some or all of it away. In the current environment, that is more accessible than at any point in the history of the field. That is its own conversation, but the short version is: the project does not have to be impressive. It just has to be real.
Performing Versus Showing Up
There is a version of junior output that looks impressive on the surface. Organized, thorough, covers all the bases. It makes a bunch of assumptions, almost all of them wrong. It is also, consistently, the least useful thing I receive.
The more valuable output is usually shorter. It asks a specific question. It admits uncertainty. It shows me how someone is thinking rather than what they think they are supposed to say. That version is harder because it requires you to actually produce original thought instead of reaching for a template of what competence looks like. I don't expect competence from a junior yet. I expect to help them build the skills to achieve competence. But more on that later.
AI has made the performing version easier to generate and easier to recognize. The model fills in blanks with whatever is statistically most likely to be true across the broadest possible version of the situation. It does not know your situation. It knows all situations. When a junior hands me AI output without bringing themselves to it first, what I get is a document that could apply to almost anyone generally, and almost nobody specifically. In the beginning I just want them to understand the context I already do. Later, I want them to contribute something non-obvious. Crawl, walk, run.
Potentially a hot take depending on which circles you are in... using AI output as a crutch while you develop taste and judgment sounds reasonable until you think about what the crutch actually does. Coming across as authoritative before you have earned any authority is, at best, going to make you look a little silly to someone who recognizes the shape of it. At worst it is going to genuinely put off someone who does not realize it is AI output and holds you to it. That is not a temporary cost you pay on the way to getting good. That is a debt a junior does not need to take on. While every senior should want to teach, many don't. One of the primary early jobs of a junior is to motivate a senior to take them under their wing.
There is a meaningful difference between using AI to help format and organize something you already drafted, and asking AI to draft the thing from scratch. The first one is a legitimate tool. The second one, at the stage where you have not yet developed judgment, is borrowing credibility you do not have. The interest rate on that is higher than most juniors expect. You do not know what you do not know, AI makes it look like you're pretending you know it all.
Nobody likes a know-it-all. Unless you really do know it all... like me of course.
And to the objection that this is easy to say for someone who never had to struggle with the basics: that was a fair critique a year or two ago. It is not today. You have tools like Claude Code and Codex. You have models that will walk you through every single line of code and explain exactly why it works the way it does. The basics are more accessible than they have ever been in the history of this field. Not knowing something is a starting point, not an excuse. The tools to close that gap are sitting right there. The internet was a game changer, having an AI assistant who can customize lessons to your specific situation makes it a question of motivation and integrity, not availability of information.
The Superpower Nobody Is Talking About
When I try to course-correct on this, I am not telling juniors to use AI less. I am telling them to use it differently.
The way too many people still use these models is as an answer machine. The allure of a one-shot prompt that delivers everything you could ever want is certainly fun, but that version of using LLMs is more like playing a slot machine than doing anything useful. What I have found that produces frankly unfair results is using AI as a thought partner, not a genie.
Before you ask for an answer, ask for the questions. What would a senior developer want to know before weighing in on this? What context is missing? What are the assumptions baked into this that might not apply here? If you give the model your actual situation, team size, history, constraints, what has and has not worked, it will ask you back for the things you have not thought about yet. That's how you use this to augment and amplify rather than replace.
The iteration is the superpower. Not the generation. The people who get the most out of AI are the ones who go back and forth, push, disagree, ask for alternatives, ask for the weaknesses in the approach the model just recommended. One-shot prompting is the floor. Most people are camping there.
A model will confidently give you a point of view if you do not bring your own. The developers who come out of this era well are the ones who developed a point of view strong enough to survive contact with the real world.
Fake It Till You Make It, Revisited
"Fake it till you make it," when done right, was never about pretending to know things you do not know. It was about projecting enough confidence to stay in the room while you are still figuring things out. Ask the question that feels risky. Admit you do not understand something instead of going quiet. That version works because it accelerates learning. You use the grace period you have been given. You develop faster than the people performing competence.
Junior developers have something real and finite: a window where everyone in the room knows you are new, and nobody reasonable expects you to have all the answers. That window closes. The juniors who use it well, who ask every question that feels stupid, who push back on their own assumptions, who ask AI to challenge them rather than just serve them, those are the developers who level up fast.
Now look, I am not going to pretend that every environment gives you that window. There are places where asking questions gets held against you, where looking uncertain shows up in a performance review, where the grace period described here is shorter than it should be or does not exist at all. The advice here is still the advice. But if you are working somewhere that punishes you for not knowing things you were never taught, I am not going to tell you that is your problem to solve. I'll just add a small addendum to the advice: Run. Find somewhere else. There are better places. And if that is your story I am genuinely sorry that your employer sucks.
AI made the other version of fake it till you make it too easy and too transparent. You can produce something that looks like senior-level analysis if you squint and turn to the left faster than ever. But the people who have been around the block who look at it without squinting will recognize you for doing exactly that.
If Your Name Is on It
There is something I find myself saying to juniors in some form or another more often than anything else. You are a steward of this codebase. It existed before you got here. Someone else is going to be in it after you leave. Write code you would not hate walking into blind. Even if you stick around in the code base for some time, write code you won't hate yourself for in 6 months because you completely forgot the context in the moment that led you there.
That responsibility does not change because AI generated the code. If your name is on the pull request, it is your code. Every line. Before you open that PR, you should be able to explain what every line does. Not because someone is going to quiz you, but because if you cannot explain it, you do not own it. And when it breaks, which eventually some of it will, you are going to be the one who cannot point the debugger in the right direction because you do not actually know what the thing is doing.
AI is a phenomenal tutor if you use it that way. Have it walk you through the code it just wrote, line by line, before you ship it. Ask a second model to review it specifically for maintainability. Push back on complexity. Models are trained on code written by engineers who tend to over-engineer, which means the output often has more moving parts than the problem requires. More surface area to break. Harder to hold in your head. Harder to hand off. Ask the model what could be cut. Ask it what the simplest version of this looks like. A senior would push back on your implementation. Learn to do it yourself.
What Questions Actually Tell You
One thing I have come to believe about junior developers specifically is that their questions are often more useful than their answers.
An answer tells you what someone knows. A question tells you where they are. What they noticed, what they found uncertain, what they understand well enough to know they do not fully understand yet. That is real signal. And it is the kind of signal that gets suppressed when someone decides to perform instead of show up.
There is also something that juniors specifically have, which gets underestimated, including by them. They have not yet accumulated the years of pattern recognition that whisper in your ear that this would never work before you have even really thought about it. Which means sometimes they ask the question nobody else was willing to ask. And sometimes that question is the thing that actually opens the problem up. I have talked through technical issues with people who have no technical background at all, and the question they ask from outside the framework has surfaced something I had been walking past. Juniors can do that. It is worth developing rather than hiding behind a formatted list of someone else's best practices.
What I Am Actually Trying to Teach
If I strip away all of it and try to say the thing directly: I am trying to teach junior developers to stay in the work.
The model is going to show up and give you something. Your job is not to hand that thing to me. Your job is to go through it, understand it, fill it in with what you actually know about the situation, push back on what does not fit, and bring me the version that has you in it. If I could get more useful output by prompting the model myself, then the question of what I hired you for becomes harder to answer.
You are not a relay. You are not a proxy. You are the person with the context, the questions, and a name on the pull request.
The model cannot do that part. You have to actually do it.