3 ms·

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 va

by iasay 4y ago

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.

arvinsim 4y ago
But the hours are horrible, right?
- iasay 4y ago
  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.
- gwbas1c 4y ago
  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.
diordiderot 4y ago
What would the curriculum for operations be?
- iasay 4y ago
  Well basically AWS at the moment. The art is to know which bandwagon to jump on next.
- gonzo41 4y ago
  Devops stuff, containers, configuration management and software defined networking. And change management!
alexjplant 4y ago
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.
charlie0 4y ago
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.

by iasay 4y ago

arvinsim 4y ago

But the hours are horrible, right?

iasay 4y ago
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.
gwbas1c 4y ago
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.

diordiderot 4y ago

What would the curriculum for operations be?

iasay 4y ago
Well basically AWS at the moment. The art is to know which bandwagon to jump on next.
gonzo41 4y ago
Devops stuff, containers, configuration management and software defined networking. And change management!

alexjplant 4y ago

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.

charlie0 4y ago

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.