Roadmaps to becoming a web developer in 2021

Hello, everybody out there in podcast land. I am Jerod, I’m your internet friend, and I’m here for an awesome episode of JS Party. We have a very topical and timely thing to talk about today - developer roadmaps. How do we become a web developer in 2021, or how to continue your journey if you’re part of the way down, as we all are. I have a very special guest; today I’m joined by Kamran Ahmed, who’s working on Developer Roadmap. Kamran, thanks for coming on JS Party!

Thank for having me here.

Good to have you, very excited. I wanna start off this episode with a tweet which hit my timeline - it looks like 17 hours ago - from Sam Sycamore. Very on-topic. He said “I’ve spent five years gaining experience as a carpenter, landscaper and home remodeler. That work earns me $21/hour, living paycheck to paycheck. I’ve spent less than five months learning web development, and today I closed two freelance deals that will pay my bills for the next three months.”

He then follows up and says “Not everyone can do what I’ve done, not everyone would want to do what I’ve done, not everyone would wake up at 4 AM to study and to perform physical labor from 9 to 5 everyday, but it can be done. If you think you’re up for it, then I hope you’ll go for it.”

Surely, in web development land everybody’s mileage varies. People learn at different paces. Some are given to it, some have to power through; we all have to power through a little bit. So it’s not as if everybody can do what Sam has done, but a lot of people can really thrive in this industry, and we’ve seen a lot of people do it. What are your thoughts on that, and Sam’s experience, Kamran?

[04:07] Exactly. I know a lot of people who have not gone through the formal education of computer science and still are making good money… So I think anyone, if you have the clear path and you have the good mentors and if you’re able to find out the correct way, you can even get started in a couple of months, 2-3 months and you’re really able to get a good amount of money from the freelance work or the actual job as well. So definitely, yeah.

Yeah, and not everybody wants to freelance; some people want a full-time job. We know that once you get through that first set of hurdles with regards to your knowledge in web development, there’s another set of hurdles which is organizations aren’t always hiring for junior developers; everybody wants the senior developer, so there’s a mismatch there.

There’s definitely challenges along the way, but we see that there’s huge opportunity, and we benefitted from the huge opportunity in this industry. So anything that I find, especially around helping other people down that path, I get very excited and I like to promote that.

I’ve found your repository, Roadmap to Becoming a Web Developer, in 2021; of course, it’s linked up in the show notes. We’re here to discuss it. It shows how to be a frontend web developer, how to be a backend web developer, there’s DevOps… There’s a bunch of stuff, and I’m sure you’re working on expanding it… But I was just curious, why did you create this project? What inspired you to put this work in?

Yeah, so I graduated from a university that is not a very good university. I graduated in the software engineering. When I graduated, I was doing random stuff; I did game development, I did Android development, I did web, I did a lot of different stuff… But I did not have a clear path of what I wanted to do, or how does the job market look like, and things like that. So I was always bugging my seniors at university and reaching out to people on LinkedIn, and GitHub, and here and there, asking them “What should I be learning?”

I saw that after some time spent in the industry I was getting asked the same questions that I was asking earlier in my career to different people, from my juniors, some of the people was working with… And as you said, there are a lot of people in the industry which are not formally educated in computer science. So from that, I decided to create a path and prepare a list of items that can help anyone get into the speed. And for example if you’re stuck or if you don’t know what to want to learn, you can look at this list and take what you want to learn next, and continue on with your journey. This was mainly the reasoning behind me starting this project.

So when did you start it? Because it’s for 2021, but I know you were working on it last year as well, and you just keep it updated. How long have you been compiling this roadmap?

So the first version was a very basic one. I just thought the really basic stuff. It was in 2016, I believe; at the beginning of 2016. So every year I run a survey, I look at what the community looks like, and based on my own experience, I keep updating, with the help of community also… So this is the fourth version, I believe; the most recent version. I’m still working on a 2021 version, but still, it is mostly up to date with the current landscape.

And is it all from your mind, or is it a community effort?

It’s a community effort, I believe. Also, it’s mostly me, because there are a lot people contributing with ideas and suggestions, but I did not really want to put everything out there. So I wanted to be very focused. So I’m really picky with the stuff that I put in there, but I have the help of the community, and I run the survey, and I look at the different – for example the State of JavaScript and a lot of different online community surveys, and stuff. I’m very aware of this every year.

Very, very good. And it’s worth pointing out that this roadmap is an awesome resource, but it is very much that. It is a map of choices. So in addition to this, you’re gonna have to team this with the How. So this is kind of like the What. What you should learn, what order perhaps you should tackle these topics, which ones work together, which ones are set at odds, you’re gonna have to choose between this and that as you work your way down the path…

[08:07] And you’ve demarcated what’s optional, what you think is required, things that you suggest, things that you would suggest necessarily… And that’s all very useful, but none of this is really the How. Like, “Well, I’m gonna learn HTTP, but… How do I do that?” You’re not trying to tackle that particular problem, right?

Yeah. One more thing I wanted to point out here is that the target audience for this roadmap is mainly the intermediate developers, the people who already have some idea, who are in the speed and are stuck in there, they don’t know how to level up.

For a beginner developer - it’s a bit different for that. I would not recommend you to go this path. I’m working on something and I hope really that in the next couple of weeks, by the end of January [unintelligible 00:08:45.14] But it’s going to be a different path for the complete beginner.

Okay.

So there’s that. And after that, the second thing is it depends on the job market also. This is mainly looking at the European market and looking at generally the area that I have worked in. So it is mainly targeting that. For example, the recommendations that I have here on the roadmap - for example, I’m not recommending React.js. In Germany there might be Vue.js, or in U.S. there might be something else, like Svelte, or whatever. So you should keep that in mind while you’re following this roadmap.

Now, answering your question - I wanted to give the spot… Because there’s nothing on the internet. If you are just starting or if you’re in the field you don’t know really what to look at. So I wanted to prepare this as a source that can guide people towards what they want to learn. Because if you want to learn how, you can always google and you can find tons of different material in the written form; or on YouTube, for example, there are a lot of YouTubers doing a really good job for that. There’s [unintelligible 00:09:47.08] There’s a lot of good people doing really good stuff.

Sure.

So you can find a lot of the sources out there. But I think the hierarchical path was missing there, so this I wanted to solve it as a source. But I have plans to put in the resources. I was working on something to make this roadmap interactive also… So there’s going to be soon the interactive version, so you’ll be able to click the items on the roadmap and be able to see where you can learn all of that.

Also, I’ve recently started my YouTube channel, so I wanted to go with the roadmap… But it takes a lot of time, so I don’t expect to put all of this stuff on my channel, but there’s a lot of stuff out there, so I’m going to link it to the roadmaps in a couple of weeks or so. This year my plan is to expand it and put this kind of stuff.

