Would love to see a roadmap added for embedded development or system level programming etc. There is a huge emphasis on "the web" when it comes to software engineering, that people forget (especially college students figuring out a career path), that there are many jobs in defence, hardware companies, etc. that develop software without using any web technologies at all.
colechristensen 1612 days ago [-]
I could condense that down to a single task that will get you 90% of the way there: Learn how to bit-bang a serial interface on two different microcontroller platforms.
cossray 1612 days ago [-]
Claiming a serial interface task will equip you with 90% of Embedded Systems is the biggest disrespect of a profession I've ever encountered. To outsiders, the field might be regarded to be just a microcontroller playground. But the spectrum of hardware design and programming in the field is at an unprecedented levels. PCB design, power supply, SoCs, SBCs, FPGAs, peripheral interfaces, Embedded C and Linux software development...to mention but a few; are some of the skills a modern embedded system engineer needs at the lower level.
tonyarkles 1612 days ago [-]
Well, yes and no. Depends a lot on whether you want to do the "full stack" or not there. Lots of bigger companies have EEs to do the PCB, power supply, pinmux, etc stuff, and then embedded software people to write the code that runs on it. An embedded software developer probably should be comfortable using an oscilloscope/logic analyzer in a pinch, but all of the hardware design tasks aren't necessarily required for doing embedded software work.
I say this all as a "full stack" embedded guy. I'd love to have someone else take on part of it, but I'm a solo consultant right now :). Did both EE and CS in school, and more than happy to do whole projects end-to-end, but I also don't expect EEs to be fantastic programmers, or embedded software people to be fantastic hardware designers.
stmL 1612 days ago [-]
I interpreted the parent comment as do all of the parts yourself. Pick microcontrollers, design the PCB with power supply, find the right toolchain for both microcontrollers and implement serial communication. Which is almost 90% percent of the job.
Also, does FPGA come to mind when embedded is mentioned? I always assume that FPGA is a whole another subject (only FPGA not the board part).
non-entity 1611 days ago [-]
> always assume that FPGA is a whole another subject
This has been my assumption as well. I looked a while back at learning FPGA development because it seemed rather interesting, but quickly decided to go another route after seeing and talking to some FPGA guys. From what I saw it does not in any way resemble what I'm used to as a software developer
colechristensen 1612 days ago [-]
This is an overreaction, and really not a very nice way to interact with people.
I was talking about embedded development which doesn't really have anything to do with PCB design, power, FPGA, etc. You don't need those things to be a programmer working on embedded systems or microcontrollers.
Implementing a serial interface in software flipping GPIOs up and down will expose you to a whole lot of the necessary ecosystem and if you can do it, you're well past the point where you should be able to get paid to do it and the point where you need a roadmap to tell you where to expand your skills. I didn't say doing it would get you a senior level position or a masters degree in EE.
abhishekjha 1612 days ago [-]
What exactly qualifies as a web technology? Isn't anything on an IP address a web technology?
TorbjornLunde 1612 days ago [-]
Web != internet.
HTTP, HTML, CSS, JavaScript, etc are web technologies.
TCP/IP (among other things) are internet technologies.
Web tech builds upon internet tech.
Thorentis 1612 days ago [-]
Yeah, in my OP I was meaning the WWW specifically, so the things developed for use with the WWW (HTML, CSS, HTTP, etc.) Networking (TCP/IP, UDP, etc.) are not WWW specific.
Now having said that, sure I've seen some defence projects that make use of HTTP or have internal "web"sites for managing interfaces. It's even a trend for embedded hardware to have web management interfaces (your internet router/modem is a great example).
But when I say "web", of course I was really meaning user-facing/world facing websites. That seems to be the implication behind "front end developer". Not "I make front ends for building automation systems" but "I make front ends for websites hosted on the WWW". Requires a slightly different set of knowledge imo. One is tailored for looks and UX, the other is a trade-off between minimalism, efficiency, and usability (if only this was applied more to the major sites you see on the WWW now!).
seangrogg 1612 days ago [-]
Semantics, but JavaScript itself is not a "web technology" - despite being conceived for the purpose of web scripting the original publication for version 1 even calls out that the language can be used on a variety of host environments (not limited to browsers). This can largely be seen in host environments like Node.js where it acts like any other similar language.
jolmg 1612 days ago [-]
By that logic, CSS is not a web technology because it can also be used in GUI toolkits like GTK[1]. HTML is used in ePUB files[2], so I guess it's not a web technology either...
Would protocols that use HTTP for transport like gRPC[3] mean that HTTP is not a web technology either? I don't know what is a web technology anymore...
Disagree. Electron apps are built w/ web tech regardless of how they're distributed or connected at runtime.
shantly 1612 days ago [-]
The assertion was that IP address = Web.
jolmg 1612 days ago [-]
IMAP, SMTP, FTP, NFS, IRC, and lots of other networking protocols use IP addresses but aren't web technologies.
ioquf 1612 days ago [-]
I am interested in this too. I am trying actually to start embedded development for a specific platform, but it's hard to understand where is a good starting point even as experienced software developer.
proverbialbunny 1612 days ago [-]
This is a generalized 2cents, but: Go around online looking for any and every job post you can find in that space. Tally up what is most common to what is least common. Bonus points for profiling into subgroups of common requirements.
As someone who has quite a bit of experience as a systems level engineer, who has written code for custom hardware, but is not a firmware engineer (in other words, grain of salt here): Knowing C (or C++) well enough to be able to write threaded code is super important, for not all but many jobs. (Or at least know the concepts, eg the different kinds of atomics.) Knowing I²C or similar is a good idea. Knowing or dipping your toes into DSP can be helpful. Know at least mean squared error, and how to do a bandpass. And bonus points (though very few people in the embedded space know it) is learn Rust. It will teach you good programming practices that most firmware engineers do not know. Many of them are stuck bug testing run time errors day in and day out, instead of letting the compiler do it for them. (Again, 2 cents on all of this. Best to get actual requirements from job posts.)
kamranahmed_se 1612 days ago [-]
Hey guys, I am the person behind this website. Please know that it is still in progress. I wanted the initial version out so it is just the "roadmap" images for now. However, I am working on making these roadmaps more accessible for the beginners and easier to contribute to. In the list of things planned for the coming week is the textual version for each with different sections (job-ready, intermediate, advanced, overall landscape, etc) and each of the steps are going to be clickable with resources to learn from.
The website and the content is opensource and can be found at https://github.com/kamranahmedse/roadmap.sh. Please feel free to contribute, drop your feedback, feature requests and issues there.
madiathomas 1612 days ago [-]
Instead of learning JavaScript frameworks, isn't it better to advise people to learn and master JavaScript itself? I feel learning HTTP, HTTPS, HTML, CSS, and JavaScript inside-out will benefit someone than to try to learn a framework that will disappear very soon. When you know undelying technologies, it is easier to learn new frameworks because they will always be based on underlying technologies.
brojonat 1612 days ago [-]
Learning a framework will enable more participation and contribution _now_. And arguably knowing the framework isn't so important compared to going through the _process_ of learning one; if you know how to do that then you can just latch onto the next up-and-coming framework. But yes, it's certainly also good to master JS itself.
BigJ1211 1612 days ago [-]
Angular/React/Vue are unlikely to dissappear they've existed for a long time now.
Angular: 3* years *9 if you count AngularJS
React: 6 years
Vue: 5 year
That's a long time by web standards, they also keep up and push native javascript forward.
So yes, learn native JS. Definitely learn a framework though, as those skills are ultimately what you need to work on anything more complex than a simple website.
madiathomas 1612 days ago [-]
5-10 years is too little considering the fact that they spent first 2-3 years gaining momentum. Even worse for Angular because it was completely changed along the way. JavaScript knowledge is still relevant even after 24 years. Whatever is on those libraries and frameworks will one day make its way into JavaScript and that will be theur end. Frameworks will come and go. Even the most successfull JavaScript library ever, jQuery, is on the decline because of newer frameworks and features like querySelector.
pjmlp 1612 days ago [-]
Frontend roadmap completly ignores everything that isn't a Web browser.
So no Qt, wxWidgets, Android, iOS, WPF, Forms, UWP, WinUI, GNOME, KDE, ...
hombre_fatal 1612 days ago [-]
In my experience, "front-end" these days generally means "web client development", e.g. the opposite of "back-end" (server application).
You're talking about client development in general.
I suppose web clients stole their own term because of the idiosyncrasies with web browsers, like how the server can ship declarative HTML to the browser for a fully-working UI which is a unique phenomenon.
There are issues with this weird distinction though. For example, people will complain how hard "front-end development" is, thinking it's something unique to the web, without knowing that all client development is hard.
jlokier 1612 days ago [-]
These days, I think the job-ad word coding is:
- Frontend = In a web browser; HTML, CSS, JavaScript
In my previous job i was working on game tools with wxWidgets, in my current job i am working on game tools with Qt. In between i got an offer (which i rejected since i am interested in games) for a Qt tool to be used for (IIRC) DNA research (or something like that, i'd just be doing the UI not the actual logic).
Scarblac 1612 days ago [-]
I think job descriptions saying "Frontend Developer" and "Backend Developer" nowadays imply the Web.
pjmlp 1612 days ago [-]
Except when it doesn't.
mitchdoogle 1612 days ago [-]
I think this would come as news to a large group of people, including myself. I've only ever imagined a front end developer working on the web.
pjmlp 1612 days ago [-]
Another large group of people has been doing frontend before Web existed.
jstimpfle 1612 days ago [-]
Meanings change. I think what you mean would be called an application or GUI programmer today.
lubonay 1612 days ago [-]
Mobile and Desktop are different beasts from Web Frontend and require different (although related) skillsets.
pjmlp 1612 days ago [-]
It is still frontend nonetheless.
tener 1612 days ago [-]
Agreed - should probably read " web frontend" or something similar.
notthatharda 1612 days ago [-]
Except Android/iOS, everything you listed is dead or dying.
No sane person would pick anything but Electron for a desktop app today, unless you are in a particularly high performance domain (CAD/Graphics/Video/...)
AlchemistCamp 1612 days ago [-]
> No sane person would pick anything but Electron for a desktop app today, unless you are in a particularly high performance domain (CAD/Graphics/Video/...)
People who don't hate their users or who don't hate the environment might.
Electron apps use lots of CPU, lots of RAM and lots of energy. I get that they're easy for web devs to make and I've made them before but I'd fight tooth and nail against launching one at scale (like Slack did, for example).
notthatharda 1612 days ago [-]
Well, if you make the energy argument, theres a lot more to cut then.
How about high resolution displays? And bit depths? We can perfectly work on a 1024x768x256 colors screen. Imagine how much CPU/GPU cycles that would save.
kcolford 1612 days ago [-]
Are you kidding me? There are many reasons to pick a non-electron platform without the need for particularly high performance. Android/iOS are good examples of the reasons why. There's just so much to be had by integrating with the OS and the environment that the user uses your tool in. Electron is great for a prototype or as a way to get your feet wet in improving the desktop experience. The best user experiences will always be founded on the native technologies of the target platform.
Edit: spelling errors
pjmlp 1612 days ago [-]
If they don't have any respect for their users I guess.
notthatharda 1612 days ago [-]
Only if by users you mean people living in the terminal. Yeah, those people hate GUIs, compositing desktops and anything more than monospaced text. Just whisper "Emoji" in their ear and witness the Wrath of Khan unleashed.
I would say exactly the opposite, not using web-tech for GUIs is disrespecting the users, because the end result is an ugly app with a lot of missing features (gif/image/emoji support for example).
Users seem to love their VS Code/Discord apps written in Electron. I wonder why.
bsagdiyev 1611 days ago [-]
I don't want gif/image/emoji support in 100% of the apps I use, so this point is silly. I dislike Electron apps because they tend to break with the OS UI and force whatever the developer thinks I want on me. I don't. Stop it.
pjmlp 1612 days ago [-]
Because they offer a gratis plugin eco-system over the competition that outweighs the disadvantage of running a memory hungry application.
Other than VSCode, my computers are free from Electron virus.
wdroz 1612 days ago [-]
IMO, you could put Remote Procedure Call (RPC) technologies such as gRPC for backend developer.
xmprt 1612 days ago [-]
Definitely a great idea. gRPC has been a huge benefit for us. I'd also get rid of learning NoSQL databases. It's good to know but in 99% of situations you should be dealing with them especially not before you learn about things further down the list like Docker, RESTful APIs, Auth, etc.
databrecht 1612 days ago [-]
NoSQL is not less important than others. Especially not with the rise of many startups that want to scale and want their sites to be lightning fast (e.g. available at the edge). Many companies I worked lately actually thought the non-traditional databases are becoming more important.
Also distinguishing NoSQL and SQL is quite old and still dating from the CAP theorem which is also becoming obsolete. You have traditional databases and the rest since 'NoSQL' are incorporating SQL features (ACID, joins, etc) and vice-versa, soon it will just be databases with feature X,Y,Z. If you want to add something I would rather add 'distributed databases'. Learn relational databases probably boils down to 'learn SQL'
Knowing which database to use in the landscape is extremely important.
It should imo be:
- Learn SQL
- Learn GraphQL (becoming the new SQL quickly)
- Learn gRPC
- Learn about database features (consistency, distribution, replication, sharding, OLTP, OLAP) and what database to use in which situation.
brillout 1611 days ago [-]
"becoming the new SQL quickly" - Prisma, who led the way on that front, abandoned this pursuit.
"Learn GraphQL" - I'm not sure you need to learn GraphQL. You need to now that GraphQL is a powerful tool for APIs consumed by third party devs, such as the GitHub or Facebook API. But for internal APIs (and more than 98% of APIs are internal!), GraphQL (and even REST) is overkill and you'd be better off with RPC, such as Wildcard API [1] or gRPC [2]. Many developers will never have to build a GraphQL API in they entire career. Only few companies need to expose their data to third parties.
I would hope new developers ignore comments like yours.
NoSQL databases are just a tool like other tools. And you should know when and why to apply such tools not just dismiss learning them altogether.
Also every developer goes on their own journey. So if someone wants to build a social network then a graph database is going to make more sense even at the beginning than a relational one.
xwdv 1612 days ago [-]
I’ve seen way too many junior developers fall in love with NoSQL databases to recommend them as a starting point. NoSQL is a niche tool whereas relational databases will be the bread and butter in a vast majority of cases. Many junior devs try to use NoSQL for everything and then fuck it all up.
Postgres even supports using NoSQL concepts with JSONB so there’s no reason not to start with it.
I’m sure I’ll get downvoted since HN has been very hostile to real talk lately but I don’t care.
majewsky 1612 days ago [-]
Yes, but the current version of the roadmap makes it seem like NoSQL databases are way more important than they are (IMHO). I would say a junior backend developer needs to know about web servers, REST, AuthN/AuthZ and even Docker way before they need to know about NoSQL.
oakejp12 1612 days ago [-]
I'm interested as to why junior developers even need to learn Docker. I'd say learning Docker would be a "nice-to-have," but you can go years, or even forever, without having to deal with it, or even having a need for it. I'm not saying learning Docker is fruitless, just that Junior Developers might not get enough out of learning Docker to put it in good use.
As for NoSQL. I'd say that definitely should be on the roadmap. I've assumed that they've already learned RDBMS, but knowing when to use the two is essential. Most companies now are working with data lakes and unstructured data (e.g. user and session data). Knowing how to get around that flexibility, how to structure your business logic and models, and what tool to pick (i.e. Redis for caching), etc. goes alongside NoSQL knowledge.
wdroz 1611 days ago [-]
Using docker force you to declare step by step what you need to build/use your code. If you combine that with good CI/CD, that easier to provides help to the junior developer if you can quickly reproduce the environment.
I had a bad experience with a project that I was assigned to "help". The build steps documented used incompatible lib version. It's hard to help if you can't even build/run their codes.
I would rethink including "Learn CSS3". CSS has moved away from single versioned spec to modules and levels, so CSS3 does not mean much now. If you want to emphasize some specific parts (like animations), better say so explicitly.
la_fayette 1612 days ago [-]
Please add web components to frontend, instead of pick a framework...
k_ 1612 days ago [-]
Yes.
I'd still recommend learning about one of those frameworks to anyone aspiring to be a skilled front-end developer. Not because it is essential to master them, but because there are interesting concepts in there that could help with front-end applications development.
charlieflowers 1612 days ago [-]
This is an outstanding piece of work. Kudos.
itronitron 1612 days ago [-]
the frontend developer roadmap is a hot mess and looks like it is intended as humor, especially in contrast to the backend developer which is much more descriptive
_akei 1612 days ago [-]
These lists are so depressing. Is there any other career where people are expected to know 100 things just to be an employee at the bottom of the food chain? I won't be surprised if it is harder to be a Full Stack Developer than to be a CEO of a multi-national corporation. Looks like we are pushing everything to Developers. Developers of the future are going to need a fulltime pyschologist to cope with this ever increasing list of skills required from them.
mLuby 1612 days ago [-]
Doctors, lawyers, and real engineers at least have similar or more broad domains they must be experts in, or people die.
CEO is a hard role not because of domain area but because of risk and uncertainty, both of which tend to be low when you're "at the bottom of the food chain."
madiathomas 1612 days ago [-]
All doctors, lawyers and real engineers I know only focus on one aspect. They are specialists. I know lawyers who specialises in rape cases, conveyancing, ligitation, but I have never met a lwayer who is expected to solve a rape case today and register a bond tomorrow. Same with doctors. They specialise and only focus on one domain. I was talking about skills when I included CEO, not about risk. When there is lots of money involved, almost everyone will accept to assume that risk and collect rewards.
abnry 1612 days ago [-]
There's the concept of T-shaped expertise. Start with a broad base but then narrow down to a specialty. So you've kind of got both. Doctors, for instance, still have to know the basics of every bodily system, regardless of what they specialize it, because everything affects everything in the body.
realityking 1612 days ago [-]
But even a lawyer specialised in criminal law will have gotten a broad education in contract law, property , civil procedure.
In my engineering school, mechanical engineers were taught the basics of electrical engineering.
There is a lot of value in gaining a good amount of breadth before specialising, even if just to ease communication with specialists of adjacent fields.
madiathomas 1612 days ago [-]
The best people in every field are people who are focused on one aspect and one aspect only. Linus Torvalds only focus on C programming and kernels. If you judge him based on these lists, he will be regarded incompetent because he can't do UI and is proud of it. He doesn't even try to learn the basics about it because he has his speciality and do it very well.
Lionel Messi doesn't try to be the best header or best defensive midfielder. He focuses on dribbling and scoring goals.
Trovalds has much more breadth than you give him credit for.
organsnyder 1612 days ago [-]
I'm always impressed at my primary care doc's breadth of knowledge. Whatever the topic (knee injury, heart rate, asthma...), he has working knowledge at easy recall, which he augments by consulting electronic reference materials during appointments—all while staying engaged with the patient (me). This is all in the context of a standard physical, and often the subjects (such as the knee injury) haven't been mentioned beforehand.
I do think he's in the top 5% of MDs, so of course we can't expect this of everyone. And specialists obviously specialize. But there is a large segment of the profession that requires a wide breadth of knowledge in a domain that frequently changes.
madiathomas 1612 days ago [-]
Is he a GP or a Specialist? From what I know, the list of best Doctors is full of specialists, not generalists. I am yet to hear someone recommending a General Practitioner because they have broader knowledge. It is always Specialists who are focused on one domain and one domain only. Not saying specialists don't have knowledge about other things medical-related. They do but their knowledge is limited. Just like my knowledge about firewalls and networking is limited because I focused on development.
organsnyder 1611 days ago [-]
He's a GP.
BTW, my career has been focused on development, but I still try to maintain enough knowledge that I could jump in at any point of the stack and be useful.
TheCoelacanth 1612 days ago [-]
It's not like a typical developer is going to be programming a web app one day and an embedded system for a car the next day. Even "full-stack" developers are still specializing in one domain.
mLuby 1612 days ago [-]
Anyone can accept risk. Accurately evaluating and effectively mitigating it is the skill, plus predicting a profitable direction and setting it in motion, maintaining accountability, negotiation and fundraising; the list goes on and looks very different from dev skillsets.
Maybe this site should add a CEO skill map!
madiathomas 1612 days ago [-]
Maybe we need to see those skills map. I can't wait for CEOs to disagree that you don't need those skills. Most CEOs became CEOs because they started the company or are connected to the owners of the company. Most CEOs are just political leaders of a business. They didn't need to learn HR, Finance, IT etc in order to run the company.
tarsinge 1612 days ago [-]
The key issue especially in the front-end roadmap is how the scale is not taken into account. Expecting all front end developers to use the same stack from small operations to Facebook or Google scale is irrational, yet for a lot of reasons it is standard practice. I understand how it gives a feeling of playing in the same court, but from an engineering point of view it’s useless complexity in a lot of projects.
Edit: For example I make a living doing web development and rarely using a framework or a package manager in my projects. Knowing their value sure helps in a CTO like role, but you can deliver real value and state of the art websites and apps without them.
madiathomas 1612 days ago [-]
One thing I have realised is that most tools developed by big tech companies were built to solve their unique problem. Majority of applications will never reach scale of Google or Facebook but people still use whatever is being used or marketed by those companies.
notthatharda 1612 days ago [-]
As a long time systems/backend C++/Python programmer it took me 6 months to get very comfortable with this TypeScript/NPM/Vue/Vuex/Bootstrap/Webpack/Linters/Formatters stack and create a pretty complex SPA.
A lot of stuff, true, but nothing particularly challenging.
I would say the hardest part is CSS, but using a framework like Bootstrap and then googling the little problems "how best to X in CSS" usually works.
madiathomas 1612 days ago [-]
You learnt all that without any previous background in JavaScript, HTML, HTTP etc? That is impressive if that was the case. Very impressive.
CSS is hard. Even for people who have been doing it for decades. I am one of those people who can do whatever can be done on Bootstrap, but from time to time, I still struggle with CSS. It is getting better these days because browsers are co-operating and don't have their own flavour of CSS just to break other browsers.
notthatharda 1612 days ago [-]
I knew basic JavaScript/HTML, but it was 2006 level, when I played a bit with jquery, so I knew about ids/classnames from back then.
My SPA does use HTTP/WebSocket, it's served with nginx, uses a postgres database, but this is backend stuff.
ducaale 1612 days ago [-]
Well, you are not supposed to know all of them by heart. just start by what you need and know what other technologies that exist so you can learn them when the need arises. for me, I think I know or have a vague idea about most of the concepts mentioned in Frontend and Backend. But DevOps sections seems intimidating to me. People in other fields might feel the same way about Frontend or Backend Development. The thing is, just like any craft, it requires time and practice.
madiathomas 1612 days ago [-]
I feel our craft is just too demanding. There is just too much to learn. If you stop learning for just one year, your knowledge quickly becomes redundant and you become unhireable.
SolaceQuantum 1612 days ago [-]
I don't think these are really excessive. You could probably learn much of each stack by essentially using personal projects as excuses to use these technologies and touch at least half or one third of each list each go. For example, "write a poker card playing website that saves your hand when you press a button" will get you a bunch of frontend, backend, and database.
madiathomas 1612 days ago [-]
The tools that I have already learnt are working perfectly for me. I feel these days we are just adding tools for the sake of adding new tools. Instead of spending time to perfect what I already know, I have to spend time learning how to use tools I will never need.
opportune 1612 days ago [-]
You don’t need to know everything on the list to be good at a role.
Just for example, Devops engineer lists Mesos, emacs, sockets, and virtualization. Other than know that these concepts exist and a 5 sentence description of what they do, you don’t need to intimately understand them. I haven’t gone through the other roles but I’m sure they’re the same.
thih9 1612 days ago [-]
I've looked at the "Backend Developer" guide, I'm surprised that it doesn't mention git or any other version control tools.
I think it could be a useful addition; nowadays version control is part of almost all backend projects.
kamranahmed_se 1612 days ago [-]
Thank you for pointing it out. It is still being modified and will hopefully be fixed this week along with the other changes. It was there in the "common" section in the repository https://github.com/kamranahmedse/developer-roadmap but was missed when moving the roadmap to the website.
s_gourichon 1612 days ago [-]
1. Yes, git should definitely appear in a common / transverse section. Oh, I see it now appears.
2. What do you mean "missed when moving the roadmap to the website"? Don't you have an automated deployment setup?
3. I see no code at all in the repository. This looks like free-to-contribute documentation, not FOSS then. Still, very good thing that you did it.
4. Also, besides web (that you cover) and embedded (as mentioned in other comments, and writing device driver can be considered similar), there is still also desktop applications, signal processing oriented programming (including electrical, sound, image and similar) and their number-crunching oriented cousins (machine learning, smart data import with added value, data science and similar) and security. I personally know startups that do each of these.
greggman2 1612 days ago [-]
I think I don't understand these. They seem too high level to actually be useful. There's a old Steve Martin skit from the 70s where he's says he's going to tell you "How to get a million dollars and never pay taxes...... Step 1: Get a million dollars ...". These roadmaps seem about that level.
Am I missing it? Are these actually useful? For example clicking backend the first thing is it lists 14 languages (although two of these items are not languages). How is that useful to someone? Which one should they pick? How would someone that didn't already know these languages and their strengths and weaknesses get useful info from that? Sorry I'm not trying to be critical just wondering how this is helpful.
abnry 1612 days ago [-]
This is a roadmap, not a tutorial. You still need to get in the car and turn the key in the ignition. Logically, it makes sense to learn some technologies before other technologies. They build on each other. And for someone like me who knows very little software engineering, just seeing some organized list of terms looks helpful.
Matty1992 1612 days ago [-]
Agreed, the "Pick a language" phase is one of the most difficult parts of starting a developer path especially without context, atleast in my memory.
There isnt a good reason to just pick something like python or typescript if you want to build native phone apps for example
swilliamsio 1612 days ago [-]
I partially agree. The backend map seems really wishy-washy. The front end map seems much more useful, just because it's more limited in scope. It would be better I feel with in depth tutorials for every step, or links to them, with achievable goals at every step, kind of like a testable curriculum.
brojonat 1612 days ago [-]
It's funny seeing different peoples' takes on this; someone else said the frontend section was a 'hot mess' but the backend was much more structured and well done. Guess it's just a testament to how much is out there.
biudiepie 1612 days ago [-]
Love this idea, hope the maps could be interactive. Attaching related resources would be great.
jktj 1612 days ago [-]
I second this, related resources for language of choice.
kevinyun 1612 days ago [-]
Wow, this is nice. Going through the front-end path briefly, I realize I know most of these things, and it is because of gradual exposure and necessity in a tool.
I remember as a freshman in college, when I decided to first learn the basics of web development, I saw an intimidating roadmap like this one (though that was for full-stack). Back then, I would have never dreamed of making it even a quarter way through the list.
veeralpatel979 1612 days ago [-]
Would love to see a roadmap on security engineering!
sauravs 1612 days ago [-]
good point...i will be interested too
aaron-santos 1612 days ago [-]
Maybe not a developer roadmap per se, but I refer to this data science roadmap[1] from time to time. It isn't a definitive statement on what makes a data scientist, but it does help me pick the next concept to learn and make knowledge gaps more obvious.
These seem to be bags of words, which hardly explain the rationale or context for any of the items mentioned.
In terms of 'brainstorm of words, some of which may be useful', fine. But I'd be very surprised if even the average dev had even heard of everything on that list. The scope includes some ubiquitous things, and some things that are surely niche.
I'm hoping no beginner gets the impression that they ought to know all of these things or else they're an imposter.
What's the appeal to these?
tchaffee 1612 days ago [-]
Full stack dev here. Both the frontend and backend lists look reasonable and I know all the tools and the vast majority of the terms. I do agree with you that the lists look overwhelming. Some information hiding and ability to reveal would help.
james_s_tayler 1612 days ago [-]
Yeah, it's just a word soup presented as a giant image. I've seen these before. They're not bad for at least laying out the landscape, but I think a more interactive format would be helpful.
Like allowing you to pick a language and then relevant frameworks/tools/patterns are shown. Furthermore it'd be useful to split it up into junior, intermediate, senior, principal level expectations. As a junior if you see this you might just want to quit on day one. As a senior it's useful to spot any gaps. As an intermediate it's useful to pick a next area to gain proficiency in.
paradox_hunter 1612 days ago [-]
I think he should make it clear who these roadmaps are for.
From the looks of it, definitely not a beginner, but probably for someone who has spent atleast some time in the field.
throwaway35784 1612 days ago [-]
If they are image maps with links where to learn the leaf nodes this would be the bees knees.
1612 days ago [-]
kmfrk 1612 days ago [-]
Great concept! Teaching yourself things is always difficult because you only see things horizontally and don't know how to actually build on what you know, especially without spending 000s of dollars.
loco5niner 1612 days ago [-]
> 000s of dollars
Wow, that's a lot of dollars
avishj 1612 days ago [-]
That's a really nice website. I'm a young developer interested in web developer and it gives me a good roadmap for how I would go along figuring stuff out till I become a full stack web development. I just hope that the full stack roadmap comes soon, the front-end and back-end seems really well planned out.
Another thing that I'll say that would be nice, if there were other roadmaps for become a mobile app developer like those including OSes like Android, iOS, Mac OS, etc.
Farbklex 1612 days ago [-]
Good overview. I also like it as an illustration for beginners to explain, that "learning to code" is very broad and can be broken down into tiny areas.
When I teach friends how to code, I show them the bigger picture and then narrow down what I'll actually teach them no manage expectations: Java / Kotlin basics and some android development. So they now what they get in the beginning and what else is out there.
yuchi 1612 days ago [-]
The design of the maps is terrible, the content is gold.
Will recommend internally in my company.
Very nice job.
sethammons 1612 days ago [-]
I find the back end engineer roadmap lacking a few critical items that seem to be in the devops section (granted, everyone needs devops chops). Metrics, monitoring, alerting, and networks (tcp, http, grpc, sockets), and basic distributed systems.
Z3lgius 1612 days ago [-]
This is amazing! I always get questions from new developers or students similar to "I want to do/be X, how do I start?" and now I can point them to this. Thank you for this.
ddorian43 1612 days ago [-]
Create a roadmap for low-level/systems developer (ex: create database, search-engine, storage engine, replication, sharding, low level performance etc)
lubonay 1612 days ago [-]
Here's an idea to improve this site: make the texts searchable somehow. Ctrl+F -> "JavaScript" shouldn't yield 0 results.
P.S. are you generating a static site using next.js ?
neiman 1612 days ago [-]
Wow, may be slightly overwhelming for a newcomer but a great idea nevertheless!
Which tools they used to make these beautiful infographics?
1612 days ago [-]
zyl1n 1612 days ago [-]
What does yellow color in some boxes mean?
tudorpavel 1612 days ago [-]
It's unfortunate that not every diagram contains the legend from the first diagram in the GitHub repo [0] which explains yellow as "Personal recommendation" and orange as "Available Options". I think grey was "Optional".
Yellow means "Personal Recommendations" and the peach one means available options. This will be more clarified/fixed in the next release.
notthatharda 1612 days ago [-]
Good default, general industry consensus for best option if you have no particular needs.
franferri 1612 days ago [-]
Brilliant idea
pjmlp 1612 days ago [-]
The Frontend Developer "roadmap" ignores any kind of native UI development.
It should be renamed to Frontend Web Developer.
scarface74 1612 days ago [-]
When people in the modern era say “front end developer” that basically implies web.
Most people in common nomenclature don’t call iOS and Android developers “front end developers”. They are referred to as “mobile developers”.
pjmlp 1612 days ago [-]
Plenty of digital agencies do frontend work across multiple delivery platform formats
scarface74 1612 days ago [-]
I don’t doubt that. But, if they advertise a need for “front end developers”, that would strongly imply web developers.
I would definitely be surprised if they advertised a position for a “front end developer”, I applied and during the interview they asked questions about Windows Forms development.
pjmlp 1612 days ago [-]
Be prepared to be surprised then.
scarface74 1612 days ago [-]
Trust me, I’ve been on plenty of successful interviews. Not once have they wanted a “full stack developer” or a front end developer that could do Windows Forms.
I’m not saying that no one wants desktop developers - they just don’t refer to them as “front end” developers.
Windows Forms or any windows desktop development was already losing favor when I was looking for a job in 2008 after being at one company for almost a decade.
Now in 2019, any developer who cares about his career will run screaming the other way if a company even mentions that they are doing desktop software unless they can get a job with Microsoft or Adobe.
pjmlp 1612 days ago [-]
Believe me as well, doing frontend native and Web UIs since mid-90s, including digital agencies.
Plenty of companies are doing greenfield native UIs, including desktop. Mobile is desktop as well, just a matter of hardware form factor.
scarface74 1612 days ago [-]
Mobile is “not just like desktop” unless you’re using a cross platform framework and even then you have different constraints - unreliable network connections, different screen sizes and interactions, you have to be more mindful of power and memory usage, dealing with app stores and review processes, etc.
But its really not hard to look at job boards or where the money is going both from internal and external investments to see which cart to tie your horse to. It definitely is not the desktop.
Even Microsoft isn’t really focusing on desktop development and has put .Net Framework in maintenance mode.
pjmlp 1612 days ago [-]
A tablet with keyboard is a desktop.
A laptop with wireless connectivity is a desktop.
Anything with a pluggable keyboard and screen is a desktop.
Something that many fail to grasp.
scarface74 1612 days ago [-]
What's your point? Just like "front end development" implies "web development" to most people, "desktop development" implies "development that is not web, Android, or iOS".
pjmlp 1612 days ago [-]
To people that don't know better.
scarface74 1612 days ago [-]
Are you really saying that there are people posting to HN that don’t know “desktop applications” don’t include applications running on laptops?
pjmlp 1611 days ago [-]
Indeed.
thiagomgd 1612 days ago [-]
In that case, would you really want to work there?
bdcravens 1612 days ago [-]
They also do SEO and WordPress sites. And many of the front end devs also do back end or devops, and vice versa. "Front end" isn't a synonym for an agency employee, it's just one role that may be needed at such an agency.
loco5niner 1612 days ago [-]
Great content. Lots of typos
Rendered at 13:45:11 GMT+0000 (Coordinated Universal Time) with Vercel.
I say this all as a "full stack" embedded guy. I'd love to have someone else take on part of it, but I'm a solo consultant right now :). Did both EE and CS in school, and more than happy to do whole projects end-to-end, but I also don't expect EEs to be fantastic programmers, or embedded software people to be fantastic hardware designers.
Also, does FPGA come to mind when embedded is mentioned? I always assume that FPGA is a whole another subject (only FPGA not the board part).
This has been my assumption as well. I looked a while back at learning FPGA development because it seemed rather interesting, but quickly decided to go another route after seeing and talking to some FPGA guys. From what I saw it does not in any way resemble what I'm used to as a software developer
I was talking about embedded development which doesn't really have anything to do with PCB design, power, FPGA, etc. You don't need those things to be a programmer working on embedded systems or microcontrollers.
Implementing a serial interface in software flipping GPIOs up and down will expose you to a whole lot of the necessary ecosystem and if you can do it, you're well past the point where you should be able to get paid to do it and the point where you need a roadmap to tell you where to expand your skills. I didn't say doing it would get you a senior level position or a masters degree in EE.
HTTP, HTML, CSS, JavaScript, etc are web technologies.
TCP/IP (among other things) are internet technologies.
Web tech builds upon internet tech.
Now having said that, sure I've seen some defence projects that make use of HTTP or have internal "web"sites for managing interfaces. It's even a trend for embedded hardware to have web management interfaces (your internet router/modem is a great example).
But when I say "web", of course I was really meaning user-facing/world facing websites. That seems to be the implication behind "front end developer". Not "I make front ends for building automation systems" but "I make front ends for websites hosted on the WWW". Requires a slightly different set of knowledge imo. One is tailored for looks and UX, the other is a trade-off between minimalism, efficiency, and usability (if only this was applied more to the major sites you see on the WWW now!).
Would protocols that use HTTP for transport like gRPC[3] mean that HTTP is not a web technology either? I don't know what is a web technology anymore...
[1] https://developer.gnome.org/gtk3/stable/chap-css-overview.ht...
[2] https://en.wikipedia.org/wiki/EPUB
[3] https://en.wikipedia.org/wiki/GRPC
As someone who has quite a bit of experience as a systems level engineer, who has written code for custom hardware, but is not a firmware engineer (in other words, grain of salt here): Knowing C (or C++) well enough to be able to write threaded code is super important, for not all but many jobs. (Or at least know the concepts, eg the different kinds of atomics.) Knowing I²C or similar is a good idea. Knowing or dipping your toes into DSP can be helpful. Know at least mean squared error, and how to do a bandpass. And bonus points (though very few people in the embedded space know it) is learn Rust. It will teach you good programming practices that most firmware engineers do not know. Many of them are stuck bug testing run time errors day in and day out, instead of letting the compiler do it for them. (Again, 2 cents on all of this. Best to get actual requirements from job posts.)
The website and the content is opensource and can be found at https://github.com/kamranahmedse/roadmap.sh. Please feel free to contribute, drop your feedback, feature requests and issues there.
Angular: 3* years *9 if you count AngularJS React: 6 years Vue: 5 year
That's a long time by web standards, they also keep up and push native javascript forward.
So yes, learn native JS. Definitely learn a framework though, as those skills are ultimately what you need to work on anything more complex than a simple website.
So no Qt, wxWidgets, Android, iOS, WPF, Forms, UWP, WinUI, GNOME, KDE, ...
You're talking about client development in general.
I suppose web clients stole their own term because of the idiosyncrasies with web browsers, like how the server can ship declarative HTML to the browser for a fully-working UI which is a unique phenomenon.
There are issues with this weird distinction though. For example, people will complain how hard "front-end development" is, thinking it's something unique to the web, without knowing that all client development is hard.
- Frontend = In a web browser; HTML, CSS, JavaScript
- Mobile = Android, iOS
- Desktop = Qt, wxWidgets, WPF, Forms, UWP, WinUI, GNOME, KDE
In my previous job i was working on game tools with wxWidgets, in my current job i am working on game tools with Qt. In between i got an offer (which i rejected since i am interested in games) for a Qt tool to be used for (IIRC) DNA research (or something like that, i'd just be doing the UI not the actual logic).
No sane person would pick anything but Electron for a desktop app today, unless you are in a particularly high performance domain (CAD/Graphics/Video/...)
People who don't hate their users or who don't hate the environment might.
Electron apps use lots of CPU, lots of RAM and lots of energy. I get that they're easy for web devs to make and I've made them before but I'd fight tooth and nail against launching one at scale (like Slack did, for example).
How about high resolution displays? And bit depths? We can perfectly work on a 1024x768x256 colors screen. Imagine how much CPU/GPU cycles that would save.
Edit: spelling errors
I would say exactly the opposite, not using web-tech for GUIs is disrespecting the users, because the end result is an ugly app with a lot of missing features (gif/image/emoji support for example).
Users seem to love their VS Code/Discord apps written in Electron. I wonder why.
Other than VSCode, my computers are free from Electron virus.
Also distinguishing NoSQL and SQL is quite old and still dating from the CAP theorem which is also becoming obsolete. You have traditional databases and the rest since 'NoSQL' are incorporating SQL features (ACID, joins, etc) and vice-versa, soon it will just be databases with feature X,Y,Z. If you want to add something I would rather add 'distributed databases'. Learn relational databases probably boils down to 'learn SQL'
Knowing which database to use in the landscape is extremely important.
It should imo be: - Learn SQL - Learn GraphQL (becoming the new SQL quickly) - Learn gRPC - Learn about database features (consistency, distribution, replication, sharding, OLTP, OLAP) and what database to use in which situation.
"Learn GraphQL" - I'm not sure you need to learn GraphQL. You need to now that GraphQL is a powerful tool for APIs consumed by third party devs, such as the GitHub or Facebook API. But for internal APIs (and more than 98% of APIs are internal!), GraphQL (and even REST) is overkill and you'd be better off with RPC, such as Wildcard API [1] or gRPC [2]. Many developers will never have to build a GraphQL API in they entire career. Only few companies need to expose their data to third parties.
[1]: https://github.com/reframejs/wildcard-api
[2]: https://grpc.io/
NoSQL databases are just a tool like other tools. And you should know when and why to apply such tools not just dismiss learning them altogether.
Also every developer goes on their own journey. So if someone wants to build a social network then a graph database is going to make more sense even at the beginning than a relational one.
Postgres even supports using NoSQL concepts with JSONB so there’s no reason not to start with it.
I’m sure I’ll get downvoted since HN has been very hostile to real talk lately but I don’t care.
As for NoSQL. I'd say that definitely should be on the roadmap. I've assumed that they've already learned RDBMS, but knowing when to use the two is essential. Most companies now are working with data lakes and unstructured data (e.g. user and session data). Knowing how to get around that flexibility, how to structure your business logic and models, and what tool to pick (i.e. Redis for caching), etc. goes alongside NoSQL knowledge.
I had a bad experience with a project that I was assigned to "help". The build steps documented used incompatible lib version. It's hard to help if you can't even build/run their codes.
[1]: https://github.com/reframejs/wildcard-api
I'd still recommend learning about one of those frameworks to anyone aspiring to be a skilled front-end developer. Not because it is essential to master them, but because there are interesting concepts in there that could help with front-end applications development.
CEO is a hard role not because of domain area but because of risk and uncertainty, both of which tend to be low when you're "at the bottom of the food chain."
In my engineering school, mechanical engineers were taught the basics of electrical engineering.
There is a lot of value in gaining a good amount of breadth before specialising, even if just to ease communication with specialists of adjacent fields.
Lionel Messi doesn't try to be the best header or best defensive midfielder. He focuses on dribbling and scoring goals.
In the latter, he also touched some GTK code: https://github.com/torvalds/subsurface-for-dirk/commit/c0adf...
Trovalds has much more breadth than you give him credit for.
I do think he's in the top 5% of MDs, so of course we can't expect this of everyone. And specialists obviously specialize. But there is a large segment of the profession that requires a wide breadth of knowledge in a domain that frequently changes.
BTW, my career has been focused on development, but I still try to maintain enough knowledge that I could jump in at any point of the stack and be useful.
Maybe this site should add a CEO skill map!
Edit: For example I make a living doing web development and rarely using a framework or a package manager in my projects. Knowing their value sure helps in a CTO like role, but you can deliver real value and state of the art websites and apps without them.
A lot of stuff, true, but nothing particularly challenging.
I would say the hardest part is CSS, but using a framework like Bootstrap and then googling the little problems "how best to X in CSS" usually works.
CSS is hard. Even for people who have been doing it for decades. I am one of those people who can do whatever can be done on Bootstrap, but from time to time, I still struggle with CSS. It is getting better these days because browsers are co-operating and don't have their own flavour of CSS just to break other browsers.
My SPA does use HTTP/WebSocket, it's served with nginx, uses a postgres database, but this is backend stuff.
Just for example, Devops engineer lists Mesos, emacs, sockets, and virtualization. Other than know that these concepts exist and a 5 sentence description of what they do, you don’t need to intimately understand them. I haven’t gone through the other roles but I’m sure they’re the same.
I think it could be a useful addition; nowadays version control is part of almost all backend projects.
2. What do you mean "missed when moving the roadmap to the website"? Don't you have an automated deployment setup?
3. I see no code at all in the repository. This looks like free-to-contribute documentation, not FOSS then. Still, very good thing that you did it.
4. Also, besides web (that you cover) and embedded (as mentioned in other comments, and writing device driver can be considered similar), there is still also desktop applications, signal processing oriented programming (including electrical, sound, image and similar) and their number-crunching oriented cousins (machine learning, smart data import with added value, data science and similar) and security. I personally know startups that do each of these.
Am I missing it? Are these actually useful? For example clicking backend the first thing is it lists 14 languages (although two of these items are not languages). How is that useful to someone? Which one should they pick? How would someone that didn't already know these languages and their strengths and weaknesses get useful info from that? Sorry I'm not trying to be critical just wondering how this is helpful.
There isnt a good reason to just pick something like python or typescript if you want to build native phone apps for example
I remember as a freshman in college, when I decided to first learn the basics of web development, I saw an intimidating roadmap like this one (though that was for full-stack). Back then, I would have never dreamed of making it even a quarter way through the list.
[1] - http://nirvacana.com/thoughts/2013/07/08/becoming-a-data-sci...
In terms of 'brainstorm of words, some of which may be useful', fine. But I'd be very surprised if even the average dev had even heard of everything on that list. The scope includes some ubiquitous things, and some things that are surely niche.
I'm hoping no beginner gets the impression that they ought to know all of these things or else they're an imposter.
What's the appeal to these?
Like allowing you to pick a language and then relevant frameworks/tools/patterns are shown. Furthermore it'd be useful to split it up into junior, intermediate, senior, principal level expectations. As a junior if you see this you might just want to quit on day one. As a senior it's useful to spot any gaps. As an intermediate it's useful to pick a next area to gain proficiency in.
Wow, that's a lot of dollars
Another thing that I'll say that would be nice, if there were other roadmaps for become a mobile app developer like those including OSes like Android, iOS, Mac OS, etc.
When I teach friends how to code, I show them the bigger picture and then narrow down what I'll actually teach them no manage expectations: Java / Kotlin basics and some android development. So they now what they get in the beginning and what else is out there.
Very nice job.
P.S. are you generating a static site using next.js ?
Which tools they used to make these beautiful infographics?
[0] https://github.com/kamranahmedse/developer-roadmap
It should be renamed to Frontend Web Developer.
Most people in common nomenclature don’t call iOS and Android developers “front end developers”. They are referred to as “mobile developers”.
I would definitely be surprised if they advertised a position for a “front end developer”, I applied and during the interview they asked questions about Windows Forms development.
I’m not saying that no one wants desktop developers - they just don’t refer to them as “front end” developers.
Windows Forms or any windows desktop development was already losing favor when I was looking for a job in 2008 after being at one company for almost a decade.
Now in 2019, any developer who cares about his career will run screaming the other way if a company even mentions that they are doing desktop software unless they can get a job with Microsoft or Adobe.
Plenty of companies are doing greenfield native UIs, including desktop. Mobile is desktop as well, just a matter of hardware form factor.
But its really not hard to look at job boards or where the money is going both from internal and external investments to see which cart to tie your horse to. It definitely is not the desktop.
Even Microsoft isn’t really focusing on desktop development and has put .Net Framework in maintenance mode.
A laptop with wireless connectivity is a desktop.
Anything with a pluggable keyboard and screen is a desktop.
Something that many fail to grasp.