This week was no exception. I've been trying to find more ways to teach you how to be exceptional, but the well is drying up. I don't really have a good article-like story-filled email for you this week 😔

SO INSTEAD I SAID SCREW IT, LET'S REVAMP ​THE ROADMAP.SH FRONTEND ROADMAP​!

Instead of working hard with words, I decided to work hard with diagrams! I will never allow the well to dry up. If it does, I'll just continue drilling deeper 😎

HAVE FUN:

Now, I know what you're thinking... Why the heck revamp the roadmap at all?

​Roadmap.sh​ is a wonderful resource for any developer. It gives you a terrific map of the things you could learn in the future and helps you understand where in the learning journey you probably are.

I only have one problem with it.

While it's great for showing you the recommended order in which to learn each big topic of front-end development, it's missing an overall structure of how these topics relate to one another.

The roadmap, as it is, is basically a diagrammed, ordered list. First, learn HTML, then CSS, then JavaScript, then Git, then... ad infinitum.

As a complete beginner, I have a massive amount of knowledge to learn. I don't know what anything is. I don't have a mental model of how these topics work together.

"What's Git? How does it relate to code? Why are there so many frameworks? How does OAuth work in the front end? Does that have to do with SSR? What is SSR? I'm so confused!"

With the roadmap as it is, I learn a new topic and then have to do all the hard work of understanding how this new knowledge integrates with all my previously learned knowledge. But it doesn't have to be like that.

So, I want to kindly challenge the current roadmap, give a new perspective on learning you could pick up as an exceptional frontend developer, and offer an alternative change to the roadmap:

What if we kept the order in which we learn things as is in the roadmap, but then rearranged the physical locations of the topics and gave them a dotted "bounding box", which shows how they relate to each other?

Suddenly, you look at the roadmap and something magical happens.

I'm not learning 24 different topics that I have to later understand how they relate to one another. I'm understanding that the front end could be divided into these "islands" that host a wide variety of topics. These islands can be called:

1. Fundamentals

2. Collaboration and workflow

3. Frameworks and Architecture

4. Security

5. Advanced CSS

6. Type Safety

7. Other advanced stuff

And look! I can see categories and their topics at a glance now. I can quickly understand that Git, build tools, linters, and package managers are tools related to collaboration and workflow. TypeScript is for JavaScript type-safety. Frameworks and SSR are heavily related to architecture. As a beginner, would I know how that exactly happens? Nope, but it doesn't matter! I know that those are tightly linked topics at a high level.

That's not even the best part! The new roadmap still respects the original order roadmap.sh has. It's just that now each topic has a number attached to it, which shows what order to tackle each one.

Notice that it's not sequential. If you were to follow the new roadmap, you'd still be jumping around to different islands. You'd first start with fundamentals, learn a few topics of collaboration and workflow, but then fall into picking a framework, and then go all the way back to learn more advanced things about CSS.

This benefits you because it creates a physical map of the topics instead of an ordered one. Which helps because even though learning is sequential, knowledge is relational.

With this type of map, you get the best of both!

Now don't get me wrong – I love and have complete and mad respect for the wonderful people at roadmap.sh, who have helped me and thousands of devs guide our learning and how to level up!

I just think it would be fun to rock the boat a bit, offer an alternative for roadmapping your developer journey, and (hopefully) find a nice way of rethinking how to make learning easier.

Let me know what you think!

And as always, have a wonderful weekend ❤️

Four years ago, that was the first thing I learned when I took the plunge into front-end. There was an "order" to how to learn this set of skills for making websites.

If we take a look at sites like the front-end roadmap, we can see this in action. There's a recommendation being made here in what should (more or less) be known in what order.

This is helpful because, in most fields, a few key concepts have to be introduced first. That way, they can be used to build other concepts on top of those.

In front-end development, these first concepts are HTML, CSS, and JavaScript. And they take quite a while to get the hang of in the beginning. But then afterward you realize there's an endless list of concepts, knowledge, and tech stacks to learn. So then... how can you make learning a little bit easier?

Understand that while learning is sequential, knowledge is relational

We don't store information in our heads as if it were a giant array that we just access whenever we want.

(That would be funny if we did though. Imagine if remembering what you had for dinner last night meant accessing brainInformation[5739575397522572402774525727529524837438595])

