Most people remember the first time they opened a terminal. Maybe it was a Tuesday night, on a laptop at a kitchen table somewhere. The window was black. The cursor blinked. And the person sitting there was completely convinced that every other human on earth had been handed some secret manual they'd never seen.
The feeling that everyone else already knows this and I'm the only idiot in the room is the real reason many quit before they start. The work isn't too hard, and they're plenty smart enough. The trouble is that nobody ever hands them a map. They're just dropped into a forest and told the exit is somewhere to the north.
So here's a map. Something that experienced developers are only now starting to say out loud: The path in has changed over the last few years, and a lot of the old advice is out of date.
Don't Learn to Code. Learn to Build Things.
This is the single most important reframe for anyone starting out in 2026. The senior developers and design technologists who've been thinking hardest about the learning path keep landing on the same point: coding and making things are genuinely different activities, and conflating them is what sinks most beginners.
When we say "coding," we mean it in the traditional sense: memorizing syntax, learning paradigms, wrestling with package managers, and debugging a missing semicolon at 2am are just a few examples. It's what you do when migrating a database from one system to another. It's grunt work. No one wants to do grunt work. What people actually want when they "learn to code" is to make something – a website, a tool, a little app that solves an annoying problem in their own life. For Major League Hacking, it's often why someone comes to their first hackathon. Curiosity and a drive to try to build something new.
Those two goals used to be inseparable. If a person wanted to make a website, they had to spend three hours installing Homebrew, then three more installing Postgres, then three more configuring their development environment, before they ever typed a single line of the actual thing they wanted to build. Many beginners quit somewhere in those nine hours, convinced they just aren't cut out for it. The truth is they are – they're just being asked to build the entire toolbox before they get to put a hammer to a nail.
AI has broken that chain. The setup work, the boilerplate, the hunting through Stack Overflow for the right command – the stuff that used to eat the first two months of a beginner's life – can now be handled in a conversation. The craft hasn't disappeared. It's evolved.
The skill today is less about typing the code and more about knowing what to build, knowing whether what got built is any good, and knowing how to ask the right questions to get it there.
A New Coder Is Not Behind. They Are Normal.
More than one in three developers in Stack Overflow's 2024 survey had been coding for four years or less, and about a quarter of working professionals report just one to four years of experience. The industry is much younger than anyone would have you believe. And 82% of developers are learning with online resources, compared to 49% who learned in school – so the self-taught path is the real way in for most working developers today.
Software development as an industry is full of people who taught themselves the parts that mattered most, often while working other jobs, raising kids, or switching careers later in life. Changing careers at 35, parenting a toddler while learning, coming in from a liberal arts background — none of these are disadvantages. They're the everyday profiles of a new coder's future colleagues. And in the AI era, when the entire industry is learning a new way of working at the same time, everyone is a beginner at something.
What "First Language" Even Means Now
Often experienced developers get the same questions. One is "which language should I learn first?" Beginners can turn this into a weeks-long research project. They read comparison articles. They watch YouTube debates. They ask on Reddit and then argue with the replies. Months pass. They still haven't built anything.
Here's the updated answer, and it splits into two paths depending on where the learner wants to end up.
Path One: The Software Creator
Someone who wants to make a personal website, automate an annoying task, build a tool for their own life, or just prove to themselves they can make something new that works. This person should probably not spend months picking a language. They already have one: it's English or the language they grew up speaking. They can open a conversational AI tool – Claude, ChatGPT, Google's AI Studio – and describe what they want to build colloquially.
"Build me a portfolio website for a photographer."
"Write me a script that renames all the photos in this folder."
The AI can generate the code, explain what it did, and walk the learner through deploying it. This is vibe coding, and it has opened the door for an enormous number of people who would have quit during the Homebrew-install step five years ago. For this path, the "first language" question basically disappears. The first language is the one they have spoken all their life.
Path Two: The Aspiring Professional Developer
Someone who wants to work in software, whether that's engineering, DevOps, security, or any role where they'll need to audit, debug, and extend code written by other people (including AI). This person still benefits from learning a foundational language the old-fashioned way, and two of the most popular options are:
- Python: The friendliest syntax in the business, reads almost like English, sitting at the top of the TIOBE Index since late 2022. Great for data, automation, and AI adjacency.
- JavaScript: The language of the web, used by 62% of all developers in the past year, the most widely used language on the planet. Best for anything that lives in a browser.
For these learners, the advice is consistent: pick one language, don't agonize, and actually finish learning it. Your first language does something very important. It teaches you how to think like a programmer, and that thinking is what helps you audit output later. If an AI agent writes something subtly broken – an insecure database connection, a login form that leaks user data – the beginner who skipped foundations might ship the bug because they don't see it. The one who learned foundations has a real shot at catching it.
Many working developers recommend a hybrid approach to these two paths: Build the first thing with AI to catch the excitement and the momentum, then go back and ask the AI to teach instead of type. Prompts can look like:
"Explain why you structured it this way."
"What would happen if I changed this line?"
"Can I try writing this next part myself?"
Using AI as a coach rather than a grunt worker is a legitimate and increasingly common way to learn.
The Trap Called Tutorial Hell
Here's the part nobody warns new coders about. They'll find a great course. They'll finish it and feel incredible. Then they'll find another course, because the first one was so satisfying. Then another. They'll nod along to every video, understand every line the instructor types, and still freeze the moment they open a blank file on their own.
This is tutorial hell, and it can get almost anyone.
Why does it happen? Because watching someone code is like watching someone swim. A person can follow every stroke, memorize the breathing pattern, understand the biomechanics, and still sink the second they jump in. Think about watching the Olympics with your family. Every mistake elicits loud groans. Hopefully you're also turning and laughing together with the understanding that you can sit on a couch and critique, but landing that quadruple axel would be impossible without Ilia Malinin's years of experience, particular brand of confidence, and whatever brain chemicals send him launching himself into the air with blades on his feet.
Reading about a skill and performing a skill use different parts of the brain. The tutorials feel like progress because the brain is genuinely learning something – it's learning to recognize code. But recognizing code and writing code are miles apart. Nobody fully learns a new language on Duolingo. They learn it in conversation with native speakers, fumbling accents and verb conjugation, and generally looking a little bit silly. Then next time they pay at the bodega, they're a little bit better.
The rule experienced developers learn the hard way: finish one short tutorial, then immediately build something with it – even if that thing breaks.
What matters is that it's the learner's own, right away, even if it's tiny and ugly and barely works. Break it on purpose. Change things. Delete things. Google every error message that pops up. Or better, paste the error into an AI and ask what it means and why. That last part isn't cheating. 61% of all developers spend more than 30 minutes a day searching for answers, and most of them have been doing this for years. Looking things up is the skill. The professionals aren't the ones who have memorized everything – they're the ones who've gotten very good at finding the answer in the next 45 seconds.
AI as a Learning Tool
Now, 37% of developers use AI to help them learn, and it has quietly become one of the most powerful tutors ever invented. It's patient, available at 2am, willing to explain the same concept ten different ways until one of them clicks. The conversational nature has been a real breakthrough. A new coder can ask the questions they're embarrassed to ask in a bootcamp classroom, and get the answer in seconds instead of searching for it 500 different ways. That alone has reshaped what beginner education looks like. But the line between coach and crutch is real.
Asking AI to explain an error, unpack a concept, or walk through why code works the way it does is learning. Letting it write the project while the learner nods along is tutorial hell with a chatbot.
Build the Ugly Thing First
A new coder's first real project should be useful to exactly one person on earth: themselves. That's it. They are both the developer and the entire customer base. This is liberating, because it means nobody else has to like it, understand it, or ever see it.
Some projects that work beautifully for beginners:
- A script that renames a folder full of photos from IMG_4823.jpg to something a person can actually search for.
- A little webpage that shows today's weather in the learner's city.
- A to-do list they actually use.
- A tracker for how much they're spending on coffee this month.
- A program that picks a random restaurant so nobody has to argue about dinner.
- A tiny game like tic-tac-toe, hangman, rock-paper-scissors.
- A portfolio site that replaces their ancient, and heavily templated, Squarespace.
These work because they share three traits. They're finishable. They solve something real for the creator. And when they break – and they will – the learner will actually care enough to fix them.
Please, resist the urge to build the next Instagram as a first project. A finished ugly thing beats an unfinished beautiful thing every single time.
When it's done, put it on GitHub, even if the code is embarrassing. GitHub is a source of real intimidation for many beginners, so it's worth demystifying: despite its reputation as a community space, it is fundamentally a version control tool. Think of it as Google Docs for code. It tracks every change the learner (or their AI assistant) makes, so nothing is ever truly lost. The community layer sits on top of that, not underneath it. A learner does not need to "earn" the right to be on GitHub. They just need a project and an account.
You can also bring it to DEV. Post about your project. Ask people for feedback. Read and respond to the comments. While MLH hackathons are incredible labs where you can build these first projects (or your 100th) with others over a few days, DEV is available 24/7. We think of ourselves as both the Lab (MLH), and the Library (DEV), where you can learn all the time.
The Disappearing Middle, and How to Not Be It
Here's the uncomfortable thing experienced developers might be quietly worrying about, and every new learner should know it too. AI has made the distance between absolute beginner and productive builder smaller than it has ever been. But it has also, at least for now, eroded the middle layer of expertise – the years a new developer used to spend wrestling with real problems on a team, learning what "good" actually looks like, absorbing the multi-point pre-flight checklist every senior engineer builds over a career.
That erosion is a problem, and the beginner who doesn't plan for it will get stuck.
A vibe-coded app can ship fast. It can also leak every user's data the moment it goes live – there are news stories about exactly this happening, more than once, in the last year. The beginner who built it with AI and never learned the underlying concepts may not know what went wrong, may not know how to find the thing that needs fixing, and may not know what questions to ask next time. The beginner who used AI as a coach – who built, then went back and examined the code, who asked why and what if – has a much better chance of being able to do these things.
The practical advice: build first, then audit. Ship the ugly thing, then open the code and ask the AI to walk through it line by line. Ask what it would do differently for a real product. Ask what security practices it skipped. Ask what a senior developer would change.
Over time, that accumulated questioning becomes the expertise the middle layer used to provide. The learners who will thrive in this era are the ones who use AI to build fast and then stay curious enough to learn what just happened.
How To Stick With It
There's a stretch, usually somewhere between month two and month six, where a new coder will feel dumber than they did the day they started. The tutorials got easy and then the real projects got hard, and everything in between feels like fog. This is not a sign the learner is failing. It's the sign they've left the shallow end.
Three things keep people in the chair through that stretch.
- Shrink the goal: Thirty focused minutes a day will take a learner further than a six-hour Saturday binge, every single time. Consistency compounds. Burnout erases. Plenty of career switchers have made it through on forty-five minutes a day before work, for a year or more. It's a whole strategy.
- Find a room: Other beginners are the difference between a hard month and a lonely one. An MLH hackathon, a Discord community, a DEV conversation, a local meetup, a coworker a few steps ahead, a friend who's also learning.
- Keep a "done" list, not just a to-do list: Every week, write down what got built, learned, fixed, or figured out. "Got my first API call to work." "Finally understood what a for loop actually does." "Deployed my first site." On the weeks when everything feels stuck, the only thing that reliably works is scrolling back through that list and remembering the learner couldn't do any of it six months ago.
That list is proof. On the bad days, proof is the only thing that keeps a person typing.
![Defluffer - reduce token usage 📉 by 45% using this one simple trick! [Earthday challenge]](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fiekbgepcutl4jse0sfs0.png)
