Developer Roadmaps
roadmap.sh
roadmap.sh
HTTP, HTML, CSS, JavaScript, etc are web technologies.
TCP/IP (among other things) are internet technologies.
Web tech builds upon internet tech.
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...
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!).
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 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.
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.
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.
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.
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.
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.
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.
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/
So no Qt, wxWidgets, Android, iOS, WPF, Forms, UWP, WinUI, GNOME, KDE, ...
- 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).
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.
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/...)
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.
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.
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.
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."
Maybe this site should add a CEO skill map!
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.
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?
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.