Ask HN: Should I be specializing in either front end or back end as full-stack?
I am not so sure whether to fully specialize in either of them since both, the frontend and backend are too interesting and have challenging problems.
I have 3.5 YOE and don`t know whether specializing in either of them would be beneficial for my career.
42 comments
[ 3.5 ms ] story [ 108 ms ] threadSo what I really meant was more money and interesting job
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.
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'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.
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).
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.
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.
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.
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"?
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.
I meant to say what really makes it full stack, but it's too late to edit
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.
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.
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.
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.
> 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.
Could be that people joining SRE as juniors might not see that much of a difference.
We're still writing code in 2022.
https://www.youtube.com/watch?v=duJwGSUhRQA
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
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 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.
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.
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.
* 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!