Yup. Been doing this since 1999.
The whole "front end"/"back end" thing is an incredibly unrealistic and unnecessary division. Real life work is much more complicated and nuanced than that. I don't know of anyone, maybe outside of (as you said) huge companies, who works that way, having "picked a path" and entirely focusing on one side of the stack. Even if you are a "front end" developer, you are going to need at least passing familiarity with the other side, and vice versa.
Right now, I have back end code open in one split, front end JS in another, HTML in another, an ORM model for reference, and Paw with some API calls. All of these things go together, and I would have a hard time understanding any single part without being familiar with the others.
After you've been doing this for a few years you realize that code is code, whether it's running on a server, or in a browser, or on a desktop or mobile device. It's just code. Once you understand how to "think" like a developer (which in my experience is the biggest hurdle people face), the differences between any of them aren't nearly as large as they seem, and almost all of those things in that graphic are just abstractions over code.
Ever since server side javascript turned serious with node.js and "full stack developer" became a thing I have been stupefied by this. The concerns are almost orthogonal: front end gets some data which needs to be presented in a browser. Chief concerns are proper placement and appearance. Back end needs to persist data and retrieve data at speed. They absolutely have nothing to do with each other. How is this an "unnecessary division"?
Well, one is client development and the other is server application development.
Pretty big differences there even though there may be some overlap, like the server being able to render HTML which is a unique feature of web clients. I'd cluster "web client development" with iOS and Android development, not with server application development.
Too many people dump on front-end development without realizing that client development isn't easy on any platform, and they all require credentialization in apis or design patterns with major warts.
Except, it's not "just code". Front-end/back-end/ops, whatever, all have vastly different contexts. Hence the separate learning paths. You should know all three, but that doesn't mean you have to learn them at the same time or the same pace. You people are taking this chart way too literally.
I said nothing about want to. Want to and capable of are two different things. If somebody wants to just be a back end dev (or front end, or iOS, or...), by all means, go right ahead. I won't stop them. I don't want to do Android development, but I could if I needed to (after some spin-up time).
But I disagree with the idea that they are so wildly divergent that no mere mortal can grasp them. People in this thread are really selling themselves short with their knowledge, which is more transferable than they realize.
> Certainly, if and when you are ‘full stack’ you can and may do both.....but that implies both exist to begin with.
Not too long ago, both didn't exist and everyone was a web developer. And before that we were just programmers. It's a fairly recent idea.
At a smaller companies go for breadth; there's only a few of you. Larger companies prefer depth - but! at larger companies there can be more projects for you to have your fingers in.
Depending on specialisation, work can be rare but more rewarding - but you can also paint yourself into a corner with things moving out of vogue. Silverlight/flash, Ruby, VB, etc.
I've been at it since the 90s. I'm a generalist, mastered a few areas, and worked in. It gives me choices - I where to go for a web-based job, I'd call myself a web developer and not boast no much about my C knowledge.
At my current job, most the skills I provide aren't necessarily rare, but the combination of them is - where it could take 2+ people to replace me (excluding productivity).
The balance is to specialise enough in a few areas, but not be a "jack of all trades; master of none"
Like I said above, code is code. Code is just syntactic sugar around concepts, and concepts transcend languages and environments. Understand the concepts and you can pretty easily jump around just about any programming environment, from front end to back end to desktop to mobile.
It's kinda weird to me how many people think these things are so different when really they're not. Yes, every language will have its quirks and every context will have domain specific knowledge and tooling. But they are more similar than they are different, and once you grok the similarities, the differences become easy to recognize.
I've seen so many things (languages, toolkits, environments, etc) come and go over the years that I refuse to be pigeonholed into one specialty because they always change, often without warning. Ask a Flash developer how they feel about that today - in one day (the day the iPhone was released) that whole industry collapsed. The great thing about being a generalist is that you can move on, jump in and do the work that needs to be done, no matter what that work is or where it is.
Every so often something genuinely new will come along, that requires some learning and understanding. The container ecosystem are a good fairly recent example of that. But as a generalist, it doesn't look hard or magical to you because it's just something you haven't learned yet. You're prepared for that and you have the understanding to know what you need to know. You also know your limits, and the things that do (or don't) interest you and can adjust the arc of your career appropriately.
I routinely work back and forth between front and backend every day. That is a normal day for me, I love it and and I would not change it. Occasionally I'll lend a hand on an iOS app (that we're about to migrate to React Native as it happens) and maintain some internal Mac apps as well as writing my own Mac apps for fun. I've also run a side consulting business for several years to keep my skills fresh where I tackle everything from DevOps/server maintenance/cloud migrations to frontend/backend to desktop and mobile development. Basically whatever itch I'm feeling at the time.
Concepts translate pretty easily and, where they are different, as a generalist you accumulate enough experience to know what those differences are. And if companies want to divide their jobs into "front end" and "back end," that's fine, because you have the knowledge to apply for either. :)
A lot of people in this thread are really selling themselves short. They know more than they realize and the "other side" of the stack is not some mysterious magic that requires years of intense specialization. It's just programming. Same thing we've all been doing for years.
"Specialization is for insects." - Heinlein
'There is so many things to learn I started with Python but there is this and this and that'
A language is just a language, the principles and your ability to translate problems to code is what is making you a programmer.
But will you see this comment given that you don't get notifications?
If you only have 3 developers, it doesn't make much sense to have one backend, one frontend, and one dev-ops. Are you always going to have exactly equal amounts of work for all three to do each day?
But apart from that, it also seems so much easier to divide up work by feature without stepping on anyone's toes. Like, you code search, I'll code chat. Not you code search backend, I'll code search frontend. That increases overhead and coordination.
And then, if your frontend is heavy on JavaScript, there's often a lot of similar code between frontend and backend. Validation is a classic example. A more extreme example might be a browser game using WebSockets and lockstep simulation. The browser and server might share most of their code. It would be absurd to split all the developers into frontend and backend in this case.
Generalist or polyglot developer still doesn't fully capture the broad scope of knowledge you can call on beyond cutting code and may have lost any of its negative connotations over the last 23 years.
e.g. webpack, I ended up getting it setup because 90% of the tutorials out there use it. Same thing for NPM scripts, use NPM, you figure out 'npm run' pretty quick. It isn't learned per se, it is just sort of acquired.
Same thing for eslint, most tutorials start off with "ok now install eslint and use these rules"
If you use react, you'll learn redux or mobx because that is what all the tutorials teach you to use. It'll just happen, and maybe after a month or so of use (or some independent research), the new developer will understand the code they are using.
Learning a test framework, hopefully, comes naturally after the code base grows large enough that a quick manual pass through no longer suffices.
I think going out and purposefully learning these technologies one by one is sort of silly, thinks make a lot more sense in situ. Go build something, after it is mostly done, figure out what gaps in knowledge exist, fill those gaps in.
Yeah sure, I know a bunch of stuff on that list. SemVer? Yeah, I get what the numbers mean. I google the ^x.x.x syntax, whatever.
ESLint, Prettier, yep, install and drop a .config file somewhere. Copy someone else’s. It’s hardly rocket science.
Webpack, I know that it exists and as soon as the defaults installed by create-react-app break, I’ll figure it out.
This is a big list but let’s not pretend that you need to be an expert in any great amount of it to get something made. And the purpose is right there at the top:
“The purpose of these roadmaps is to give you an idea about the landscape and to guide you if you are confused about what to learn next and not to encourage you to pick what is hip and trendy.”
I think it does that pretty well. Settle down a bit, everyone.
If you want to know what to learn, learn web fundamentals. Learn the Web APIs and everything that's been standardized in HTML, CSS and JS. Learn relational databases. Etc. Learn how to build your graphics using SVG. Learn how to do your animations with CSS. Hell, if that's too boring learn WebGL and WebAssembly. They may not be ready, tested or in vogue, but they'll be here for the long haul. Screw libraries that abstract over this stuff. If you don't learn from the ground up you're putting your future career in the hands of things that may end up being ephemeral. Stuff like React, Sass, D3 etc might seem like safe bets, but so did jQuery at one stage.
Just, be aware that your goals as a developer are sometimes at odds with the goals of your employer or even the community as a whole. There's a lot of pressure to get up to speed and be productive as quick as possible. You can see this in things like the React docs, which encourage you to ignore language features and just memorise patterns.
But I want to get stuff made. I have ideas, I have a thing I want to make. Would I like to really deeply properly fundamentally understand JavaScript? Sure! Do I have time, with my actual real job and friends and life and other hobbies? Nope. Thank goodness, then, for React. It's a godsend.
(Also, I have no desire to "work" as a developer for someone else as my salaried job. Perhaps that affects my outlook.)
My usual measuring stick is "if this thing disappeared tomorrow, would I be able to recreate it from scratch myself with no documentation?" (obviously not up to the same performance standards).
It's still a long way off disappearing and in many high security environments might be the only approved library.
I think it could be intimidating for a beginner to think, "Damn, I've gotta learn all these things" and you totally, totally don't. But as you work in this space for a while, you'll encounter a lot of this, and the more you learn about the different pieces, the better code you'll write everywhere.
And heck, a depressing number likely don't even use version control.
The picture of what's 'normal' in this field (via blogs, Reddit, Hacker News, etc) is as distorted as a picture of what a 'normal' life would be like is on social media sites.
If you're at a tech savvy startup or planning to get started as a web developer in Silicon Valley, you'll probably want to know a decent amount of what's on this list. If you're outside of that situation or working contract/freelance/whatever, then you'll only need to know about 50% or so of it.
It's useful to learn about these things but never lose sight of the big picture. Frameworks, tools, languages, trends, all go in and out of fashion very quickly, for various reasons. On the other hand, practices, patterns, soft skills and a good understanding of how things really work will be valuable for an entire career.
Put your energy into understanding which problems are being solved by the above things, not into becoming masters of any particular set of tools. You'll still be very good at those tools because you'll know the role they play and what to expect from them.
I couldn't set up webpack for a project if my life depended on it. To be fair, I spend a lot more time doing back end development.
But even for the back end development pathway, I don't know anything about web sockets, GraphQL, message brokers, ElasticSearch et al, NoSQL, or caching with Memcached/Redis.
It's not that I couldn't learn how to use all of the above, but rather that it's just something I don't have to use at my job. Most employers don't/shouldn't require you to know these things in order to get a job, they are skills you can learn on the job.
The ability to learn is the most important skill an employee can have. The rest is just decoration.
Nobody "needs" anything, so it's not a fair standard to set.
I'd say if you're a developer and you don't know about something on this list, you should probably learn about it. Master? Nah. Know what it is/means? Yeah.
Btw that is some sweet looking graphs, but I think they would be even nicer if they where SVG instead of binary png's.
> If your stack...so complicated that you simply have no ability to understand ... and how to deploy it easily
You are correct. That said I don't share your reaction at all.
You don't need to understand all of these things to understand how one stack is built, or how to deploy, but you DO need to start understanding these things when it comes to making decisions.
I mean, look at the list. Sure, you don't need to know Bootstrap, BEM, etc to work on a website. But if you're a webdev, soon you should know what Bootstrap is, and a few of the competitors. You should understand what the pros/cons are. If your shop uses BEM, that's all you need to know...but once you're no longer new and are starting to make decisions, you need to understand WHY BEM is the way it is, that it's basically trying to NOT cascade, and thus why random CSS advice you read may or may not apply. (and then begin to decide what BEM is good/not good at, and what the alternatives are).
Continue this for discussion for more than 30 seconds and you enter into territory where any realistic human has a path. I've been full stack, backend, frontend...but I always have a "current" path, because that defines what I'm keeping up with, because I can't keep up with it all. So yeah, you have to choose a path, by definition of human limitations. If you don't choose one consciously, you're still choosing one.
Starting webdev? Understand the very very basics of HTTP, add HTML, and realistically add CSS. Read/Write from DOM with JS. Add some templating framework on the backend or frontend. CSS preprocessors show up quick if you're doing anything of any real size or complexity. Front end quickly hits bundlers and transpilers and minifiers...After a year in the biz the list gets pretty long. 5 years? 10 years? 20 years?
The list of topics I can barely mumble about is huge, but that still leaves a big list of items. OAuth? OIDC? Web Services? CORS? SOP? cookies, localstorage? IndexedDB? The field is vast and any individual may only cut one path through each roadmap, how do you know what path is appropriate? Someone might have a path on any number of the roadmaps listed, or just one: They appear to just be a separation between domains, not a declaration that you must have only one (and they're pretty fair IMNSHO - You can definitely focus on just one roadmap fairly naturally).
Where do you feel you must "choose a path"? Why do have such "deep resentment" when I don't see that being said at all? This just shows the topics at different scopes of knowledge, separated by domains that may or may not apply to you, but are natural domain boundaries anyway.
Your response has merit but it would be better if you assumed good faith. Even if you don't understand their thinking.
>I was convinced for a while there as I scrolled down that this was a joke. "Good parody!" I thought to myself. Then I realized to my horror this is actually serious.
...is pompous and holier than thou. Being unable to see the value in this infographic doesn't mean it's trash, and I think it's unnecessary to comment with such an arrogant attitude like that, especially when it's obvious they're just either not the intended audience or they're misinterpreting the goal of the graphic.
That's not a good faith interpretation.
Many of us share a general lighthearted humor about the state of the industry: Becoming a developer in some fields is less about engineering and more about "piecing things together."
Nobody's looking down on anyone. This is often something we joke about because we find ourselves piecing things together, too, almost to a point of silliness. It's not a rip at anyone sharing information, more like a jarring reality check.
But is it obvious? I'm sure others resonate with that.
You have to consider the possibility that his criticism is entirely valid and that a non-zero number of people find this roadmap way more convoluted than it ought to be.
As a web developer since 1997, currently working in both the Rails & JAMstack spaces, I can assure any and all beginners out there you don't need to know anything about at least 50% of this stuff, probably closer to 70%.
I also deeply resent the notion that you have to "choose a path." Depending on the task at hand and what I'm trying to accomplish, I'm working on the backend, the frontend, and/or the devops side. I jump between all of those daily. If your stack, website, or web app is so complicated that you simply have no ability to understand how it's built bottom-to-top, back-to-front, and how to deploy it easily, then either (a) you're in a massive team at a gigantic software company, or (b) you're doing it wrong!