Realistic Learning Roadmaps

·

12 min read

It's amazing that there's no end to the number of resources available online for learning anything in the tech field, but this leads to newcomers being overwhelmed with the sheer volume of courses, videos, bootcamps, docs and interactive platforms that are often recommended by others already in the field.

A newcomer to this space will be bombarded with thousands of articles, videos and posts on platforms like YouTube, Reddit or dev.to that claim to have the "definitive roadmap".

To clarify, roadmaps are basically guided learning paths. Essentially a list of "learn this, then learn that, do this in the middle" that's intended to be the go-to step-by-step process for becoming a junior, mid-level or senior. In reality, these roadmaps are often either too simplistic/broad or unrealistic in the amount of time they usually claim is sufficient to complete them.

The Burden of Choice

Let's step back and consider why a newcomer would even need a roadmap. It should be easy to simply parse job descriptions for an idea on what technologies a position will require and just tackle those individually, but it isn't.

The first barrier to entry is that there's a lot of unknown pre-requisite and supplementary materials for the technologies actually listed in a given job description. These pre-requisite and companion materials are branching in the sense that for each library there are potentially dozens of technologies that will pair perfectly with it and are used in industry to accompany it.

The second barrier to entry, compounding the first, is the number of options available for an aspiring developer willing to put in the work and learn what they need to. There are simply too many libraries, frameworks, concepts, patterns, technologies and principles to learn from too many course websites, videos, articles, documentation pages, guides and open university courses. It sounds like a first world problem, but this flood of options and resources leads to every developer having a unique collection of information due to the difficult choices they have to make when learning. Effectively, every developer is different in some way unless they follow the same learning path.

This is where roadmaps come in. A roadmap promises some guidance on what to learn and in what order or what to focus on in order to gain the skills needed to perform the role well. In principle, there's nothing wrong with them. In practice, they leave a lot to be desired.

The Problem With Roadmaps

A rampant issue we have is that roadmaps often just parrot the names of libraries instead of explaining why to learn this or that technology or this or that library. There are also roadmaps that are just collections of disconnected links which expect you to learn a concept from a random article or page and then jump to a completely different article or page to learn a related concept... This makes no sense!

The major issue with these library-centric roadmaps is that they encourage learning the tools instead of the concepts. This is understandable, given that the job market requires knowledge of the tools more than the concepts in many cases. But unless the learner knows this beforehand, they'll end up ignoring many of the concepts that will allow them to keep their job when the library they've learned is eventually deprecated in favor of the newer and shinier contender.

I see this a lot with people who learn a framework and skip learning the basics and understanding the architecture of applications, when their framework of choice is deprecated or when they're offered a new position using a different framework a lot of them struggle to make the switch. This is because after following their framework centric roadmap they became framework users not developers.

The solution for this is simple, roadmaps can be descriptive of why you need to learn something. But even when a roadmap has relevant content and descriptive resources like this one for frontend developers and the same one but for backend developers, it can often look very intimidating to beginners. There's so many items that make little sense to a complete beginner that even with guidance on where to start, it's impossible to look at the whole list without feeling discouraged from trying. Effectively, the roadmap becomes a giant self-study syllabus without a teacher and that barrier becomes very difficult to overcome.

Escaping this, newcomers will end up searching for a more structured learning path to follow. This usually comes in the form of a course on an online platform like Udemy or a long video series on YouTube or structured journey-based websites like The Odin Project, freecodecamp and Full Stack Open. I have nothing against these approaches and, in fact, that's the way I'd recommend for most newcomers. These websites are mature and have started many developers' successful careers and can often be a saving grace when all the other resources are too dispersed to properly learn anything from.

However, there's a dangerous common issue that faces both those who follow a roadmap and those who follow guided resources: Burnout.

Burnout

By this point, you may have realized that there are indeed a lot of things you need to learn to become an effective developer. What I've discussed so far does not dispute this fact. However, it helps to outline that the real issue here isn't that you have to learn a lot, it's that you'll experience burnout.

I'm sure not a single developer on Earth can claim they've never felt a little burnt out while learning new things. In fact, it's so common that it's often assumed to be part of the process, that it'll happen eventually and delaying it is the best we can do. Simply put, when trying to follow a roadmap and giving yourself a strict timeline, you could often end up either covering too much in too little time or being stuck on sections that ultimately don't matter and becoming discouraged.

I strongly disagree with the idea that burnout is inevitable. In my own experience, I've suffered from it before, but rarely have I ever felt like I hadn't locked myself into this unhealthy pattern of not pacing myself to the point where it caused burnout in the first place. I can't stress enough that the point of a realistic roadmap and proper pacing along the way isn't to ensure that you'll learn everything, but rather to ensure that you can do that while maintaining the balance of your life and your mental health.

Building A Realistic Roadmap

At this point, I'd like to include a disclaimer that I am not creating a roadmap for you to follow. Rather, I am going to include a set of guidelines that I've personally used to build my own roadmap to avoid burnout and make sure that I've covered the material that I need at a pace that makes me comfortable. It's also worth noting that everyone has their own method and process when learning and I do not discourage you from deviating as little or as much as you'd like from this set of guidelines.

You Can Learn For Free

Because a lot of developers struggle with finding where and what to learn, a lot of people have capitalized on this by offering absurdly priced courses, resources and even roadmaps costing money. There's nothing wrong with paying for learning materials, but you don't have to.