I love the idea of the interactive roadmap, especially if you can create an ecosystem around it. You may not be the best resource on how to learn DNS, but maybe somebody else already has that, it’s a great resource - well, link it through the interactive roadmap. But maybe you’re the expert on Node.js, or whatever it happens to be - then you can put your own resources where they fit. But then when you don’t have something, fill it in with somebody else’s.

So it’s very on-point to mention that this is for intermediate developers. This is not for the person starting from ground zero. Like you said, you may wanna have some stuff for that person down the road. Historically, what have you told people – I don’t know if you get this question a lot, like “Hey, I wanna get into web dev. Where do I start?” And since this is for intermediates, maybe you can check out the roadmap, but it’s not necessarily for you… What about a brand new person? Where do you usually point them?

That is a question that I get a lot on my Twitter. In my Twitter messages there are a fair bit of people/beginners asking “Where should I start?” This is the question that I get the most, so mostly I have a copy-pasted message that I wrote, and I paste it down…

Well, paste it to me in audio form here…

I will do that. So first of all, it depends upon the person; for example if you want to be a frontend developer or a backend developer, or if you want to get into DevOps. For the frontend developers I normally say “Just pick HTML.” For example, look at any source code… But even W3Schools is fine. Just go look at the HTML, just spend a week or two weeks going through the HTML, learn the basic – learn how to create the forms, learn about the structure, and just get the basics out of the way… And just prepare a couple of projects; the structure of some HTML pages of the website.

Then look at the CSS, for example, and then try to style these pages.

[12:13] For example, I ask them to copy the Twitter homepage, the login page. So when you have the form and all in HTML, after the two weeks when you are done with this, for example “Style this form to look like the page that you copied.” So do a couple of pages like this. Then for example pick the JavaScript and try to make it interactive. For example the form that you made, try to choose a validation method; when the user clicks it, validate the login, username and password, and show the message, like for example “Invalid username or password.” And do a couple of exercises like this, for example.

Then once you’re done with this, you have done some projects, just start looking for open source projects, or create a couple of templates on GitHub… Learn about the Git, for example, and create [unintelligible 00:12:53.23] on GitHub for a couple of projects in there… And then start from there; continue onwards, and then learn React, and then you can continue on with the roadmap. The same kind of path I have for the backend also, and so on.

So you don’t need to look at the roadmap itself, because the beginners – whenever I get a question, mostly on Twitter, people are really scared of this roadmap. They see that I have a hundred items in there. “It would take me like two years to go through all of this. How can I speed it up?” First of all, it looks daunting, but it really is not. If you [unintelligible 00:13:25.23] HTML, CSS, JavaScript, the basics, and then do a couple of projects, and then for example – like, most of the items in there, they don’t really take much time, like DNS, and how it works, and what is a domain name; you can easily do it in one hour or two hours, the internet section.

But a lot of items in there – so I plan on adding a timeline there also, in the future… But it really looks daunting, but it is not. And as I said, it is not for the beginner, it is for the intermediate… And I mentioned it also in the disclaimer, but people don’t look at the disclaimer at the top…

[laughs] That’s because we all just scroll right down to the shiny, colored version. You skip the words and you go right to the pictures, don’t we?

Yeah. So I need to find a better way to highlight there in the roadmap also, that it is not for the beginners. If you’re a beginner, do this, this, this.

Right. So one thing that you have is that you can break off into your particular path - whether you wanna be a frontend developer, backend developer, and then you can break off into DevOps from there… But you have a section which is the introduction section, which is stuff that everybody should know. And in here you have things like version control, which at this point in time is basically Git, and then GitHub as an addendum to that.

Yes.

Basic terminal usage, data structures and algorithms, licensing, SSH, design patterns… Okay, I can see where you can get overloaded relatively quickly. Now, I learned software development back in yesteryear, in the days of your, when a lot of this stuff didn’t really matter back then. I didn’t think once about licensing, I didn’t know what semantic versioning was… SSH was a thing I learned pretty early on, but version control came much later. I knew I needed it by the time I picked it up, because I was too busy having file1_copy0, copy2 etc.

Same for me…

I eventually picked it up, but… Do you think that perhaps this shared knowledge that everybody kind of has to know about is one of the things that overwhelms people? …whether they’re just getting started or they’ve been coding for a little time, and they’re wondering “When do I really need to learn Git? When do I need to completely understand open source licenses?” It feels like some of these aren’t necessarily required, but you just pick them up over time. Is that a fair assessment?

Yeah, I agree with that stuff. For example, if I tell you also about my past, for the first two years when I was starting - I started in 2013 when I was in university [unintelligible 00:15:41.25] and I learned about Git after two years in the industry. I learned about SSH after 2-3 years also. Design patterns I never touched, because in the beginning I would create a mess of the code, looking at design patterns.

[15:58] So most of this stuff I did not do in the beginning. As I said, I need to highlight that better in the paths. So this is merely the stuff that you pick up in the journey somehow, during the journey. So you don’t need to learn it in the hierarchical format.

As I said, if you look at the website, roadmap.sh, I did not mention all of this in the top. It’s just in that position here because I did not know where to put them, because there’s a common theme across all of these…

Yeah, shared knowledge.

But I agree with you, you don’t need to learn all of these in the beginning.

Alright, let’s dive into the frontend roadmap. You have it laid out, and if listeners are listening along and want to have a visual, check out roadmap.sh, and also the developer-roadmap repo on GitHub, which are both in our show notes… So you can see what we’re seeing as we discuss.

But step one - I like your step one, because I think a lot of people skip over this step… It is “Learn the internet.” Things like how does the whole internet work, and what are the protocols, what’s HTTP, how do browsers work, what’s DNS, what’s a domain name, what’s hosting - these things are really foundational to being a web developer, aren’t they?

Actually, I have been experimenting on my brother also. My younger brother has just started university, so he’s also learning a lot of this stuff… If you look in the first version – I have the version tags on the repository. If you look at the older version, I did not have all of this internet stuff. So I have been experimenting on him and seeing what are the issues that he has…

[laughs] Is he cool with that? You’re just running experiments on your brother… I hope he knows.

He’s fine with that, yeah.

[laughs] I’m just messing with you.

Now, if you look at the GitHub repository, I have the Release tab. It’s not on the website, actually…

Oh, okay. Yeah, three different releases…

Yeah.

And you used to not have the internet stuff upfront, huh?

Yes. And if you look at the first version – not this one; I think I added it here… Go back. The last one.

This 2017 version?

[20:14] Yeah, click – here is the link to the 2017 version. This one.

There you go.

So if you look, this was a super-basic one. You were just learning HTML, CSS, JavaScript.

Learn the basics - HTML, CSS and JavaScript, yeah.

