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.
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.
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.
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.
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).
> 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
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.
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!).
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.
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...
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.
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.)
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.
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.
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.
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.
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.
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.
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).
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/...)
> 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).
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.
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.
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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.
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
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.
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."
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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".
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.
