Cover photo by Annie Spratt on Unsplash
Even though I’m not from the era of webmasters, I know that at least since 2012 there have been courses promising super-fast training to turn you into a developer. This isn’t exclusive to front-end either — back in college, there was a joke about a video called “Learn C in 5 hours.”
The problem is when nobody warns you not to take that seriously.
Photo by Thought Catalog on Unsplash
The Problem with Learning
Learning is a subjective concept. Especially for me — I’m not a teacher — I can only talk about what works for me. But there’s generally some agreement among educators that everyone has their own optimized learning style.
A course using Method A might work great for Person 1 but poorly for Person 2. A course using Method B might be the opposite. Person C might do well with both, and Person D with neither. Even without digging into academic research, I can give a practical example: on the official React site — the front-end library — on their tutorial page, there’s a box saying you can follow two paths: one for people who learn by doing, and one for people who prefer a “bottom-up” conceptual approach. That already points to at least two different learning styles. The last suggestion, that both paths complement each other, might even hint at a third method: combining the two at the same time.
All this “theory” — if we can call it that — boils down to this: content creators who make courses or tutorials only control how long their course lasts. They might estimate how much practice time you’ll need beyond the lessons, to estimate total effort. The problem is that this estimate doesn’t take into account different learning styles, so it only makes sense if your personal method exactly fits the course’s approach. In my experience, that rarely happens.
Never try to twist your learning style to fit a course or content. It’s often impossible, and if it is possible, it will require a huge effort — and when you look for another resource, you might try to do the same again. That’s a recipe for slowing down your progress. I’m not saying you shouldn’t optimize your learning: if a tip improves your process, go for it. But if something isn’t working after a reasonable effort, switch. Today we have endless sources of knowledge, especially in development. Don’t get stuck.
This also applies to this post. If you don’t get what I mean here, ask me to explain it differently. If that still doesn’t work, find other sources or talk to others. You don’t even have to finish reading, or you can come back later when it might make more sense.
The Problem of “Leveling Up”
Photo by Isaac Smith on Unsplash
Besides the problem of learning, there’s the problem of leveling up: at what point in the journey of learning programming is a person considered a developer? There’s no agreement.
Some courses and bootcamps leverage this ambiguity — sometimes even against learners. This doesn’t stop you from learning, but it creates false expectations. You don’t develop a “developer mindset” just by finishing a course. You gain more technical knowledge. Is that enough to be a developer?
We can argue about what counts as “enough” for a developer: is just knowing how to make a webpage enough? Okay, but do you have to build it from scratch or can you use frameworks? Does it just have to work, or should it meet performance benchmarks like Lighthouse? Do you need to know accessibility at this stage? Is knowing HTML/CSS/JS enough, or do you also have to know concepts that apply to mobile apps (like notification APIs or phone features)? Should you understand UI/UX to spot issues? And what about soft skills?
There are a lot of questions. If some of these are mandatory, I wouldn’t call myself a dev.
For companies, they might require some amount of experience before hiring you as a dev. That makes the course-to-dev connection even less direct. Other companies might hire you with little experience and train you during onboarding, making outside courses optional.
The point is: there is no single moment when someone “becomes” a developer. It doesn’t exist. A person gradually acquires developer skills, might get a job in the field, and keeps learning. They didn’t “become” a dev the moment they got hired, because you can be a dev as a hobby and never work professionally. It’s not finishing course X or Y, because you might learn other ways or even without formal learning and still build a product that meets many requirements.
Lots of Advice, Few Final Words
Photo by AllGo - An App For Plus Size People on Unsplash
I’ve laid out a lot of questions about who is or isn’t a dev. If you’re just starting out, don’t panic. That’s not my goal. I want to protect you from thinking a course is “mandatory” just because everyone you know took it, or that those who did are somehow better or will get what they want faster.
The other extreme is dangerous too: yes, no one can promise you’ll be a dev in a week. But there are trusted resources recommended by established people and companies, with estimated timelines to master topics. Again: estimates, not guarantees. You should be open to advice from people who agree there are many paths to the same goal. Avoid advice from those selling you something or offering a “revolutionary” one-size-fits-all path — that just doesn’t exist.
My recommendations for beginners wondering “am I really a dev?” are three:
Read the Front-end Handbook: you don’t need to read it all. It’s not a technical book but a great summary of the front-end profession, technologies, what you need to apply for jobs, and where to find knowledge. It’s suggestive and updated yearly (although 2020 wasn’t released, the 2019 version is still relevant).
Follow the front-end developer roadmap: updated every year, it shows technologies and how they fit into a journey. I don’t know everything there — neither do most devs, because it’s not necessary — but it’s great for beginners to have some order and context.
Use the front-end web developer learning path on MDN: despite the tagline saying it teaches you everything to become a dev, I disagree. It teaches you how to build simple pages based on solid fundamentals you can apply in any framework — which is essential. MDN is my daily dev reference. Their descriptions are concise, designed for quick reference, not official docs.
I already recommended the Front-end Handbook back in 2018 in a post of mine here. The other sources are newer or I discovered them later. I’m always looking for solid, renewable sources to recommend.
There are YouTube channels, courses, articles, and dev.to posts that will be very positive for your career. During and after your initial process, build the habit of accessing these sources to learn more and share knowledge. Never stop learning.
And don’t make this post your only source. Talk to other people, share your thoughts. I want to hear your opinion!
Top comments (0)