So if you look, this is a bit not daunting as compared to the current one. The current one has a lot more stuff. But as I said, so he was having the issues, for example he didn’t know what the domain is, what the hosting is, and all of this, so I just put that upfront because when someone is learning, it is easier to get into theoretical stuff before you get into the practical, the hands-on coding stuff. So that’s why I put the internet and all the theory in the beginning. It’s not really much, so you can easily learn it in one day, or something. And then you can continue on to the hands-on coding stuff, with HTML and so on.

Yeah, absolutely. I think even more so than what is HTTP – maybe just like what it is, not necessarily how it works, is understanding DNS and understanding how a domain name such as Changelog.com, or roadmap.sh resolves into an address which can be located on the internet by a browser, and how that whole translation system works. I think it is empowering to understand all of that. It doesn’t take you very much time to pick that up. You could probably learn it in a couple of hours, and toy around with your command line tools, like dig, and whois, and understand that process, and really go from there.

I think knowing HTTP at like a deep level, like GETs, and POSTs, and PUTs, and DELETEs and all of that - probably not super-necessarily at this phase, but just understanding that’s the language that the clients and servers talk to each other when you request web pages and when you update web pages. It’s probably enough to just make it not so mystical. This is really about demystification at this point, because –

Yeah, so you don’t need to go deep down, because if you look at any of the items, such as DNS – DNS is also a lot of stuff. But I have just put it here so you know, if you open Google.com, what’s happening behind the scenes. What is the domain name - google.com; what’s the hosting, where is the website located, so that for example, when you build some website with HTML and CSS, you know where to put it, and so on.

And same for the HTTP. When you open something, you need to know how to look at the console; for example if some image is being loaded, how is it being loaded? If some CSS is being loaded, how is it being loaded? And this stuff is going to be used when you look at the HTML, and when you put the link tags, and so on. So that’s why just getting the basic idea of all of this in the beginning is going to be beneficial for later on.

Yeah. Very good. So then we go from here and you go to - okay, now it’s time for your three-layer cake: HTML, CSS and JavaScript, in that order. And I think I’m agreeing with you 100% that you have to build from the foundation, which is HTML. CSS is the look and feel, and then JavaScript is the interactivity… And it doesn’t really make sense to learn them – if you wanna be a frontender, there’s no reason to go straight to JavaScript. Maybe if you’re gonna be a backender, you’ll go straight to JavaScript. You don’t care about the HTML and CSS, but you wanna write backend JavaScript code. Frontender - learn these three, learn them in that order.

We can probably skip over, for the sake of our discussion, HTML and maybe go straight to CSS. You have kind of learn the basics, making layouts (floats, positioning, box model, CSS Grid etc) and I think that’s all good. I’m curious what your take is on the idea of somebody putting some rocket fuel on their CSS, or maybe kind of like skipping over, to a certain degree, with a framework… And saying “Well, I’m gonna pick up the framework and it’s gonna allow me to make some websites, even if I don’t totally understand exactly the way it’s working”, like a Tailwind or a Bootstrap, Bulma, whatever that your flavor happens to be… And actually start a little bit with the framework and learn CSS through framework usage. Do you think that’s wise, or do you think that’s foolhardy?

[24:12] I would not recommend that. When you look at, for example, Bootstrap or Tailwind or something, you easily get motivated; you look at beautiful pages and then you get motivated to learn that stuff. But I think it is going to be later on beneficial for you if you know the CSS properly.

If you look at the purple boxes, I say learn the basics, learn the layouts - so these are the items that I think you should learn beforehand, before you jump on to the frameworks… And you don’t really need to learn about animation, and CSS tree stuff, and all of this deep, deep stuff… Just get the basic idea, learn how to create the basic pages and then move on to maybe the frameworks. If you look at the CSS frameworks, I have put it fifth, sixth place maybe; it’s quite below there.

You have a way down there. After learning Git, after learning GitHub, and so on.

Yeah, because if you look at the job market, people really don’t ask about the CSS frameworks that much.

Sure.

They ask you more about the CSS stuff. So if you look at the job descriptions also, there’s not much about the CSS frameworks, and they’re not going to ask you much about that.

True.

They’re going to ask much more about CSS itself. So I think CSS is much more beneficial… And depending upon what the end goal is - if you want to build something of your own, you might go on and learn some framework in the beginning. But if you want to find a job somewhere, then I think it is beneficial to learn CSS good, and then move on to the next thing.

I think that’s 100% on point. A great distinction to draw is where are you trying to go with this? Are you trying to go from where you are right now to employable, or more employable? Or are you trying to go from where you are right now to launching your own web app or website? I think if you are just trying to put something into the world that you create, you could perhaps forgo some of the deeper knowledge with CSS and pick that up as need be. You’re basically taking on technical debt to get your product out faster, to put it in startup-y terms… And I think that’s probably a fair move.

But if your goal is hireabilty, like you said, the knowledge about Flexbox, and Grid, and these things are gonna be the kind of questions that hiring managers are gonna ask you if they’re hiring for a frontend position. They’re not gonna say “Do you have Tailwind’s classics memorized?” for example. Well said.

One more thing. This roadmap gets popped up on Hacker News quite a lot, and every time I look at the comments, I get bashed for all of this… That you don’t need to learn CSS that much, you don’t need to learn JavaScript. Just move on to Bootstrap, or use React, and all. So this is my point - what is your end goal? If you want to be employable, then this stuff is going to be for that. If you wanna just build some stuff, you don’t need to learn half of the items that are listed, and all of those roadmap items.

Yeah. Well, there’s not very much nuance on Hacker News. There’s a lot of Caps Lock writing… But I think that conversations like these help to tease out the nuance. And one of the situations that we’re in culturally is that there’s a fine line between somebody who’s an entrepreneur/startup/freelancer, and a full-time web developer employee… Because you can toggle back and forth between those quite often. In fact, when you can’t find a job, everyone’s a freelancer, right? Like “Hey, I’m freelancing. Hey, I’ve got my own thing I’m doing.” So you get into that “Ship it” mindset, the productivity/technical debt mindset, because you are trying to get something out there and show what you can build… And a framework is absolutely gonna give you a shortcut to that.

Agreed, yeah.

But then when you go to the point of hiring and interviewing and working full-time for a company, they aren’t interested necessarily in specific CSS frameworks, they’re interested in what you know, what you can build… And you kind of toggle back and forth, so it’s an interesting dichotomy.

Okay, so moving on from that… Then we come into JavaScript, and this is like – you know, the cake gets bigger; it’s like top-heavy, right? The base foundation - yeah, there’s stuff to learn with HTML, but it’s pretty straightforward. You can have a cheatsheet of all the elements, when to use what, and you understand the sideways tree structure… It’s there, but it’s not much. And the CSS is more, but then when you get into the land of JavaScript - holy cow. It’s a whole new world of complexity and choices…

[28:17] Yeah, so JavaScript - I agree, there’s a lot of stuff that you can learn. I have mentioned a couple of items. If you look, there’s only 3-4 items there… So in my own opinion, I think you just need to learn all of this, and you don’t really need to go deep down, because that stuff you can learn while you are for example doing projects, or you’re learning about frameworks in JavaScript. You can go and learn all of that stuff while you’re doing that.

