10
Switching from DevOps to backend
(programming.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 02 Aug 2023
10 points (100.0% liked)
CSCareerQuestions
928 readers
2 users here now
A community to ask questions about the tech industry!
Rules/Guidelines
- Follow the programming.dev site rules
- Please only post questions here, not articles to avoid the discussion being about the article instead of the question
Related Communities
- !programming@programming.dev - a general programming community
- !no_stupid_questions@programming.dev - general question community
- !ask_experienced_devs@programming.dev - for questions targeted towards experienced developers
Credits
Icon base by Skoll under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
Devops is not a position in itself. It's supposed to be a software development and operations philosophy.
I suppose you are trying to say this is a operations heavy position. And you are not interested in operating systems. And that's cool. You don't need to unless you want to. But if you really want to be a good, or better than good developer, it's great to know about the systems. How they are operated, how they are constructed, how operators think.
So to answer your question yes. However is that the best way for you? Only you can answer that.
This is the definition I know but unfortunately the term seems to have become a modern synonym for system admin/engineer.
Such a role might still provide valuable experience for a backend dev if there’s an opportunity to write production code for internal tools as well.
Developers at my company need to have a deep understanding of the environments they deploy onto (microservices, scheduled workflows, etc.) which can include configuring canary testing, rolling deployments, status probes, setting up and using monitoring, and very occasionally intervening to restart or redeploy running software. But these are secondary skills compared to writing code.
True, but the distinction still holds value. If a company has a DevOps role defined, you can derive from that what kind of a company you are joining. For example, they hire based on marketing and not based on merits, which tells you something about the colleagues you can expect to be working with. It also tells you about how they structure work and that hierarchy and bureaucracy may play a bigger part in getting your work done than you might like.
Good point and an interesting take. As you said this could be a good signal, when taken in context with the other limited information we get as employment candidates, about internal development practices.