Instead, it's more effective to store information in our minds based on the relationship it has with other information.

Think of information as just data. It's facts, memories, ideas, thoughts, and opinions that we can absorb and remember at a later date.

"The date March 14th"

"My co-worker today wore a Yoda shirt"

"Avocados are a fruit, not a vegetable."

By themselves, these little bits of information hold no value. There is no context behind them or reason for them to stick out from other information you hold in your head. In fact, without a reason to remember these little bits of data, they become very easy to forget. And in fact, your brain does this every day with most of the information you learn and see.

To better remember information, it becomes necessary to make it relevant or related to other information in your brain. So if we wanted to remember this information better we could say:

"The date March 14th is relevant because it's my birthday"

"My co-worker today wore a Yoda shirt and he told me last week it's his favorite shirt. He must really love Star Wars"

"Avocados are a fruit, not a vegetable and I guess I don't know what a vegetable is anymore oh no. This changes my definition of vegetables."

Suddenly, these little bits of information become more memorable, and you're more likely to store them in your head for longer. Doing this with information to make it easier to remember is a skill... And that's exactly what knowledge is.

Knowledge is the ability to relate information to make it more memorable

Information is only as useful as the use you can get from it. And the value of information will always come from its relationship with other bits of information.

That's why when you're learning, always try to relate it with other bits of information. Try to explain the similarities and differences between two concepts, and you'll quickly understand them better.

For example, what are the differences and similarities between HTML and Javascript?

Can you clearly explain that without googling or asking AI? 👀

Congratulations Reader! You got your fancy nice computer and chair, met the team, got onboarded, and were given your first ticket:

Add a button on a webpage

"Oof, how do I do that again? What's a tag? Where's the repo again? What's a variable?"

It takes you three days of googling, but you manage it! Let's go 💪

You just completed one small task of what turns out to be a huge and complicated machine of millions of moving parts and processes.

We call this machine "the software development process".

To make sense of this giant machine, very smart people in the past figured out you could divide this process into a series of steps or phases. These phases are part of what's called "the software development cycle" (SDLC)

It's a simple series of concepts and is separated into x amount of steps. The x number will depend on which author you choose to read (although the main concept doesn't change). For this explanation, let's say there are 6 steps:

1. You talk to the client and plan what you want to make or develop

2. You analyze how hard it would be to create what the client wants, what resources you'll need, and identify all requirements based on said needs of the client.

3. You sit down and design the solution. This means working together with designers and architects to get an idea of how you're going to build it.

4. You develop and build it! This is a very long and messy step. You'll run into loads of issues and it usually isn't pretty.

5. You finish development and QA takes over as they test the developed code to make sure things work as expected. Once everything is okay, you integrate it.

6. Maintenance starts. This means you support and fix any issues that might pop up as the software runs and is used by its users.

Every step and phase has its roles and processes to follow. There's a lot of simplification going on here as well, as most of the time, the phases can have a lot of back and forth, as well as overlap, and can happen at the same time! So, understand this involves a lot of nuance in practice.

Despite the nuance, it still means that developing software is a team effort. In a big project, you might need project managers, functional analysts, client and stakeholder participation, architects and designers who consider scalability and UX/UI; developers for backend, frontend, and DevOps; quality assurance teams; and lots and lots of money and time.

If you're a freelancer or a senior dev, you might need to put on different hats and help with many phases of the development cycle.

But if you're a junior dev, you'll only have to focus on 2 or 3 phases in the beginning

You're still figuring stuff out. You're understanding how to develop software based on somebody's interpretation of the client's needs. Things are still really hard! So don't worry (too much) about planning, analyzing, or designing the software. As you gain experience and increase the impact you have, you'll slowly learn the different skills these phases require.

But for now as a Junior?

Just focus on the Software Development Croissant 🥐

Focus on learning how to implement (with best practices), work with QA teams, and maintainability of projects.

Another way of looking at these phases is they're the steps that will help you practice and improve your hard skills. You know, the program-y types of skills we all love to work on. How to implement code in such a way that it's easy to read, easy to test, easy to maintain, easy to scale, and easy to add upon.

Once you more or less get a good handle on it, it becomes easier to consider the other aspects and skills needed in the other phases.

Plus croissants are delicious and dividing the wheel in 3 makes it look like a croissant!