So you can just, for example, look at learning the basics, learn how to create the variable looks, and all of this stuff, get the idea about how to make the API calls, learn about the classes, and so on… And then you can move on to the next step.

So you don’t really need to master everything in JavaScript. Just get the idea about it. This will help you make the projects, and then you can move on and create projects, and then learn on the way.

Right. So a lot of this starts off as actually just programming ideas, right? Variables, control flow, what are functions, how do you call a function, how do you write a function. Basic syntax of JavaScript, basic constructs… And then you add to that. So if there’s four things that you say right away learn for JavaScript to get going, it’s the syntax and the basic constructs. It’s learn DOM manipulation, understand how JavaScript maps onto the HTML that’s inside of your browser, the document object model, and then how to change things inside of that by calling these functions.

Then you say learn the Fetch API, or Ajax… And then you say ES6+ and modular JavaScript. So you’re getting more JavaScript-specific as we go down… And then finally, just understanding some of these concepts like hoisting, event bubbling, scope - which is a generic programming concept, but how that applies inside of JavaScript… Prototypes, shadow DOM… Okay, we’re getting pretty complicated at that point. And Strict Mode, stuff like that.

So it’s really like “Get the foundations of programming, understand how those are laid out inside of JavaScript, learn about the DOM and how to fetch things, how to go and do Ajax calls.” And then you’re basically ready to move on from there. Is that what you’re saying?

Yes.

Okay.

Exactly.

There’s a lot to frontend here… So we’re about halfway down the frontend path… Are we halfway? I don’t know if we’re quite halfway. From there it’s version control…

Yes.

…just like the basics. So why would we learn version control at this phase?

Because now that you know about HTML, CSS and JavaScript, now you’re probably building some stuff. So you can make a simple web page or a simple project of your own… Now you can learn about Git, and GitHub, and now you can learn how to collaborate with other developers. So at this point you can make a full-fledged website, the frontend at least.

Yeah.

So at this point, I think it is beneficial to learn Git, so that you can work with others, and share your work with the public - for example, put it on GitHub and share it with your employer, and so on.

Yeah, start getting that public profile so that you can display to people what it is that you’ve created, and things that you’ve built. So do you think it’s fair to say at this point – so I’ve made it through understanding the basics of the internet, HTML and CSS, and I’ve got my foundations in JavaScript - of course, there’s tons more to it that I will learn over time… And I can collaborate, to a certain degree. Do you think I’m hireable probably at this point by somebody out there?

I think you’re hireable if you look at JavaScript. If you learn about HTML, CSS, JavaScript, you can easily get freelance jobs. There’s a lot of people looking for freelancers who can do that. But if you’re going to work for some company, I think after you learn version control, and GitHub, and Git, you should be easily hireable at a junior role at some company… Because I know a lot of people who are doing that. At my current company also we have a lot of developers who just know HTML, CSS and JavaScript and they are making the CSS pages, the frontend, the static pages.

[32:10] Then we move into what I would consider the heavy frontend world… Package managers, pre-processors, build tools, frameworks, web components and so on.

Yes.

I don’t necessarily think we should go every jot and tittle down this… Maybe skip down to the one that everybody talks about the most. We can skip build tools, because hey, there’s WebPack, hey, there’s a few other things…

Yeah, before we move on, I wanted to highlight the grey text, if you look at that…

Yes.

So we have a lot of grey text in there. I think this stuff is good to have, but you don’t necessarily need to know all of them while you are in that path. A lot of people think that you need to know this, but I think it is not clear enough, so you don’t need to learn all of that. This is just my personal opinion. It is good to have, and you can learn it anytime.

Right.

So they are not really that important.

It’s just like if you’ve found a treasure map to some hidden treasure, and there’s a legend on that map that describes what all these items and things look like. You’re never gonna find the treasure if you don’t read the legend and make sure what all those things mean. So if you scroll to the top of this roadmap, you’ll see that Kamran has put out a legend, where the grey mark said “You don’t have to do this in order.” The greyed out things he doesn’t actually recommend… And then the green checkmarks are alternatives.

So there are things on this list, that’s why it’s perhaps overwhelming when you just look at it. But as you start to read the details, there’s no reason to learn, if you’re doing CSS architecture, first of all, all of the architectures. I’m gonna memorize BEM, and how to do OO CSS, and SMACSS. Ten people on Earth have done that. But you might skip that one altogether and come back to it later. It’s good information, but not necessarily on your critical path to being a web developer. So, well said…

Yeah.

When it comes down to picking a framework, this is one that’s fraught with controversy, and opinions, and flame wars. So you have React.js as the happiest path, I think that is… Personal recommended path. Obviously, there’s other options as well. How do you come to these decisions?

It used to be Angular before… I think it is my personal opinion also, but if you look at the job market – if you look at the 2016-2017 version I used to have purple Angular and purple React.js, and Angular was having more priority than React, because I like Angular and I saw that it was booming, and it was getting higher and higher…

But if you look at the job market right now – I mean, all of these are great; Svelte is also getting flamed now, but I think React.js has more job market, it’s much simpler, and it’s easier to learn as compared to other frameworks. Also, if you look at the community, React has much more community than Angular and Vue.js. That’s why I think React.js is more recommended than the rest of the competitors.

Fair enough. Next up, Modern CSS. Explain this category and then some of the options here. You’ve got Styled Components, CSS Modules, so on and so forth [unintelligible 00:35:00.29] Glamorous, maybe.

Glamorous, yeah.

We’ve got a typo on that one.

Yeah, the s is missing. I’ve found a bug now. [laughter] So if you look at the modern way of writing the modern JavaScript apps, whether it is React.js, Angular or Vue.js - so we are not writing the CSS in the old ways, putting the CSS inside the link tag, and all of that. Now we have CSS in JS, and so on. So for that, I have mentioned the StyledComponents, or the CSS Modules. I need to highlight this bit in the 2021 version, because I think Emotion is also getting used a lot, and also there’s Chakra UI coming up also, and there’s Tailwind also… So I need to highlight this section on the CSS a little bit.

But yeah, if you look at the modern way of writing JavaScript apps, like the React.js and Angular or Vue or whatever, the modern CSS is a bit different from that. So I’ll have a separate section highlighting that you just need to know how to write that kind of CSS inside of the link tags.

Absolutely. So then you have Web Components, which is kind of an optional path…

Yeah.

[36:09] CSS frameworks - here’s where we bust open again, similar to JS frameworks; now we’re talking about CSS frameworks, and there’s lots of options there… How do you evaluate something to choose in this way? You gave the reason for React in terms of the JavaScript, but when it comes to CSS frameworks, what’s your criteria for selecting, or starting somewhere?

