On imposter syndrome, the myth of being "naturally technical," and an honest roadmap from someone who has read enough stack traces to know that the error is never where it says it is.
Let me set the scene.
First week of college. A lab full of people who had apparently been coding since they were twelve, somewhere between "Hello World" and an existential crisis about whether to use tabs or spaces (spoiler: the answer is spaces, and this will cause your first real argument with another developer). The person next to me had already configured something called a linter, set up version control, and was asking the professor about deployment pipelines like they were making small talk about the weather.
I was still figuring out where to save my file. I remember thinking, maybe this just isn't for me.
That thought , quiet, persistent, thoroughly convincing, like a background process you didn't know how to kill, followed me for longer than I'd like to admit. Every tutorial I couldn't finish, every error message that confidently said "unexpected token" (unexpected to whom? certainly not the token), every GitHub repo someone else casually had that I didn't, all of it felt like evidence. Evidence that there was a category of people who were simply built for this, and I was not one of them.
If any part of that sounds familiar, this is the post I wish someone had shoved in my face on day one.
The Myth: "Tech People" Are Not a Species
We have collectively decided that technical ability is a trait, something you're either born with or you're not, as if some people shipped with a built-in git installation and the rest of us are running on legacy hardware. The "tech person" archetype is everywhere. The one who built their first app in high school. Who speaks in frameworks and pull requests. Who has opinions about databases that they will share with you unprompted at a party. (You will meet this person. You will not be able to leave the conversation.)
What that picture doesn't show you are the years of failed attempts. The hundreds, genuinely, hundreds, of Googled error messages. The projects that never shipped, never compiled, never even got past the part where you try to install the dependencies and your terminal starts regarding you with what you can only describe as quiet contempt. The long stretches of feeling completely, thoroughly lost.
You're not seeing a natural. You're seeing someone who has failed in private, far more times than you know, and has simply been doing it longer. Most people who seem naturally good at tech either started earlier, failed more times, or simply Googled better. That is genuinely, entirely it.
Programming is structured logic. Design is pattern recognition. Software development is the discipline of breaking large, terrifying problems into smaller, merely annoying ones. None of this is magic. None of it is innate. It is structured thinking, practiced over time, and structured thinking is learnable by anyone willing to be confused for a while and not take it personally.
The real trap is that tech might be the only field where beginners routinely compare their chapter one to someone else's chapter fifteen. And that comparison is where "I'm not a tech person" takes root , not in evidence, but in a deeply, almost impressively unfair point of reference.
The Feeling, or, How I Learned to Catastrophise in Four Languages
My first hackathon. A group of us went mostly out of curiosity, being the people who didn't yet know what they don't know.
Everyone around us had a tech stack, a plan, strong opinions about their tech stack, and the general energy of people who had been preparing for this specific moment. We had a half-baked idea, a team name we'd come up with in the elevator, and exactly one person who'd used an API before (once, briefly, accidentally).
I remember watching the table next to us debate cloud deployment options while we were still arguing about what our app was supposed to do. It wasn't intimidating in the dramatic, movie montage sense. It was quieter than that, just a slow, creeping realisation that everyone here was operating with a manual I hadn't been given, in a language I could almost but not quite parse.
When the next phase came around, I didn't show up. I told myself it was fine. That it didn't matter. That it was just for fun anyway. All of which was true, technically, and none of which was the real reason. The real reason was I had encountered a system I didn't yet have the context to navigate, and instead of treating that as a gap to close, I treated it as a verdict. Which is exactly the wrong interpretation, and also exactly what most people do.
Here's what I know now that I didn't know then, that feeling has a name, it's extremely common, and it is lying to you. Research from Caltech's counselling centre found that around 70% of people, including objectively high-achieving people, experience imposter syndrome at some point. In tech, where the learning curve is steep and everyone's GitHub is public, the number is almost certainly higher. The person sitting next to you, nodding along with apparent confidence? Statistically, there is a solid chance they are running the exact same internal monologue and just have a better poker face.
Clance, P.R. & Imes, S. (1978). "The imposter phenomenon in high achieving women." Psychotherapy: Theory, Research & Practice.
Imposter syndrome is dangerous not because it hurts, though it does, but because of what it stops you from doing. It stops you from asking the "stupid" questions. (There are no stupid questions. There are only questions you'll have to Google alone at 2am if you don't ask them now.) It stops you from trying things in public. It stops you from making mistakes loudly. And making mistakes loudly is, almost without exception, how you learn anything in this field.
The reframe that actually helped me: discomfort isn't a warning. It's a receipt. It means something new is being processed. If you're not uncomfortable, you're probably just re-reading documentation you already understand and calling it productivity.
The Visibility Problem: Everyone Seems Ahead Because the Internet Only Shows You the Highlight Reel
There was a period, probably second semester, when I was deeply convinced that everyone around me was building something impressive in their spare time, had a side project already half-deployed, and knew which framework was worth learning right now. Felt like I was the only person not in on some shared secret.
I wasn't. I was just spending more time on LinkedIn than was healthy for me.
I'd watch people in my college's tech community, people I knew personally, people I'd eaten unremarkable cafeteria food with, and feel that specific, quiet intimidation of someone who suspects the group chat has a group chat. They were doing things I couldn't yet do, discussing things I couldn't yet follow, and making it all look very casual, which is somehow the most demoralising part.
But here's the thing about polished GitHub profiles: behind every one of them is a commit history full of messages that say things like fix, fix again, why, and okay this time for real. Behind every confident lab presentation is someone who rehearsed it four times and still mispronounced a library name. It's just invisible, because nobody posts their failures on LinkedIn.
Skill and visibility are not the same thing. The loudest voices in any room are often just the most confident, not the most capable.
The moment I genuinely absorbed this, I stopped measuring myself against a standard that had never been real to begin with.
At some point I made the most important decision of my learning journey, I stopped trying to learn everything at once.
My browser at peak chaos: a Node.js course I was 40% through, a web dev roadmap in a separate tab, an intro to data science, something about machine learning I'd opened because it sounded important, a JavaScript tutorial I'd bookmarked two weeks earlier and opened exactly once. I was a human browser with too many tabs open, technically running, fan absolutely screaming, and context-switching so aggressively that nothing ever made it to long-term memory. Classic thrashing. The OS eventually slows to a crawl too.
The reason this doesn't work is structural. Things build on each other. You cannot meaningfully understand how a REST API works if you don't understand how functions pass data. You can't debug an async function if you don't understand sync execution. Trying to learn full-stack development before you understand what a variable holds is the equivalent of trying to read a novel when you haven't learned the alphabet yet, ambitious, deeply inefficient, and a reliable way to generate confusion that has nothing to do with your actual ability.
What I did instead: I picked one thing and stayed with it until something actually clicked. Depth creates confidence. Surface-level breadth creates the feeling of progress, which is a very convincing counterfeit that will waste months of your time if you let it.
The Roadmap: What to Actually Do (In Order, With Real Advice)
Not a listicle. Not just build projects! delivered with the energy of someone who has never stared at a blank file and wondered why the cursor blinks with such aggressive indifference. This is what actually works.
1. Use Tutorials, But Escape Them Before They Become a Comfort Blanket
Tutorials are training wheels. Necessary at first. A problem if you're still on them when you should be riding.
The trap is finishing a tutorial feels productive, and your brain rewards you for it , because your brain cannot tell the difference between understanding something and watching someone else understand something while you nodded along. (This is, incidentally, also how most people watch cooking shows without ever learning to cook.)
The fix: as soon as something in a tutorial makes sense, close it and try to recreate it from scratch in a blank file. Don't copy. Rebuild. You will immediately discover approximately seventeen things you didn't actually understand, and that is the point. That friction, that specific, irritating gap between "I watched someone do this" and "I can do this", is where learning lives.
One tutorial per topic. The "maybe this other course explains it better" spiral is where time goes to die.
2. Learn Concepts First. Syntax Is Just Autocomplete Waiting to Happen.
You will forget syntax. Every developer forgets syntax. Senior engineers, people who have been doing this for a decade, Google basic syntax with a regularity that would comfort you enormously if you could see it. The dirty secret of the industry is that most of us are one browser tab away from not knowing what we're doing, and that's fine, because the tab is always there.
What you don't forget, if you actually understood them, are the concepts. How data moves through a program. What a loop is actually doing and why it exists instead of twenty identical lines. Why a function is a unit. What "asynchronous" means beyond the word itself and why it matters when you're waiting on a network call. These ideas transfer across languages, across frameworks, across the entire industry. Syntax is notation. Concepts are the thing.
When you're learning something new, slow down at the why before the how. Why does this need to return a value? Why does this variable live outside the loop? Why is this function async? Ask it like a very persistent five-year-old. The answers are where the understanding is. Syntax you can look up. You cannot look up intuition.
3. Build Things. Small, Embarrassing, Beautifully Unimpressive Things.
The best thing I ever did for my learning was build a to-do list app that no human being would ever willingly use. It was ugly. It broke on refresh. It had a bug where deleting one item deleted a different item, seemingly at random, as if the array had developed opinions and a grudge. I spent a day fixing it. I understood indexing properly for the first time. Worth every minute.
Real projects produce real problems. Why doesn't this update when I click? Why does this variable not exist outside this function? Why is this value "undefined" when I can "see" it right there? These are not tutorial question, there's no answer key, no next video, no instructor who has pre-solved it for you. They are engineering questions. Working through them, one at a time, with increasing speed, is how actual skill gets built.
Start with something that has one feature. A page that displays your name. A button that changes colour. A form that saves one input somewhere. Get that working, actually working, not "works on my machine" working, and then add one more thing. The compound interest of small, completed features will take you further than any ambitious project you abandoned at 30%. Finishing matters more than scope, every single time.
4. Break Things Intentionally. Your Curiosity Is a Debugger.
There is a gear-shift that happens somewhere in the middle of learning, and it is the most important one: you stop asking "how do I do this?" and start asking "why is it done this way and not another?" Why does this framework structure files this way? Why does this function return a promise instead of just the value? Why is this pattern considered an anti-pattern now when it apparently wasn't three years ago?
A practical way to build this habit: when you encounter code you don't fully understand, don't just move on. Change one thing. See what breaks. Change another. See what doesn't. Remove a line that looks optional. Watch the whole thing fall over. This is reverse-engineering your own understanding, and it builds intuition faster than reading documentation because it forces your brain to engage with the structure rather than just observe it at a safe distance.
This is also what separates someone who can follow a tutorial from someone who can solve a problem they've never encountered before.
5. Use AI as a Thinking Partner, Not a Vending Machine.
We are learning in an era where you can describe a problem to an AI and have working code in your clipboard before you've finished your sentence. This is either the most powerful learning accelerator in history or the most elaborate way to never actually learn anything, depending entirely on how you use it.
The trap: you ask AI to write the code, it writes the code, you move on, and you have learned approximately nothing except how to write a prompt. Worse, you've now got code in your project that you cannot debug, extend, or explain, which will become your problem the moment something breaks at the wrong time. The AI has had a productive session. You have not.
The right approach: use it to explain what you don't understand, to surface tradeoffs you hadn't considered, and to get unstuck when you've genuinely hit a wall after actually trying. But insist on understanding every line before you move on. Your understanding of your own project should always exceed the AI's involvement in it. Otherwise you're not building skill, you're outsourcing it to a model that won't be there when the interview starts.
6. Be Consistent. Boringly, Undramatically, Persistently Consistent.
There is no montage moment. No single hackathon that transforms you, no dramatic breakthrough at 3am where it all makes sense at once. What actually compounds is quiet: thirty focused minutes every day, building something, breaking something, understanding something incrementally more.
Research on deliberate practice, Ericsson's work, which you've heard cited a hundred times because it keeps being correct, shows consistently that frequency and quality of practice matter more than intensity. Thirty minutes daily beats a ten-hour sprint weekly, not as a motivational aphorism but as neuroscience.
Ericsson, K.A., Krampe, R.T., & Tesch-Römer, C. (1993). "The role of deliberate practice in the acquisition of expert performance." Psychological Review, 100(3).
Make the bar low enough that you clear it every single day. Consistency that actually happens beats intensity that doesn't, by a margin that compounds over time into something almost embarrassingly large.
The Click: What Confusion Actually Means
There is a moment everyone in tech knows intimately. You stare at the same block of code for an hour. Nothing resolves. You've read it so many times the syntax has stopped looking like syntax and started looking like abstract art with a semicolon problem. You take a break. You come back. You read it again. And then, sometimes immediately, sometimes the next morning for reasons your brain declines to explain , it clicks.
That is not talent. That is not luck. That is literally how the brain builds understanding, through repeated, imperfect exposure. The first time you see something, it feels impossible. The third time, familiar but slippery. The fifth time, it starts to feel like yours. Cognitive science calls this consolidation, the brain converting new information into long-term understanding, a process that happens mostly during rest, which is why the breakthrough so often arrives the next morning and not during the hour you were actively suffering through it.
Stickgold, R. & Walker, M.P. (2013). "Sleep-dependent memory triage." Nature Neuroscience.
Confusion is not a signal that you're failing. It is a signal that you're processing something genuinely new. If you're never confused, you're probably not learning anything that stretches you, which means you've accidentally plateaued while feeling productive, which is arguably the worst outcome.
The best engineers I've encountered are not the ones who always have the answer. They're the ones who are completely comfortable saying "I don't know this yet", and then going to find out, systematically, without drama. That comfort is itself a skill. And unlike most skills in this field, it requires no tutorials. It just requires deciding that not knowing is a starting point, not an indictment.
The Only Metric That Matters
I want to end with something small.
A while after that first hackathon, after the feeling of being in the wrong room had started to quiet down, I was sitting with people from my tech community and someone made a joke. A niche, specific, deeply nerdy programming joke. The kind that only lands if you understand what a null pointer exception is, why it happens, and why it specifically ruins a day that was already not going well.
I laughed. Actually laughed. Not the polite "I'll figure out why this was funny later" laugh, because I got it. It sounds like nothing. But that moment, being in on it, feeling like the language had started to become mine a little, meant more than any tutorial I'd completed. It was the first time I thought, okay. Something is actually changing.
You don't need to know everything. You just need to keep going long enough that the things that once felt foreign start to feel, if not easy, then at least navigable. Familiar. Yours. The only comparison worth making is you yesterday versus you today. Not the person whose LinkedIn you've been auditing at midnight. Not the developer with two hundred commits this month. Just you, and the version of you that didn't understand something that you now do. That gap, however small, is the whole point.
"Progress in tech isn't about how much you start with. It's about how stubbornly you continue."
So here's what you do, build something small. Break it immediately, because you will. Understand why it broke. Build it again. Repeat until the error messages start to feel less like personal attacks and more like a compiler being genuinely helpful in the most annoying way possible, and ultimately on your side.
The people you're comparing yourself to? They're still breaking things. They've just gotten faster at figuring out why. You were never not technical enough. You were just earlier than you thought.
Now close this tab and go write some code. It doesn't have to be good. That's not the point yet, and honestly, it wasn't the point for anyone else either, at the beginning.
