A lot of companies are focusing on hiring "short fat" engineers. Especially companies having "dev ops" engineering model, where engineers must be able to work on all stages of the product lifecycle - from design, development, testing, to deployment and operations.
> Especially companies having "dev ops" engineering model, where engineers must be able to work on all stages of the product lifecycle - from design, development, testing, to deployment and operations.
This is what DevOps is _supposed_ to be but often not what "DevOps Engineers" are hired to be. In my experience most companies hire DevOps Engineers that are one of two things:
1) Sysadmins that also know Python and whichever public cloud dominates the vertical the company operates in
2) Developers that don't actually develop but spend all of their time managing CI/CD pipelines, SCM, JIRA, etc.
In either case their roles are obviously secondary to the developers that build actual solutions; they are the mechanics for the software engineers, which inherently means that their contribution to the value stream is not holistic and it's just another way of enforcing the traditional dichotomy between people that build solutions (developers) and people that keep them from falling over (operations).
I've held the title of "DevOps Engineer" at least once professionally and when I would talk to recruiters or new employers about a software engineering position they'd often ask me what "got me into DevOps" or why I'm trying to "get back into coding". If you know and like working with dev tools and infrastructure then my advice to you is to be a Software Engineer that does DevOps, not a "DevOps Engineer".
Some would see this as a cynical take, but I’ve experienced it so many times, and am feeling such burnout from it that I started pondering this week if I’d be better served applying directly to developer roles instead of anything to do with DevOps; seems no one but the most highest of highly functioning teams seem to grok it. Wonder if that makes me a cynic. Would a cynic admit to being a cynic? Probably.
Anyway.
Nice little coincidence seeing your comment suggesting exactly the same thing. Of course, google just calls those people “SREs”...which in the best of worlds is a “Site Reliability Engineer”, in past orgs though it’s really meant “Sometimes Responsible for Everything”
I don't think it's cynical at all... it's just an unfortunate reality. New things come along and people try to fit them into existing frameworks. Words' meanings evolve over time. People that don't actually do technical work often end up being responsible for placing and managing the people that do; sometimes their notions of roles and responsibilities don't align with ours.
> I’ve experienced it so many times, and am feeling such burnout from it that I started pondering this week if I’d be better served applying directly to developer roles instead of anything to do with DevOps
I, too, am glad to see that I'm not the only one that's had this experience. I wish you the best of luck in "breaking the cycle". Hang tough!
"Full stack" (for whatever definition) is valued because it cuts down on coordination costs, but you may run into limits of what you can expect one person to know. Interestingly, as I've had to hire some "skinny" specialists, my Kanban board has gotten wider to coordinate between them.
Agree - most job postings I see call for experience with an ever-increasing number of disparate technologies. And full-stack web development necessitates it until you've grown the team to a large size.
yes it's true. as someone who's a generalist, every interview I've been to asks me very specific things about one programming language / tech stack. Even though I'm underpaid, I enjoy continuing doing my "short fat" engineering at my current job getting to touch many technologies and focusing on solving the problems at hand rather than specializing in one.
A lot of companies are focusing on hiring "short fat" engineers. Especially companies having "dev ops" engineering model, where engineers must be able to work on all stages of the product lifecycle - from design, development, testing, to deployment and operations.