For CSS my personal criteria is just looking at the community and looking at the existing projects and are other people using it. I think when it comes to CSS frameworks, there’s no recommendation, no strict kind of my personal opinion on that. So whatever works for you, you can use that.

For example, I am currently using Chakra UI a lot. But before that, I’ve used Tailwind, I’ve used the React Step, and all… I mean, it depends on the project, and it depends upon the jobs that you’re applying for, for example; what the company is using. It doesn’t really matter what you use. But my personal preference right now is Chakra UI, because he’s my colleague [unintelligible 00:37:11.03] and he’s a good friend of mine also… And I think it really makes building the frontend applications really easy. It works kind of like Tailwind, but there’s a bit of different implementation, and so on.

Oh, you’re friends with him? We did a whole episode on Chakra; you’ve probably heard that one.

Yes, actually he’s my colleague. We’re working at the same company.

Oh, awesome. Tell him we said hi. I wasn’t on that show, but I was hanging around during the show. So I don’t think I’ve met him personally, but awesome guy, and very cool project, Chakra UI. We’ll link up the episode for that if you want to go back and hear the story.

Yeah, he’s a super-cool guy, and he’s putting too much effort into Chakra UI himself; I see him working on that, and that’s made me want to use it more in my future projects than anything else.

Yeah, that’s always a good reason. Like, “Hey, my friend built this, and he’s working really hard on it, so I like to use it.” There’s nothing wrong with that.

Once we get past here, we’re starting to get into some of the minutiae. A lot of optional stuff, a lot of “choose your own adventure” at that point. But testing, of course, is a critical path, I believe; I don’t know exactly where it fits in the timeline, but learning how to test is a critical skill for any developer, no matter if you’re frontend, backend, DevOps, whatever you are; testing, and automated testing specifically, not manual testing where you go click around things (because we all do that) is definitely something that needs to be on your roadmap somewhere.

Yeah. I’ve put it a little bit down below, because I did not really know where to put it… Because if you look at the other things compared with them, there are other things that have more priority than the testing itself. For example, if you need to learn React, you need to learn React first, before you know how to test it. So that’s why it’s a bit down… But it should definitely be above the Web Components, and whatever.

Yeah. I’m sure it’s tough to pick the exact order. And testing is a tough one, because it kind of is a broad brush. It kind of can slot into all of these different topics… But when you’re just getting started and you’re trying to lay a foundation, if you don’t know how to test, it can be a real blocker to actually learn your technologies. It’s like, “Do I have to test this as I go? I don’t even know the technology. How am I gonna test the technology?”

The nice thing about it is it’s a skillset and a mindset, really, that once you have it and you’ve learned it, usually a junior developer will learn it from a team or a senior engineer who’s already doing the practice and already has the test harness in place, and you can just kind of copy and paste a few tests, and change the values, so you can learn by example inside of a team.

Once you understand how to do automated testing – of course, it is contextual to the particular technology; how you go about doing unit tests versus integration tests is gonna change over time as well. Once you have that down, you can start to slot it in as you learn other things. But it is really tricky to tell somebody when they should learn how to write automated tests, because you’ve gotta know how to do the thing before you can learn how to test the thing, kind of.

[40:10] Yeah, it’s definitely an important thing. For me, honestly, I did not learn formally testing while I was applying for jobs. I definitely learned all of this while I was working at some company. Because this is not the stuff that is asked much. They definitely ask you what different types of testing there are, what the mocks are, all of this stuff, but they don’t ask you how to write this and that.

So definitely, you need to know about this, but once you’re hired, you can definitely look, as you said, look at the people who are writing the tests and learn from them. You can learn on the job also.

Was there anything that you learned, Kamran, where you learned it thinking “This is gonna get me hired. This is really gonna help me get hired”, and it ended up being completely not usable until later? Or it was like “Why did I even learn that? Because they never asked me about it” or “I have never used it.” Do you have any of those skills that you’ve just kind of wasted your time on when it came to getting hired?

Definitely. I have a lot of stuff in the roadmap that I know about, but I have never used them. For example Electron - I have used it in a couple of my own projects, but I’ve never used it…WebAssembly - I learned it, but I did not use it at all, anywhere. There’s definitely a lot of stuff.

I have a framework of my own that I use to pick up stuff, but you definitely need to know what this thing is, and when should you use it. You don’t need to learn and go deep down into the stuff, but you should know what the different items on the list are. For example, I’m working as an engineering manager, and whenever some project comes, I need to have an idea about something.

So definitely, you don’t need to learn all of this, but you need to know what this stuff is. You need to be very careful, especially if you’re beginning in the career, to not waste your time on picking up some random stuff because your friend said to you that it’s going to be really beneficial for you, but you did not use it, or whatever.

Yeah, fair enough. Anything else before we shift our focus to the backend on this? I know we’ve skipped over a bunch; we’re not trying to be comprehensive here. But is there anything else on the frontend roadmap that you think is worth mentioning before we change our focus?

Again, I would just say, pick HTML, CSS, JavaScript, then Git, and React. js, and learn maybe the testing. Those are the 4-5 items that you need to learn. So don’t look at the roadmap if you are overwhelmed by all of this. Just pick these 4-5 items and you’re good. Just start working on the projects, and do a lot of projects, and then you learn along the way. Most of the items listed here - you don’t even need to spend so much time on it; you can learn it while you’re building stuff.

For example, I have a section for npm [unintelligible 00:42:34.02] I have a section for a lot of different things that you don’t need to learn. You learn it while you’re building software.

So as we turn our focus to the backend, one thing that’s interesting right off the bat - it starts pretty much the same as the frontend roadmap. You start off with learning the internet, and learning basic frontend knowledge, and then going from there. Why did you start here, Kamran?

Yeah, so I think it’s the same thing - you need to learn about the internet because no matter if you are doing the frontend or the backend, you need to know how the internet is working, and the hosting, and what a domain name is, because in the end, you are building for the web, right? For the frontend or for the backend. So the internet is there; then the basic frontend knowledge - you see here, I did not mention really the items that you need to learn, because it is just a basic idea about the HTML, CSS and JavaScript… Because at some point you’re going to have to do the frontend also, to be able to work with your backend. So that’s why it is there, for the basic frontend knowledge you need to know.

Yeah.

Then I have OS and general knowledge. I need to change it to [unintelligible 00:44:26.10] I need to make it grey, actually. So you don’t really need to know about all of this stuff, but this is definitely–

Out of order, probably.

Yes. So you can learn it any time. For example, I don’t know also much about the basic networking concepts. I know the basics, but I really don’t know much deep into that.

Yeah.

Also, if you’re for example doing JavaScript, you don’t need to know about threads and concurrency, or whatever. So there’s a lot of different stuff here in the OS segment that you don’t really need to know in the beginning. This can come later also.

