Ask HN: Should I be specializing in either front end or back end as full-stack?

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.

> 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.

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.