I came across Adam Golab's "React Developer Roadmap" some time ago, however, having spent the past few weeks deep-diving into React, I wanted to take another look at it from the perspective of my own experience.
Adam's roadmap rightfully starts out with the basics. Having a solid understanding of HTML, CSS and JavaScript on their own is essential. I would however, put an asterisk on the "JS Basics". While you certainly need to know the basics, the "Basics" listed cover enormous parts of the JavaScript landscape and factor into some of the React specific elements later in the roadmap. My feeling is that JavaScript needs its own section.
As my career has progressed, JavaScript has been an area of increasing focus for me. Becoming better at JavaScript should be a continual and ongoing process. While I understand exactly what Adam means by "basics" the reality is that, the concepts listed there will come in handy at any and every level of your programming journey. No matter how long you have been at it, I am convinced that there will always be something new to learn or to review with JavaScript (especially since it evolves at such breakneck speed). Considering how widely used JavaScript is, investing into improving your core JavaScript skills is something to focus on in an ongoing capacity.
When I first started learning HTML and CSS, CSS-based layouts with floats were becoming the norm as people moved away from "table-based" layout. For many years, that was more or less the standard required. With the emergence of CSS3 and later CSS pre-processors along the ever increasing improtance of responsive layouts catering to mobile devices - the importance and challenge of CSS increased. To my mind, CSS is at times easy to dismiss as a "lesser" skill than JavaScript, but don't be so quick to judge. CSS is surprisingly hard to master. Combine CSS with multiple, ever changing device sizes and multiple ever changing browser capabilities and you have the ingredients for some incredibly messy and confusing CSS code if you are not careful.
In my experience many developers will claim to "know" CSS and then proceed to write poor CSS. CSS is deceptively simple at a glance, but surprisingly tricky to get right. With the proliferation of CSS-in-JS libraries in the React world, my feeling is that it is very important to spend a solid amount of time coming to grips with CSS. Now that there are at least 3 major layout approaches available: floats, flexbox and grid it is necessary to have a grip on them. Not to mention the two large camps of pre-processors in SASS and Less. Not to mention the CSS-in-JS crowd or the ever increasing number of CSS frameworks and design systems finding their way into the mainstream. Just a few years ago, Bootstrap, and to a lesser extent, Foundation, became massively popular. Since then, an ever increasing variety of frameworks have emerged - most of which are listed in Adam's Roadmap. The trick here, however, is to focus on knowing the CSS basics very well. Regardless of the "framework", the core CSS knowledge is the most important to learn because, when it comes down to it, the frameworks are all just manifestations of CSS.
The same should also be said for JavaScript - while frameworks may come and go. You are far better off investing first in learning the language and then in the framework. Knowing JavaScript will help you to learn React, Angular or Vue, but only knowing "Angular" will only get you so far in respects to the others.
When it comes to the section "General Development Skills", my feeling is that there needs to be some separation here. I understand why these skills are listed together, but my feeling is that "Data Structures and Algorithms" and "Design Patterns" should be more closely linked to a possible "Intermediate to Advanced JavaScript" section. Creating another JavaScript-related area would emphasise just how important JavaScript is to the entire roadmap. Especially since, out of the major frameworks (React, Angular and Vue) React tends to be more JavaScript-y than the others.
That being said, "Data Structures and Algorithms" and "Design Patterns" are also segments that are not JavaScript specific. The way they are applied to JavaScript might be more or less unique, but the concepts, patterns and algorithms will be knowledge that can be applied broadly to more languages. So maybe, there is something to be said about "meta" skills on the roadmap. Some are unique to JavaScript or React, but really, there is a lot going on underneath the covers that relates more broadly to programming and problem solving at large.
When it comes to "Terminal usage", my feeling is that, in a sense, this is a skill that comes hand-in-hand with working with Git, npm and the various CLIs that are so popular these days. Anyone working with Git, npm and any form of CLI is going to become far more familiar with the terminal than they would otherwise. In my own experience, I started learning terminal when I started to use Gulp. Granted, some people may prefer to use GUIs that sit on top of Git, either through the VS Code or IntelliJ (or similar) IDEs or some other means. My advice, however to new developers would be to put in the effort and try to learn and use the terminal before relying on the GUIs. Once you have a decent grasp of it, move over to GUI tools if you choose. The reality is that, the command line, is effectively the 'real' lingua franca of the computer world. Before touch, before the mouse and the GUI there was the terminal.
My feeling is that the best way to learn HTTP/HTTPS and API clients is to work with API based projects. You will learn a lot just from inspecting the XHR tab on the Network panel of your browser developer tools. From there you can start building Postman or Insomnia collections. (Or better yet, if you really want to show-off your terminal skills, start using cURL). Nothing will teach you more about HTTP/HTTPS/APIs than working with directly with APIs.
From there, one can take a swing at learning to build your own APIs. Now, this might not really fit in nicely with a "React" roadmap per-se, but for me, the best thing I did for my JavaScript skills was to learn Node.js and start building my own APIs.
I will be the first to admit that the term "full-stack" seems to be overused and misunderstood. In my experience, the larger an organisation or a team gets, the smaller the focus of a particular developer will tend to become. By their very nature, small teams will benefit from less people doing "more". Whereas larger teams tend to gain efficiency by "more" people doing "less". Not less in terms of productivity, but less in terms of the overall scope of their work. As such, unless you are working as an independent developer or a developer in a small team, chances are good that you are inherently focusing more on one part of the stack than another. The reason I bring up this topic however is because, by learning Node.js, and in relation, how to build APIs, you are essentially investing into improving your overall JavaScript skills in a big way.
Maybe it comes down to how I tend to learn things, but I really felt that my JavaScript knowledge improved immensely once I dug into Node.js. Building APIs and learning about the nature of backend development opened so many doors and lifted so many perceived limitations from my programming mindset. Learning Node.js helped me realise that I could be a "real" programmer despite my "front-end only" background.
Searching for and finding solutions is definitely a skill. As is recognising when and how to learn from, absorb and apply the solutions you find. Something I would add, or rather preface "searching" with are two slightly more fundamental skills:
I have found that one of the greatest breakthroughs in my programming life came about when I realised that I could improve my comprehension of code and of error messages just by reading code. In a way, when you start out, error messages are a terrible thing. They feel like blame or punishment. They are often in the colour red, and they are written in weird, hard to understand language. To the beginner, they often leave you confused and demotivated. The more you read code and error messages, the more you will begin to ask yourself questions about what you are reading and the more helpful they will become.
Next time you read code or an error message, don't just read it. After each line, ask yourself: "What does this code (or error message) mean? What is it telling me if I were to translate it into plain language?"
Something immensely useful in this process is "Rubber Duck Debugging (RDD)". Especially if you are a remote or independent developer, taking this approach will do wonders for your ability to solve problems.
Something I often try to remember when facing a bug is to acknowledge two things:
As such, via process of elimination you start stepping through your code to verify whether what you think is happening, is actually happening. Chances are good you will soon find the source of your bug.
To be continued...