Yeah. Let me submit something to you… So I agree that these are all things to have general operating system knowledge, and really what you’re talking is kind of like how a server operates.

Yes.

So you can sort of back into that, or learn it over time, especially if you’re using platforms as a service, or you’re deploying to things that run functions for you, and things like that… But then are you really a backend developer? I don’t know, maybe you are. What you need to understand is client server interaction. You need to understand how the web works. It kind of fits into the internet and the basic knowledge. It’s like, what does the client-server relationship look like? And you have that in basic networking concepts; these are high-level categories, so I’m not sure where things fit in your mind… But I think when it comes to a backend, what are we doing? Well, we’re writing servers, effectively. We’re writing services. So understanding the client-server interactions, a little bit about networking, TCP/IP probably, definitely HTTP… I think a backender really needs to know HTTP very well, more so than a frontender needs to… And through that, over time, you’ll learn things like threads and concurrency, and stuff like that; POSIX basics etc.

But I think maybe simplifying this and moving those down to where those could be things later… But I’d say client-server interactions [unintelligible 00:46:23.21] might be something that really gives a backend developer a good foundation, right?

Yeah. So this is more of a dev-opsy kind of point; it’s more of a dev-ops related…

Oh, okay.

So this stuff you don’t need to know in the beginning.

Right.

The stuff that you were mentioning, about the client and the server - I think internet covers there a bit also…

Sure.

So yeah, that should be a little bit – like, way down, not a little bit.

Probably worth highlighting for a backender though, instead of “What is HTTP?” I think maybe that in depth. HTTP in depth, or something like that.

Yeah.

Well said. This goes into a DevOps thing eventually. But then we get down to what’s really interesting. Of course, you’re on JS Party, so we’ve already made our decision - the backend is JavaScript… No. Learn a language, right? So unlike in the browser -and maybe WebAssembly will change this - you’re basically writing JavaScript in the browser. Maybe you’re writing TypeScript, maybe you’re writing something that compiles to JavaScript… But we’re executing JavaScript in the browser, at least for now, until a lot of the WASM stuff really takes over and we can write whatever language we want and run it in the browser.

But on the backend - choice now. Massive amounts of choice. You do not need to run JavaScript on your backend, and so now it’s time to learn and pick a language.

Learn a language - so as I said earlier, in the beginning, this roadmap is more of a job-oriented. If you look at the Learn a Language section, for example I have highlighted JavaScript as my recommendation, because JavaScript definitely has more jobs than just the items that I have mentioned here… But definitely they are booming also. For example, Java has a lot of jobs, Go has a lot of jobs also…

JavaScript I have mentioned because JavaScript is easier for the people with the frontend knowledge, for example, or the people who already are getting into web development; they know JavaScript a little bit also, so it is easier for them to learn JavaScript. So in this section I just mentioned to learn the basics of programming with the language of your choice, whatever you picked.

[48:23] Yeah. So it’s very much context-dependent, right? There’s a lot of good languages on the backend. They all have pros and cons. I think the job market is a good way of gauging, like “Well, I’m just getting started. I don’t know how to pick the best language because I don’t know what the best language might look like. Why don’t you just tell me what’s the best language?” And when it comes to hiring - well, you just sort by most opportunity, right? And I agree with you, JavaScript is absolutely right there at the top, and it has the benefit of saving time… Because you’re already learning some frontend stuff, you’re already learning JavaScript, to a certain degree…

Let’s face it, a backend developer needs to know some frontend. And I’ll say it, a frontend developer needs to know some backend. They don’t need to be full-stack, they’re not gonna have all the knowledge about all the things, but you are more useful and more valuable and more productive as a developer if you understand the other side of the conversation that you’re having. And whether you’re on the client side or the server side, you need to know some of the other.

So most people writing backend - they know some JavaScript, right? You’ve picked up some JavaScript. So it’s nice not having to learn a whole other language, especially when it’s already highly in demand.

Yeah. And also, one thing that I recommend to people mostly is to go to, for example, Stack Overflow Careers. For example, if you’re targeting Germany, pick the location for Germany and look for the jobs. Sort by the skills. What is there most clear? You’ll see that it’s JavaScript, for example, or Go, or whatever. And pick from there.

Go to LinkedIn Jobs and look at the jobs of your target area. What is the skillset that is more in demand? And pick the language from there. If you’re not building your own project, it really depends on the job market.

Absolutely. That’s great advice. I’m wondering - can you do those over time as well? Because then you could see which ones are trending in up or down directions… Because you want your skills to be good now, but you want them to be in demand five years from now… And usually, if you get a slight curve one direction or the other, you can see “Well, there’s a lot, but it’s trending down” versus “It’s a lot, but it’s trending up.” Is there a way to get that out of the job boards, or any other source?

Yeah, for example Stack Overflow releases their survey also… For example The State of JS, or the Stack Overflow Survey, and all. I normally look there also. You can look at this stuff also and see where it is going. For example, GitHub also releases like [unintelligible 00:50:43.17] So you can look at all of these surveys that other companies are doing and then get the idea from there also.

Right. Another way you can do it is you can sort by the language that has the best podcast support. JavaScript has JS Party, there’s Syntax, there’s all these shows… Yeah, sort by then. And then also Go has GoTime, which is an awesome podcast… So like hey, maybe learn Go, because there’s an awesome podcast. I’m just now being silly, but… There you go; another way you can sort your languages.

So you’ve picked a language, you’ve learned the language… Core details about its runtime… Really diving deep, to a certain degree. Maybe not like you are expert-level, but proficient I think is the goal here. Proficient with this language.

Yeah.

And then it goes to - what. We have Git at this point, hosting, GitHub… I think you’re probably now hireable and you wanna get your profile out there? Is that what you’re thinking?

Yeah, so it’s the same like the frontend roadmap. As I mentioned, learn the basics, and then learn how to code with other people, and put your work out there. In the Learn a Language section it’s not about the databases, it’s not about anything. It’s just learn the langauge, learn how to program this, and learn how to for example make the API calls, and so on, and then the Git, so you can work with other people.

And if you go down, then I have the databases. That’s where things get interesting, where you learn how to make full-fledged applications…

[52:10] Yeah. So you have now databases, you have relational databases as the first step, with Postgres as your personal opinion; I share that opinion, so hey - team Postgres. But then it goes – there is the technologies, like Postgres, versus Maria, versus Microsoft, SQL, Oracle etc. but really what you want is the concepts at this point. You have to pick one to learn on. But the point is “How do I design a database? How do I run a database? How do I make queries? How do I put stuff in the database?” That’s foundational knowledge and transferable knowledge, and really what you’re after, regardless of which database you’re picking.

Yeah. Also, at this second what I meant to say is just learn how to do [unintelligible 00:52:52.17] and get the basics out of the way… Because this stuff about the performance and all - this is somewhere down below on the roadmap also. So here just learn how to do the CRUD operations. And this is transferable knowledge. For example, if you learn Postgres, you already know MySQL.

