Ask HN: Should I be specializing in either front end or back end as full-stack?
42 comments
Which do you enjoy more?
It’s always easier to learn and excel in a subject that you prefer. Don’t force yourself into a specialty you don’t like because you think it will help your career more. Doing work you don’t enjoy every day is not good for your career.
As for specialties, both front-end and back-end are too broad of categories. There’s a huge difference between a back-end developer writing simple CRUD apps to serve 1 request per second and a back-end developer writing complex distributed, high-availability applications that serve huge numbers of requests per second. Don’t listen to anyone who tells you “everything is just a CRUD app”.
Pick the domain you like most and then work toward the companies doing the most interesting work in that domain.
It’s always easier to learn and excel in a subject that you prefer. Don’t force yourself into a specialty you don’t like because you think it will help your career more. Doing work you don’t enjoy every day is not good for your career.
As for specialties, both front-end and back-end are too broad of categories. There’s a huge difference between a back-end developer writing simple CRUD apps to serve 1 request per second and a back-end developer writing complex distributed, high-availability applications that serve huge numbers of requests per second. Don’t listen to anyone who tells you “everything is just a CRUD app”.
Pick the domain you like most and then work toward the companies doing the most interesting work in that domain.
I think I enjoy backend work more, however in my 3 years of working I didn't really experience those complex distributed apps to work on.
I've been mainly working with really simple CRUD apps. 1 server apps kind of things.
That's why I'm also afraid that I won'be fit and good enough to work on those big complex apps.
I've been mainly working with really simple CRUD apps. 1 server apps kind of things.
That's why I'm also afraid that I won'be fit and good enough to work on those big complex apps.
Complex distributed apps are incredibly difficult to get started with, at first. They are a huge leap up from simple CRUD because of the atomicity and consistency requirements.
Can you look for a junior position in a medium to big company, or a startup, with enough engineers to help mentor you?
If you want to try it yourself, you can start by experimenting with database clones, redis shards, K8s, etc., and then try reimplementing the same things in various cloud providers, so you can get a basic understanding of a shared/sharded data model in various frameworks.
Or, if you want to leapfrog all that, you can jump straight to serverless stores like Firebase or https://www.cloudflare.com/products/workers-kv/ that abstract away the infrastructure and let you focus on writing business logic on top of that.
But IMO you will learn more quickly from one year on the job, during professional backend work in a capable team, than self-learning willy-nilly (where you can pick up a lot of bad practices, or outdated/inappropriate architectures).
Can you look for a junior position in a medium to big company, or a startup, with enough engineers to help mentor you?
If you want to try it yourself, you can start by experimenting with database clones, redis shards, K8s, etc., and then try reimplementing the same things in various cloud providers, so you can get a basic understanding of a shared/sharded data model in various frameworks.
Or, if you want to leapfrog all that, you can jump straight to serverless stores like Firebase or https://www.cloudflare.com/products/workers-kv/ that abstract away the infrastructure and let you focus on writing business logic on top of that.
But IMO you will learn more quickly from one year on the job, during professional backend work in a capable team, than self-learning willy-nilly (where you can pick up a lot of bad practices, or outdated/inappropriate architectures).
It may not be common, but I don't think it's inherently not doable. I worked at a Ruby/Rails startup that had a monolithic API codebase, but also a number of new microservices written in Go using various AWS products. The Platform team that maintained all of this was small like 3-pizza-small and we hired both junior devs as well as interns if they showed an appropriate aptitude. So I wouldn't rule it out. Btw the example company is gone for this intent/purpose but did exist as such.
In general I think working at (very) small startups is the best way for very capable, self-learner types to be exposed and allowed to do lots of things in a short time as it's basically a free-for-all matching tasks with anyone who can get it done.
Edit: after writing this, I realize that the other Ruby/Rails place I'm working at (Shopify) does let non-senior devs do some complicated stuff in the core monolith and jobs that gets reviewed by senior devs. The team I'm on runs Kanban-style 2-week minicycles (didn't like Sprint'ing) and encourage different people to try tackling different things, often with pairing or review of proposed approach.
In general I think working at (very) small startups is the best way for very capable, self-learner types to be exposed and allowed to do lots of things in a short time as it's basically a free-for-all matching tasks with anyone who can get it done.
Edit: after writing this, I realize that the other Ruby/Rails place I'm working at (Shopify) does let non-senior devs do some complicated stuff in the core monolith and jobs that gets reviewed by senior devs. The team I'm on runs Kanban-style 2-week minicycles (didn't like Sprint'ing) and encourage different people to try tackling different things, often with pairing or review of proposed approach.
Just using microservices doesn't automatically mean your app is distributed, though, or resilient/reliable/maintainable/scalable/consistent/atomic, etc. Microservices increase complexity but don't automatically guarantee improved quality.
More to the point: The tricky part of doing it all yourself is you have no idea if you're doing it well, and whether it would survive heavy real-world use and other devs/teams/companies/APIs/user agents. It's not easy for a solo dev to catch pitfalls that more experienced devs, or just more # of devs, might notice in a pair programming sesh or code review.
By all means experiment on your own, but IMO I found teams to be much more helpful for actually learning best practices rather than barebones spaghetti code. Startups count too! What you may lose in learning architectural best practices (depending on if you have any seniors and how good they are), you gain in problem-solving and research abilities, not to mention learning to do a lot of things at low cost.
More to the point: The tricky part of doing it all yourself is you have no idea if you're doing it well, and whether it would survive heavy real-world use and other devs/teams/companies/APIs/user agents. It's not easy for a solo dev to catch pitfalls that more experienced devs, or just more # of devs, might notice in a pair programming sesh or code review.
By all means experiment on your own, but IMO I found teams to be much more helpful for actually learning best practices rather than barebones spaghetti code. Startups count too! What you may lose in learning architectural best practices (depending on if you have any seniors and how good they are), you gain in problem-solving and research abilities, not to mention learning to do a lot of things at low cost.
You’re only a couple years into your career. They’re not going to throw you into the deep end right away. You have to work up toward it over time and usually change companies a few times to get there.
Which is the sad part. It's difficult to get good unless you have the responsibility of doing something challenging. I have similar experience to OP but am now tech lead and managing the infra, which has given me the confidence to take on other devops stuff.
This. Getting a good appreciation for infra is key.
The best way to get into distributed systems is to start building them. Create an OSS project in the space, put it on your resume and whatnot, blog about it, and they will come
I work at a fairly complex distributed system (lots of infrastructure, mostly event-based system with milli-seconds latency for interactions between services managed mainly through queues, either managed externally or internally, 90 million MAU) and I cannot agree more.
Also, I would say that the difference is not much "scaling" a CRUD app for request/seconds, but for engineers on a single codebase/service, also architecturally. It's one thing to work alone on your project (which will probably handle k req/s, it's very easy nowadays with classic PostgreSQL and some other queues like RabbitMQ if you need event-based system). It's another to work on the same system with 100x more features, complexity (either in the same monolith or in different micro-services), and especially understand how to be pragmatic and solve problems you did not account for.
No amount of study can prepare you, other than first years at work. Afterwards, in my opinion, the challenges become improving the technology to scale more, and management.
Also, I would say that the difference is not much "scaling" a CRUD app for request/seconds, but for engineers on a single codebase/service, also architecturally. It's one thing to work alone on your project (which will probably handle k req/s, it's very easy nowadays with classic PostgreSQL and some other queues like RabbitMQ if you need event-based system). It's another to work on the same system with 100x more features, complexity (either in the same monolith or in different micro-services), and especially understand how to be pragmatic and solve problems you did not account for.
No amount of study can prepare you, other than first years at work. Afterwards, in my opinion, the challenges become improving the technology to scale more, and management.
Question: at what point does "specializing" in one or the other make you not a "full stack" developer anymore?
I can technically do about everything on the web, I'm just really bad at front-end, and really good at back-end, which is where I do most of my work. Am I "full stack"?
How good to you have to be in...well, everything, to call yourself "full stack"?
I can technically do about everything on the web, I'm just really bad at front-end, and really good at back-end, which is where I do most of my work. Am I "full stack"?
How good to you have to be in...well, everything, to call yourself "full stack"?
I think this is the flavor of question that should be asked, tho I'd go further. For one thing, I've always really loathed the phrase "full stack" - if you've ever written a UI that has to drive hardware that requires assembly level firmware, built a CI/CD pipeline to run tests, build artifacts, manage infrastructure, update firmware and send it all out into the world, you _might_ be "full stack", for everyone else it's just a colloquial term for a web front end and a database API developer.
But I digress.
Even in the common context, to be Full Stack, I'd argue that you should be better than the sum of the parts. The lift you get from being able to decide, intelligently and at the speed of thought (without talking to a counterpart on the other end), which pieces of code - optimization, safeguards, business logic, etc. - belong in the front and back end, and how they interact at peak effectiveness, is more valuable than just the ability to build a good API or build a good web page.
Further, a full stack engineer, in my experience, is more likely to reach for tools like websockets, memcached, etc. earlier in a project than typical REST APIs (for example) where the line between back- and front- end require a bit more coordinated architecting, to achieve a richer end result.
But I doubt this is widely accepted. Anyway, my point is I wouldn't focus on either just because; I'd focus on what makes you better by knowing some of both. What can you learn in the back-end to support problems you're familiar with in the front-end, and what can you do in the front-end to make better use of your knowledge in the back-end? That's where full-stack value really lies.
But I digress.
Even in the common context, to be Full Stack, I'd argue that you should be better than the sum of the parts. The lift you get from being able to decide, intelligently and at the speed of thought (without talking to a counterpart on the other end), which pieces of code - optimization, safeguards, business logic, etc. - belong in the front and back end, and how they interact at peak effectiveness, is more valuable than just the ability to build a good API or build a good web page.
Further, a full stack engineer, in my experience, is more likely to reach for tools like websockets, memcached, etc. earlier in a project than typical REST APIs (for example) where the line between back- and front- end require a bit more coordinated architecting, to achieve a richer end result.
But I doubt this is widely accepted. Anyway, my point is I wouldn't focus on either just because; I'd focus on what makes you better by knowing some of both. What can you learn in the back-end to support problems you're familiar with in the front-end, and what can you do in the front-end to make better use of your knowledge in the back-end? That's where full-stack value really lies.
This is a good question. as far as front/back end I think it's probably just good enough to mostly get it working right without breaking anything too often.
But what I think really makes it front end is also when you have some server/platform administration skills. You would be surprised how many web developers don't know about tab complete on the shell, or have no idea how DNS works.
But what I think really makes it front end is also when you have some server/platform administration skills. You would be surprised how many web developers don't know about tab complete on the shell, or have no idea how DNS works.
But what I think really makes it front end
I meant to say what really makes it full stack, but it's too late to edit
I meant to say what really makes it full stack, but it's too late to edit
To me, full stack means you're not "really bad" at FE but more like intermediate to advanced at FE and BE. Over the past few years, full stack is becoming more involved with devops, data engineering, and machine learning too so there's now different levels of full stack in my opinion.
Full stack allows a single dev to "own" the whole ticket. It's great for startups but not so much at larger (or even medium sized) companies.
If you're "really bad at front-end" I would say: not a full stack. If you can't own a ticket end to end and create a front-end that is at least comparable in quality to a dedicated front-end developer then you are just a backend developer.
Similar to how I know some mobile dev but wouldn't call myself a mobile app developer in a million years.
With that said, I have interviewed a lot of people and full-stack is such a buzzword now that probably 2/3 of the people with it on their resume are in that boat. (good at one level of the stack and just a passing knowledge of the others)
I have had recruiters tell me so many times: "Oh, I found this awesome candidate, they're a full stack developer!" only to find there idea of full stack is they know how to add a border to a div with CSS or they are a front-end wizard but their only backend knowledge is SQL.
If you're "really bad at front-end" I would say: not a full stack. If you can't own a ticket end to end and create a front-end that is at least comparable in quality to a dedicated front-end developer then you are just a backend developer.
Similar to how I know some mobile dev but wouldn't call myself a mobile app developer in a million years.
With that said, I have interviewed a lot of people and full-stack is such a buzzword now that probably 2/3 of the people with it on their resume are in that boat. (good at one level of the stack and just a passing knowledge of the others)
I have had recruiters tell me so many times: "Oh, I found this awesome candidate, they're a full stack developer!" only to find there idea of full stack is they know how to add a border to a div with CSS or they are a front-end wizard but their only backend knowledge is SQL.
My own personal definition of Full Stack Dev is similar to the term one man army. It means I can design an app, do the front end, the backend, and handle the deployment.
Note that the app itself might not be great because you're doing the job or 4 or 5 specialists, but the idea is you could pull it off and have an ok app at the end without it being complete garbage.
Note that the app itself might not be great because you're doing the job or 4 or 5 specialists, but the idea is you could pull it off and have an ok app at the end without it being complete garbage.
Having done 25 years of "full stack" now I'd go for the back end or even skip it and hit operations/SRE. The rate of churn is far far lower, the knowledge is valuable for longer and the money is better.
The "money is better" part of it could be due to that there are just less people in SRE with 25 YOE than in other adjacent fields.
Could be that people joining SRE as juniors might not see that much of a difference.
Could be that people joining SRE as juniors might not see that much of a difference.
My opinion is the opposite. DISCLAIMER: I've never been a CTO or worked at a FAANG so I could be completely wrong about all of these, but it's the general impression that I get (even though I don't like it).
> The rate of churn is far far lower
For network engineers, perhaps, because the job opportunities are more stable in number as the industry has consolidated around cloud vendors for startups. It seems to me as though "DevOps" and cloud engineers have job tenures similar to software engineers.
> the knowledge is valuable for longer
...compared to the npm ecosystem, but generally speaking backend languages change about as quickly as Kubernetes, Hashicorp, and AWS offerings. A new paradigm comes along once in a while but lots of "new" knowledge could be described as application of existing concepts in a new problem domain.
> the money is better.
I don't think this is the case. Your actual value to an organization isn't always the same as your perceived value, and if you're in ops then your perceived value is less than if you write software. Writing software delivers features that drive revenue, so your contribution is tangible. Ops' contribution, on the other hand, is making sure that said things don't fall over. The best job that you can do in ops is to make things work as they should. Put more simply - writing software you can only make money, but doing ops you can only save it. Your success is also tethered to the software that runs the business insofar as if it goes down then you're on the hook to (at least help to) fix it. You're working towards a zero state instead of away from it and other teams are holding the reins.
I would further add that in a job interview when people ask "what projects you've been responsible for" it's a lot harder to explain something like an infrastructure migration or tooling deployment than it is building a feature as there's an order of less magnitude of novelty in the former than the latter. Interviewers would rather hear about how a feature that you built directly contributed to the business' bottom line than how you were able to implement TLS or put all of your secrets in Vault for the sake of compliance. There's less room for creative thinking in the ops world than in building a bespoke solution for a problem domain.
For the above reasons I'm sticking permanently with full-stack with a back-end concentration.
> The rate of churn is far far lower
For network engineers, perhaps, because the job opportunities are more stable in number as the industry has consolidated around cloud vendors for startups. It seems to me as though "DevOps" and cloud engineers have job tenures similar to software engineers.
> the knowledge is valuable for longer
...compared to the npm ecosystem, but generally speaking backend languages change about as quickly as Kubernetes, Hashicorp, and AWS offerings. A new paradigm comes along once in a while but lots of "new" knowledge could be described as application of existing concepts in a new problem domain.
> the money is better.
I don't think this is the case. Your actual value to an organization isn't always the same as your perceived value, and if you're in ops then your perceived value is less than if you write software. Writing software delivers features that drive revenue, so your contribution is tangible. Ops' contribution, on the other hand, is making sure that said things don't fall over. The best job that you can do in ops is to make things work as they should. Put more simply - writing software you can only make money, but doing ops you can only save it. Your success is also tethered to the software that runs the business insofar as if it goes down then you're on the hook to (at least help to) fix it. You're working towards a zero state instead of away from it and other teams are holding the reins.
I would further add that in a job interview when people ask "what projects you've been responsible for" it's a lot harder to explain something like an infrastructure migration or tooling deployment than it is building a feature as there's an order of less magnitude of novelty in the former than the latter. Interviewers would rather hear about how a feature that you built directly contributed to the business' bottom line than how you were able to implement TLS or put all of your secrets in Vault for the sake of compliance. There's less room for creative thinking in the ops world than in building a bespoke solution for a problem domain.
For the above reasons I'm sticking permanently with full-stack with a back-end concentration.
What would the curriculum for operations be?
But the hours are horrible, right?
Unanticipated issues should be the exception, not the norm. If unanticipated issues (both during and outside of working hours) occur at any regular interval; that is a problem that must be fixed ASAP.
When unanticipated issues continue to occur; it indicates either a management problem, a technical competence problem, or both.
IMO: One of the advantages of "devops" is that the people who get interrupted off hours are the same people who have to fix the problem. It's not always sustainable, though.
When unanticipated issues continue to occur; it indicates either a management problem, a technical competence problem, or both.
IMO: One of the advantages of "devops" is that the people who get interrupted off hours are the same people who have to fix the problem. It's not always sustainable, though.
I'm sure it is for some people but it's the least amount of hours I've ever done for the most money which is what I have optimised my career for.
in the macro: look at how many people in positions you'd like to be in (CTO, VP Eng, etc) have backend vs frontend backgrounds. there's a statistical "frontend ceiling" (https://twitter.com/changelog/status/1466420085908807681) in career progression.
in the micro: statistics dont matter if YOU know what you enjoy + are good at + pays well. theres ways to do well and make money in whatever background. you can even do this by rotating ends every 2 years until you find a natural stopping point
in the micro: statistics dont matter if YOU know what you enjoy + are good at + pays well. theres ways to do well and make money in whatever background. you can even do this by rotating ends every 2 years until you find a natural stopping point
“a jack of all trades is a master of none, but oftentimes better than a master of one.”
I recommend doing a "deep dive" on whatever you're actually interested in, but have at least a more than superficial understanding of many other things. maybe once a month spend 4 or 5 hours trying out a technology being discussed on HN.
But once you have a job, learn as much as you can about all the platform technology involved. if you're doing web development, this could be apache, nginx, azure, aws, bash, powershell, haproxy, f5, routing, DNS, firewalls, etc. but it could also mean jenkins, docker, k8s, ansible, puppet, github, gitlab, blah blah.
Being full stack means you understand the full stack. If you're working on a project and there is part of the process you don't understand, that should be the next thing you learn. when you get a job you'll probably be mostly focussed on one thing, but you can ask the other engineers and admins questions. If they're any good they'll love to show off their knowledge.
Being full stack really means not being stuck in your ways and not being afraid to touch something because the person who normally does it is sick.
So learn what you want. When you get a job learn what the job is using even if it's not your immediate responsibility. Always keep your eye on things that might be a better way of doing it. Programming, and tech in general burns through people who aren't constantly learning something new.
I recommend doing a "deep dive" on whatever you're actually interested in, but have at least a more than superficial understanding of many other things. maybe once a month spend 4 or 5 hours trying out a technology being discussed on HN.
But once you have a job, learn as much as you can about all the platform technology involved. if you're doing web development, this could be apache, nginx, azure, aws, bash, powershell, haproxy, f5, routing, DNS, firewalls, etc. but it could also mean jenkins, docker, k8s, ansible, puppet, github, gitlab, blah blah.
Being full stack means you understand the full stack. If you're working on a project and there is part of the process you don't understand, that should be the next thing you learn. when you get a job you'll probably be mostly focussed on one thing, but you can ask the other engineers and admins questions. If they're any good they'll love to show off their knowledge.
Being full stack really means not being stuck in your ways and not being afraid to touch something because the person who normally does it is sick.
So learn what you want. When you get a job learn what the job is using even if it's not your immediate responsibility. Always keep your eye on things that might be a better way of doing it. Programming, and tech in general burns through people who aren't constantly learning something new.
Define "beneficial for your career." Do you mean maximizing earning potential? Working on interesting tasks? Having a wide pool of job opportunities available?
I think that earning potential goes along with interesting tasks. You can't be making bank while working for web design studios.
So what I really meant was more money and interesting job
So what I really meant was more money and interesting job
In that case, the best thing to do is to feel out the organization you're in, and make yourself indispensable.
Do most of the new hires want to work on server-side code; but your UI is challenging and pushes the browser to its limits? Lean more towards in-browser work; and accomplish critical in-browser tasks that your management has trouble finding someone to do.
Likewise, is your in-browser code trivial, but your application is visibly too slow to the point that management has heat on them to make it more responsive? Focus on optimizing the data access layer, and become indispensable there.
Where I've had success is looking for areas of a product that you just can't "open a book" to learn how to implement. The problem space should have a high degree of novelty to it. These problems exist in all layers of the stack. In my case, I became lead for Syncplicity's desktop client, a major Dropbox competitor. For awhile my code was a market leader. (We were the only desktop file sync product that could handle 100,000+ files.)
Another area of success that I've had is in young companies, where team sizes are too small to really specialize. In my current role, I'm doing "full stack C#" with Blazor in the UI. (We chose it so that it would be easy for developers to move back and forth between UI and server-side code.) As we grow I'll probably focus more on back-end work; but at the moment, "full stack" is useful because I can make an API change in a single pull request without coordinating with anyone else.
Edit: As far as money goes, you will need some flexibility. I've taken a few below-market-rate jobs because they were interesting; then when I saw money flow into the company I had to raise a ruckus in order to get to market rate. It's not something I like doing, but unfortunately, that's how the world works, and that's why I keep focusing on becoming indispensable.
Do most of the new hires want to work on server-side code; but your UI is challenging and pushes the browser to its limits? Lean more towards in-browser work; and accomplish critical in-browser tasks that your management has trouble finding someone to do.
Likewise, is your in-browser code trivial, but your application is visibly too slow to the point that management has heat on them to make it more responsive? Focus on optimizing the data access layer, and become indispensable there.
Where I've had success is looking for areas of a product that you just can't "open a book" to learn how to implement. The problem space should have a high degree of novelty to it. These problems exist in all layers of the stack. In my case, I became lead for Syncplicity's desktop client, a major Dropbox competitor. For awhile my code was a market leader. (We were the only desktop file sync product that could handle 100,000+ files.)
Another area of success that I've had is in young companies, where team sizes are too small to really specialize. In my current role, I'm doing "full stack C#" with Blazor in the UI. (We chose it so that it would be easy for developers to move back and forth between UI and server-side code.) As we grow I'll probably focus more on back-end work; but at the moment, "full stack" is useful because I can make an API change in a single pull request without coordinating with anyone else.
Edit: As far as money goes, you will need some flexibility. I've taken a few below-market-rate jobs because they were interesting; then when I saw money flow into the company I had to raise a ruckus in order to get to market rate. It's not something I like doing, but unfortunately, that's how the world works, and that's why I keep focusing on becoming indispensable.
I interpret your question as a realization that you have a limited capacity, and you'd like to prioritize your learning.
If you are thinking about optimizing for employability, the answer to this largely comes down to the market you are trying to fit into (both location and business sector) and what you enjoy. As strangers, we cannot really give insight into those things with what you've provided.
From prioritizing time/effort for value perspective, I can say:
First, don't feel the need to be an expert at everything. I've been developing software for a long time, and there are still things I don't know. There will always be things I don't know. That opportunity for growth is one of the joys of software development. Don't burn yourself out trying to do everything.
My philosophy is to invest heavily in learning things that are likely to be relevant for a long time, and invest less heavily in things that are likely to only be valuable for a short time. Having shallow breadth is useful, so is having deep knowledge in a foundational technology.
Learning the language/framework/editor du jour is fun, but understand that you may be on a hamster wheel. Much of the new things are extremely similar, competing and vary only to address shortcomings with an earlier iteration while introducing the next set of shortcomings. It is necessary to have a full toolset, but resist chasing all the newest tools. Hamster wheels don't get you anywhere despite making you feel like you are moving fast.
Also, don't feel like 'full stack' is some badge of honor you strive to attain and keep. Just make sure you are doing useful work that someone cares about.
If you are thinking about optimizing for employability, the answer to this largely comes down to the market you are trying to fit into (both location and business sector) and what you enjoy. As strangers, we cannot really give insight into those things with what you've provided.
From prioritizing time/effort for value perspective, I can say:
First, don't feel the need to be an expert at everything. I've been developing software for a long time, and there are still things I don't know. There will always be things I don't know. That opportunity for growth is one of the joys of software development. Don't burn yourself out trying to do everything.
My philosophy is to invest heavily in learning things that are likely to be relevant for a long time, and invest less heavily in things that are likely to only be valuable for a short time. Having shallow breadth is useful, so is having deep knowledge in a foundational technology.
Learning the language/framework/editor du jour is fun, but understand that you may be on a hamster wheel. Much of the new things are extremely similar, competing and vary only to address shortcomings with an earlier iteration while introducing the next set of shortcomings. It is necessary to have a full toolset, but resist chasing all the newest tools. Hamster wheels don't get you anywhere despite making you feel like you are moving fast.
Also, don't feel like 'full stack' is some badge of honor you strive to attain and keep. Just make sure you are doing useful work that someone cares about.
You probably know best since you've done both and you have some idea about what you like. You can have a great career with either.
When I was just starting out, I had some imposter syndrome and need to prove myself, so I let other people's opinions rule my decision making. Someone always made me feel like the grass was greener in their specialty. Now that I'm older and more experienced, I see that every step of the development process is needed.
So I suspect that you already have some idea of what you would like to do, and just want some external validation and permission to follow your calling. And I would say, go for it! Whatever is in your heart to do, probably correlates with what the world needs right now.
And to be honest, I've often been hired to do one job but ended up doing another. It's really about how quickly we can learn, explore the problem space to find a solution and execute a plan. The rest is just titles IMHO.
So I suspect that you already have some idea of what you would like to do, and just want some external validation and permission to follow your calling. And I would say, go for it! Whatever is in your heart to do, probably correlates with what the world needs right now.
And to be honest, I've often been hired to do one job but ended up doing another. It's really about how quickly we can learn, explore the problem space to find a solution and execute a plan. The rest is just titles IMHO.
Depends on what you enjoy and what you value. If you aren't sure about either one, why not go (or stay?) full stack?
Heard a VC in a podcast mention backend is going extinct with api SaaS so I'd do front end
Salesforce was going to take over the world with their 'No Software!' SaaS platform, circa 2000.
We're still writing code in 2022.
We're still writing code in 2022.
They didn't take over the world, but they certainly made their own world.
https://www.youtube.com/watch?v=duJwGSUhRQA
https://www.youtube.com/watch?v=duJwGSUhRQA
I can't tell if this is sarcastic or not… backend isn't going anywhere.
Last thing I would do is take engineering advice from a VC
TL;DR - I'd say try learning and building with both and see which one makes more sense. You don't even have to think which is better for your career, as frontend, backend, fullstack can all find good paying jobs. What matter is you enjoying your work.
I'm a self taught software engineer, and have about the same experience as you.
I knew a little bit of python when I started learning and thus decided to learn Django (backend), really liked it (even then CSS was giving me the most trouble).
Then decided to learn JS to get a more well-rounded education, but hated it. Now I use Hotwired techniques for my web apps, to the least amount of Javascript possible.
I'm a self taught software engineer, and have about the same experience as you.
I knew a little bit of python when I started learning and thus decided to learn Django (backend), really liked it (even then CSS was giving me the most trouble).
Then decided to learn JS to get a more well-rounded education, but hated it. Now I use Hotwired techniques for my web apps, to the least amount of Javascript possible.
Sure, they all have interesting challenges, but the day to day work is pretty different. I think in part it comes down to personality and preferences. Which do you prefer:
* Working with users & designers, rapidly iterating UIs on some bleeding-edge messy ecosystem (React, etc.), dealing with whitespace and color palettes, state management and associated race conditions, and having clearly visible creative output at the end to show for it?
or...
* Working behind the scenes with other techies, vendors, specs and docs, architecting against best (or at least "known good") practices & patterns, enforcing rigidity and consistency and good versioning throughout your APIs, optimizing the hell out of every query, containerizing everything and jumping in and out of DevOps every hour, getting to learn various platforms and stacks in depth in order to produce a stable HTTP endpoint, working with many clouds... all to produce a remarkably well-engineered response that fellow engineers could appreciate but no user will ever see?
You can get a pretty deep, but different, sense of satisfaction from either calling. And these days there is really no end to the depth of specialization you can achieve, only the breadth. Even within "frontend" and "backend" there is already several lifetimes of learning, and the pace of development is only getting faster.
The frontend tends to iterate quicker, fast and furious, while the backend focuses on stability and resilience. The engineering cultures can be different (though not incompatible). In general I think the backend stuff is "harder" in that it's more actual engineering, and tends to get paid better. The frontend stuff is difficult in a different way -- creative and visual, often -- which for some reason companies don't tend to reward as highly. In our culture, engineering is thought of as more difficult than design, unless you're Steve Jobs or similar.
But at the end of the day, either path (or remaining full stack) would easily get you a much-more-than-livable wage at any decent company, so it comes down to things like work-life balance (do you want to be on pagerduty?) and just how much you enjoy each bucket of work, and the kind of people you end up working with.
If you're not sure, don't decide after 3.5 years. Maybe try a FE specialization for a year or two, a BE one for another year or two, etc. until you find a niche you really enjoy.
For me it took like 15+ years to realize that what I loved was being able to quickly develop UX with an abstracted/serverless backend, using Next.js. But others hate that loss of control and want to work on the parts of the stack that I'm grateful to never have to touch again. YMMV... take time to explore!
* Working with users & designers, rapidly iterating UIs on some bleeding-edge messy ecosystem (React, etc.), dealing with whitespace and color palettes, state management and associated race conditions, and having clearly visible creative output at the end to show for it?
or...
* Working behind the scenes with other techies, vendors, specs and docs, architecting against best (or at least "known good") practices & patterns, enforcing rigidity and consistency and good versioning throughout your APIs, optimizing the hell out of every query, containerizing everything and jumping in and out of DevOps every hour, getting to learn various platforms and stacks in depth in order to produce a stable HTTP endpoint, working with many clouds... all to produce a remarkably well-engineered response that fellow engineers could appreciate but no user will ever see?
You can get a pretty deep, but different, sense of satisfaction from either calling. And these days there is really no end to the depth of specialization you can achieve, only the breadth. Even within "frontend" and "backend" there is already several lifetimes of learning, and the pace of development is only getting faster.
The frontend tends to iterate quicker, fast and furious, while the backend focuses on stability and resilience. The engineering cultures can be different (though not incompatible). In general I think the backend stuff is "harder" in that it's more actual engineering, and tends to get paid better. The frontend stuff is difficult in a different way -- creative and visual, often -- which for some reason companies don't tend to reward as highly. In our culture, engineering is thought of as more difficult than design, unless you're Steve Jobs or similar.
But at the end of the day, either path (or remaining full stack) would easily get you a much-more-than-livable wage at any decent company, so it comes down to things like work-life balance (do you want to be on pagerduty?) and just how much you enjoy each bucket of work, and the kind of people you end up working with.
If you're not sure, don't decide after 3.5 years. Maybe try a FE specialization for a year or two, a BE one for another year or two, etc. until you find a niche you really enjoy.
For me it took like 15+ years to realize that what I loved was being able to quickly develop UX with an abstracted/serverless backend, using Next.js. But others hate that loss of control and want to work on the parts of the stack that I'm grateful to never have to touch again. YMMV... take time to explore!
I have 3.5 YOE and don`t know whether specializing in either of them would be beneficial for my career.