Practice, Don't Cram.

Development is inherently a practical field, a lot of the knowledge that we acquire is meant to be applied when developing, designing or architecting systems and applications. The approach of trying to fly through materials as fast as possible or to keep cramming until you get tired is not going to allow you to properly process this information and retain it.

Try to learn one "thing" at a time. If you're feeling like you haven't covered enough today, instead of covering more material, prioritize applying what you've learned. If today's thing is a new framework, try building an application with it. If it's a library, try using it in an application. Keep your learning sessions short and your practice sessions frequent to avoid forgetting things.

Read Job Descriptions

The new and shiny libraries of the day are often overrepresented in online material; from articles to videos and pages dedicated to this new tech, it can be easy to forget that companies still use stable and battle-tested tech. This can so extreme as to be old and deprecated, but remember that you're focusing on the concepts and not the specific libraries.

Job descriptions usually include the main technology that you'll be working with day to day, other supplemental technologies may or may not be mentioned as well. Reading these allows you to know what to keep an eye on for your desired position, but keep in mind you shouldn't take it as gospel that what's required in this job description will be what's required in the same role at a different company. Be mindful of what's being used in the industry to guide your learning process, but do not let it overwhelm your choices.

Build Meaningful Projects

This is different from practicing in the sense that I'm not talking about building a little project to try out a library or a framework, but rather building a project to allow you to run into real world issues that you would only face when building an application or system.

If you can avoid template project tutorials like "How to build a Facebook Clone", I strongly suggest you stay away from them. These projects, unless you wildly innovate on them, act as a placeholder on your resume and portfolio. Not to mention that, usually, you end up making no decisions of your own for the application.

Coming up with project ideas is difficult, but you don't need to build something complicated. My approach is to build things that I'd like to use or have like tools or to build exploratory projects or working with weird and interesting libraries.

Join The Community

Whether you'd like to know about new and interesting technologies, get help from other learners, help other developers with their own learning path or even just see what other people are learning, I believe you should join online communities like Reddit's many learning-friendly subreddits such as r/learnprogramming or websites like dev.to. These positive communities encourage participation and discussion while allowing developers of all levels to ask questions and help each other.

Finally, Don't Give Up

The big secret to learning anything is consistency, it's more useful to study an hour a day for a year than it is to study ten hours a day for two weeks.

The more you learn, the more knowledgeable and confident you'll become and the more receptive you'll become to learning even more amazing things. The beautiful thing about becoming a developer is that one day you'll realize you know a ton of things and have a million ways to tackle the many problems that computers are built to solve.

You should be aware that the reason I urge you so strongly to build your own roadmap is to avoid two central issues: tutorial hell and being a master of nothing.

Let's Talk About Tutorial Hell

I'd like to shed some light on tutorial hell and why it's the reason roadmaps can be dangerous.

When you learn a technology without having a reason to, as you would if you were simply learning it because someone told you to, you can often miss the intended learning outcomes of this technology; or what you were supposed to learn about it beyond its syntax or its constructs. In essence, you lose out on what the point of this technology is.

When your only knowledge of a technology is its syntax or usage, you can very easily fall into tutorial hell: where the only way you can make anything using this technology that you know is to follow a guided tutorial teaching you how to make something with it.

I hinted at this earlier when I urged you to avoid "How to build a Facebook Clone"-type tutorials, these are purpose built for padding your GitHub and your resume with "projects" where in reality you know nothing about the decisions involved in building the project or the process followed to make those decisions. You serve as an outside observer to the whole part of the process that as a developer you should be involved in, the decision making, problem solving and architecture.

Following roadmaps and guided resources can be a double-edged sword, with the right mindset they can be infinitely more useful to you than simply learning every technology possible and hoping something sticks. Building your own well-researched roadmap helps you understand why you're learning a certain technology and by understanding the reasons you're covering this material you can hopefully avoid relying on others to tell you in what way to use a tool you already know how to use.

A Jack Of All Trades, A Master of None

To bring it all together, I'll clarify the biggest problem with the majority of learning paths that new developers follow. Whether it's a roadmap; a guided course or simply parsing job descriptions and learning what they list off, a newcomer would believe that there's so many technologies on their radar that they end up being a jack of all trades and a master of none. To become a frontend developer, they would think that even the smallest styling library makes sense to learn compared to the component framework that they would be actually using the vast majority of the time.

By giving equal focus to so many technologies, you can very easily lose sight of what technology is the most important to your role or to the job you're applying for. It's easy to get lost in the details when you don't yet have the insight into the development process to know the value of what you're learning.

The common pitfall here is developers will learn every major component framework on the frontend side or every server framework on the backend side instead of focusing on one and learning the concepts that will easily be transferrable if they move to another.

Earlier I mentioned that learning only the specifics of a framework makes you a framework user and not a developer, which is true, but the critical detail here is that doesn't prevent you from learning those specifics in addition to the concepts that you need to know. Gaining deep knowledge of your tool of choice is always an excellent idea and is necessary to be an effective and productive developer, the mark of a great developer is to know how to eject from this technology into a similar one at will.

To sum up: master the concepts, gain expertise in your technology of choice and focus strongly on gaining general skills in your role rather than learning 1% of every tool available or learning 100% of only one tool.