Pretty much.

I mean, doing the CRUD at least.

Right.

So yeah, that’s about it. Learn about that. And then for example if you look at the More About Databases section, I have mentioned most of the performance stuff, and the database schema design, and all of this and that.

Yeah, so one thing I’ve noticed as I’ve been in this industry for quite some time now, and have seen different people come up through different stacks and pick different technologies based on the community they’re in, or just what they’re exposed to, is that JavaScript backend developers do tend to get exposed to NoSQL databases, specifically MongoDB, sooner than relational databases. With other backends - I think with the Ruby community it’s kind of the other way around… And I’m curious what your history is with databases. Did you start on a relational in terms of learning, or did you start with a document database like Mongo and moved to relational? What was your experience?

I think picking the right tool for the right job is my mantra, kind of. I started with PHP in the beginning, so I did PHP a lot for 4-5 years… And I was using mainly MySQL with that. After that I tried PostgreSQL and I went with that; I used PostgreSQL for some time. Then I moved to JavaScript and started using MongoDB. So my history is kind of that…

I think PostgreSQL is booming. PostgreSQL has a lot of stuff that you can do with [unintelligible 00:54:32.19] So PostgreSQL is definitely my choice when you know about the schema and when you know what you’re going to store… But MongoDB - we are using heavily MongoDB also, because we have the third-party services, so we don’t really know about the schema that is going to be coming from there… So we went with MongoDB for some of the parts, and we went with Postgres for some of the internal applications where we knew what we are going to store and how the [unintelligible 00:55:00.26] is going to look like. So it really depends upon the use case.

So are these specific technologies that you’ll find on job boards similar to the way you would find things on the frontend? Is someone gonna say “Must have MongoDB skills”? I’m asking sincerely, because I don’t go through the job boards very often. Is Postgres on the list, or does it say like “Must know SQL”?

I think yeah, Postgres – it really doesn’t matter. It depends on the level, for example, you’re applying for. If you’re looking for software engineer, they mostly look for just SQL. But if you’re looking at senior software engineer, or principal software engineer, they look at the intricacies, like the deep down into Postgres - how it works, and how does it compare with MySQL for example, or when you should use it, when should you not use it, and so on.

Yeah. Fair enough. There’s a lot here about databases, and I think that’s fair… Because let’s face it, a lot of backend development is all about putting data in and getting data out of databases. That’s a lot of what it is, at the end of the day.

Definitely, yeah.

So the more that you can learn about how a database operates, and how you can interact with a database, and optimize that, you are going to be more valuable. And after databases it’s Learning About APIs. There’s a lot to talk about here as well.

[56:13] Yeah, so for the APIs I think most of the applications being built these days is just the APIs. For the past 3-4 years I have never done an application which was just an application rendering the HTML page from the backend itself. I mean, we do SSR and stuff, but this is also now built with APIs. So I think APIs are really important. Learning about the REST and JSON APIs, and the authentication, those kinds of mechanisms, is important. You just learn that, and there are different mechanisms; there’s gRPC, there’s SOAP, and so on. And how you write the APIs.

I would tend to agree. Where does GraphQL fit into this? Because it is trending in the upward direction.

GraphQL – so if you look at the job market, I don’t think it is as much in demand as the RESTful API, for example.

A hundred percent agree with you. I’m just wondering where it is. Is it on there somewhere?

It is way down, I think.

Way down. Oh, there it is. Way down.

Yeah.

Alright. I probably would at least include it in this list… Maybe it’s not your opinionated one, but… If you asked me what are the common types of server-side APIs today, I would say in this order REST-based JSON APIs. Then I would say probably gRPC. Then GraphQL. And SOAP is just like legacy at this point. I’m not saying that you have to learn all of those, I’m just saying it’s in the zeitgeist, and I think it’s going to be on more and more job boards as time goes on.

You’re right, yeah.

Anyways, that’s a nitpick.

As I said, this popped up into my mind later on when I was building this roadmap, and making this [unintelligible 00:57:49.11] is a bit difficult…

Oh, totally.

Because it’s not a tool for the roadmap. So I just put it there, because it’s not a recommended option, so…

Like I said, just a nitpick, just curious what your thought pattern is on that.

No, I’ve been working on the restructuring a little bit of this roadmap, so there’s definitely things that are going to be up and down in the next coming weeks.

Sure. And it’s worth noting - this is a roadmap made by Kamran, friends and contributors, that is a roadmap. It’s not the only way to do it, it’s not the 100% correct way to do it. This is like one guy’s advice on what could be a great way of going about things, so take it with that in mind.

Yeah. And it’s highly opinionated.

Right.

You might have a different point of view than mine. So it’s just me giving my thoughts and my idea of what the backend development or the frontend development is, or whatever.

Right. Alright, so the API is a huge thing to learn about; of course, you’re gonna be creating APIs, so you have to know what one is and how they work in order to build them as a backender, so that’s definitely there.

Caching, I think, well-placed. Right next to web security knowledge. After you learn about APIs, caching is a huge aspect of backend development, and one of the trickiest things to get right… Specifically cache expiration is a lifelong pain for me, and for many people.

Likewise.

Yeah. So when you say pick up caching, you have a bunch of just technologies listed. I think most people are probably understanding CDNs to a certain degree, because that’s about as outsourced as your caching can get… And then move into application-level caching with something like a Memcached or a Redis.

Yeah. So by client-side I meant the HTTP caching; knowing about the HTTP headers, and so on. For example, cache control and all these headers that you can use to set up the content that gets cached in the browser, or the proxies… And the server-side caching - there’s mainly Redis and Memached, I believe, and Redis is the one that is most commonly used. Every app that I have worked with has Redis, and every job board that I’ve come across has Redis. So Redis is quite common for that, so you should pick up that also.

[01:00:00.13] Yeah. And first and foremost understanding why and when to cache; like what’s its purpose, when would you do it, when would you maybe not do it, the pitfalls of caching… These are things that are all good to know… Right there next to security knowledge.

Now, security to me falls into the same category as testing, where it’s like “Where does it fit in?” Because it’s kind of one of these things that you wanna have interspersed into all the things that you’re doing, versus adding it at the end, so to speak… Just like performance, “Oh, we’ll make it faster later.” That doesn’t always work, because you design the system in a way that’s antithetical to performance. We can really shoot ourselves in the foot if we don’t have any security knowledge at all, but again, where exactly does it go in your roadmap? We have it here next to caching and right before testing. And it’s there; you’ve gotta learn certain things.

Yeah, I think security should be also a little bit up, because there’s some stuff that you need to know about when you’re learning about, for example, databases, like OWASP, and SQL injection and all that stuff; you need to know about that. And also, when you are dealing with the API, you need to know for example about the SQL injection and all this stuff [unintelligible 01:01:04.26] So it should be a little bit up also… But definitely, it is one of the most important things that you should know about when you are working with the backend.

Absolutely. It’s also a place where you can rely heavily upon established norms, established libraries, production-grade and hardened frameworks… For example if you’re using a backend framework to build your APIs and you’re relying upon an open source, highly-used ORM or datamap or library, that thing will be built in such a way that it’s very difficult - or sometimes impossible with certain ones - to actually code in such a way that you can have a SQL injection. Because a bunch of people have been using this and working on it together, they’ll make it darn near impossible for you to write SQL-injectible code in your backend, and that’s a huge boon to you, especially when you don’t even know what it is.

It’s a place where you need to know these things, but if you are not straining too far from common ground, a lot of times you’re protected by the community of developers around you, which is nice.

Definitely, yeah.

Testing, CI/CD… We’re getting down into things beyond testing; we get to where it’s kind of choose what interests you, choose what to learn next. We’re already hireable at this point, but testing, just like in the frontend, I think it kind of spans a lot of these concerns.

Yeah. And I think for backend testing it’s way more important… I mean, definitely for frontend it’s also important, but for backend, because there’s a lot of business logic involved, and there’s a lot of the business rules, and such… So definitely the testing is really, really important, for the backend especially.

Now, at first I give pause when I hear that, but let me agree with you… And this is why - your frontend needs to be tested to ensure that it works according to the specified way it should work, correct?

Yeah.

Your backend needs to be tested for data consistency and protection concerns… Because you cannot trust your frontend anyways. If your frontend is compromised, you cannot trust it. So test all you want, you may not be executing your frontend. At the end of the day, I can pop up my browser and change your request and do all these things in your frontend; so your frontend is not a trusted piece of code. It’s your code, and it should work as it’s supposed to work, which is why you test it, but it’s not internal. It’s external.

Your backend is internal and private, and its job is to ensure that things work the way that they need to work, and that data doesn’t leak, and that all these things kind of happen, and you can’t trust your frontend… But you have to trust your backend to a certain degree, so testing is paramount there. Never ever trust your frontend, regardless of how well-tested it is.

So at first I was like, it’s more important when you said it; I was like “Are you sure?” And then I thought like, “Yeah, actually it is more important there, even though it’s important on both sides.”

[01:04:01.09] Yeah, it’s important on both sides. With the API and all of this - definitely, as you said; there can be different clients, you can look at the browser and look at the console and get that request and send whatever you want. But definitely it is really important from the backend also.

Very true, very true. And from there, we get into design and development principles, architectural patterns… We’re starting to get pretty esoteric at this point. We’re moving beyond merely hireable, to like pretty smart and useful… [laughs] I don’t know how you rank these things, but… Design patterns. Good ways of writing software, microservices etc. The difference between monoliths, microservices, and it kind of goes from there.

I think our field is getting broken down into multiple subfields, and so on. When I started, for example, there were just web developers. You were doing frontend, you were doing backend, you were doing everything. And then you got, for example, the frontend separately, the backend separately, then you got the DevOps separately…

I think this stuff also here, [unintelligible 01:04:57.15] different people specializing into this item that is listed here also… But I think for backend developers it’s still beneficial to know a lot of this stuff, because when you are a backend developer, you are architecting also. Not many companies have the architects as a separate role, that is going to help with the architecture of the application, and so on.

So when it comes to specializations, what do you think is popular ones, or in-demand specializations? You list out search engines… I think specific technologies like that, like “Can you do full-text search?” and stuff like that becomes important. What else?

What I have seen is there’s only frontend, backend and DevOps. That’s it. But mostly in bigger, bigger corporations you have the architects, who are doing a separate job. But in 90% of the companies, as a backend developer, you are going to be doing a lot of this stuff. So it is better to know about all of this. Unless you are working for some big corp, you don’t need to be a specialist, but you need to know all of this stuff as a backend developer.

Fair enough. Lots more there. We’re not gonna cover this one comprehensively either, but the very last bullet point - I should also mention that there’s a whole DevOps roadmap that we’re not talking through today, but it’s part of this… And so check that one out as well, if that’s something that interests you. But yeah, Keep Learning at the very end, and of course, one of the things in this industry is you should always be learning. If you’re not moving forward in your knowledge, you’re actually moving backwards.

Sometimes you can be moving forward and moving backwards by selecting a technology that’s gonna be obsolete here soon… Hey, that’s part of the game. But not only is there lots to learn here, but there’s lots to learn that isn’t here, and there’s depth into each one of these rectangles here. You can go a certain depth into graph databases, a certain depth into web sockets, a certain depth into message brokers and RabbitMQ. So don’t stay stagnant, don’t think that when you get to the end of the developer roadmap you finish the game and you can just collect your trophy and your high salary and be done. It actually doesn’t ever end, which is one of the reasons that you should be serious and committed if you go into this industry… Because unlike maybe a civil engineering degree, where you go to school for 4-6 years, get your degree - I’m now generalizing and assuming - you pretty much know everything you have to know from then on out… Your knowledge is gonna have a half life in software development; it’s way faster than other areas. So if you’re not somebody who wants to keep learning forever and ever until they retire, then maybe not the place for you.

Exactly, yeah.

Anything else on the backend roadmap, or on roadmaps in general, or anything else before we call it a show?

Yeah, for the backend roadmap I will again summarize that if you are a beginner, if you are trying to get into the backend development, ignore the roadmap; just pick for example a language, learn how to use the SQL queries, for example learn how to build a CRUD application, and that’s it; you’re done with the backend. Then you can keep learning a lot of this while you are building projects, and maybe learn about APIs, and so on.

Again, as you mentioned, take it with a grain of salt. You don’t need to look at my recommendations; look at what your job market looks like, what the companies are using, and then pick up whatever you want to pick. Also, it is really important to know when to use what. For example, I have mentioned PostgreSQL, I have mentioned MySQL… You need to know how are they different, in what cases you have MySQL which is better than PostgreSQL, or why PostgreSQL is better than MySQL, and so on.

There’s lots to do. Get out there and learn, everybody. The website is roadmap.sh. The GitHub repo is too long, but I’ll link it in the show notes, so you can go there, star the repo. Go to roadmap.sh. There’s a YouTube channel upcoming, you can subscribe for updates… What else, Kamran, with regard to this project? Is there room to get involved, and give your opinons and help form the roadmap for future generations?

Yeah, so people can go and open issues on the repository and suggest whatever thing can be improved, or whatever… And later on I’m going to be working on improving the website. I am working already on the redesigning of the website. It is going to be interactive, it is going to have resources on each of the [unintelligible 01:09:04.28] that are mentioned there… So if you have any suggestions or if you have any recommendations, feel free to shoot me an email or open the issue on the repository, and I’m looking forward to the contributions.

Awesome. Very cool. We appreciate you coming on JS Party. Thanks for listening, everybody. We’ll talk to you again next time.