Some advice I would give to a junior DevOps Engineer
oschvr.com
oschvr.com
DevOps is not a role, but a culture inside an organization
Better to accept that the philosophical battle has been lost and that DevOps Engineer is the new name for other titles like "System Administrator", "Infrastructure Engineer", "Operations Engineer", or "Site Reliability Engineer".
e.g. "The person responsible for dealing with making sure there is a way for the software to run somewhere and that it stays running."
Why is it so hard to embed these specialists in a vertical team and bring that cultural change? My guess is that they have two work streams and effectively two people to report to: The team leader, and their own manager/director.
I think this is a problem for businesses since it complicates traditional hierarchies in ways they are not prepared to deal with.
A counter example is QA, that does more often get embedded within a team and promotes a quality first mindset - why get this right and not DevOps? I'm confused.
I work in a cultural DevOps place at the moment, and often spend my time improving CI workflows, improving the local dev environment and upgrading dev tools to make it easier to write features when requests come in. I could easily spend my entire week doing things like this, and it seems to pay off as we have a very low cycle time and fix bugs within minutes.
However if you have a non-technical manager - they struggle to see value in this work. DevOps becomes "the way we get the project we built into our production environment" which is usually quite a small piece of work compared to actually building the project. So it becomes - we don't need one per team, hmm, maybe they should be centralised so we can share their time between teams, and then you lose the culture DevOps was supposed to create.
1) a new vertical team is created, including seasoned devs and ops hands, a bulldog of a PM, maybe a business analyst and QA as well
2) the team is successful, creating a new product that legitimately brings value
3) executives want a new line of business and so spin up a new dev team, but figure they can do it on the cheap by having the old team's QA/PM/Ops folks work for the new team too.
4) this happens a few times and now we've spun out the support functions to separate teams with their own managers
5) we're back at square 0
Why do they do this? Because they need to increase "efficiency" in order to justify their existence. They're managers, after all, so they can't directly produce value. Their only hope is to increase the efficiency with which work gets done. The problem is that a maximally efficient team/system is a minimally resilient one, and there's no one in the org who thinks their job is to promote resiliency. There's also the problem that showing an "efficiency" like one guy doing the job of three is concrete and easy to prove. An increase in systems-level efficiency -- by having three people doing three jobs and therefore not blocking any of the other expensive professionals on those teams -- is seen as as theoretical and largely hokum.
I don't know that there is a solution to this really. Even bronze age militaries experienced similar dynamics, so I'm not hopeful we can solve it by doing "agile". Also, sometimes they are right: there really isn't enough ops work on a vertical team to justify a whole full-time employee, and they really can produce more value consulting for multiple teams. I find that this is rare though, and takes a special person who is adept at context-switching. Most people aren't, and I don't know of a repeatable way of training or identifying these people, so it isn't a practical strategy for big orgs who need these things at scale.
I think you're a lot more optimistic than I am on the number of companies who have gotten QA right.
DevOps these days is sysop+better scripting and less iron
> Better to accept that the philosophical battle has been lost and that DevOps Engineer is the new name for other titles like "System Administrator", "Infrastructure Engineer", "Operations Engineer", or "Site Reliability Engineer".
As soon as I had a recruiter ask me "why are you looking to write software if you're DevOps?" incredulously on the phone I knew that there was no coming back from this. The fact that somebody whose literal job it is to have a good grasp of the technical labor market thinks that somebody can "be DevOps" (just because they have Kubernetes on their resume... never mind the slew of languages and frameworks) and that being such is orthogonal to software development is an unfortunate state of affairs.
Often times we conflate loud communication with good communication. In my personal experience there are lots of verbose individuals that are poor communicators.
It does not mean to be shy, nor uncomfortable with people. Introversion does not mean exhibiting symptoms of autism either, which might be what you are talking about with "simplify at the proper level" (?).
Introversion and extroversion have absolutely nothing to do with the quality of a software engineer or its documentation. I just wish this label would just die, given how its misunderstood and misconstrued.
I spend most of my working day talking to people, and at the end of the work day I'm done with people and need to spend a significant time alone in my head to recharge. I doubt that any of the folks I work with would describe me as an introvert because the nature of my work doesn't allow me to fall into the comfortable isolation I'd prefer. At the same time, I can't have the impact that I do if I was the stereotypical "introvert" engineer which is what makes all the effort worthwhile. The biggest challenge with this is my intolerance for people extends to friends and family after work. A day full of meetings and I can't focus on conversations my wife tries to pull me into and I have zero desire to hang out with any friends. I literally need time alone to recover.
After a long day I tend to zone out and my partner tells me it's like they're talking to a wall.
introvert - noun - a shy, reticent person. [0]
At any rate, your comment is a pretty good example of what I'm talking about. Even if where I get my idea of it is off course from yours, you immediately become seemingly quite offended and start arguing your point in depth on trying to change what I understand as being a pretty global understanding of a word. You even kind of argue at the end that it is common usage.
[0] Oxford Languages via Google
At the same time I see people watching a tutorial telling them how to put their OpenAI API key into a mass-adopted bot platform and getting "It's really cool you can do these kinds of things!" which is what started the conversation. Like it's cool they're trying, no shade to them but my baseline of what most people will think is interesting is so distorted.
It's not feasible in a number of organizations, but things like this are why it's important for developers to interact with the users of the software that they create. You learn so much more about what works and doesn't work for the users. You learn their vocabulary and assumptions about using apps which is often quite different from "power users" like we tend to be.
Extroverts get energy from talking to people, so they are likely to do it more
Introverts are the opposite.
An introvert can talk more than an extrovert.
This is especially true for juniors because they cannot fix stuffs quickly, so it's better to talk their thoughts loudly in the incident channel.
In contrast with systems administrator who does only "server stuff" and gets zip file with application thrown over the fence from dev team or multiple dev teams without understanding anything of what is in those app packages.
The majority of "devops" people I have worked with can't program their way out of a paper bag.
Meanwhile back in the 1990's we had system administrators that knew how to program in shell, C/C++, Perl, use a CI/CD system, and debug shared library symbol issues with ease that would leave your average devops (or even web or Java developer) blushing.
What you are referring to as "system administrator" today, is not what it was in the past. And what you are referring to as "devops" today ... is not all that.
I would give juniors this advice:
Do not pigeonhole yourself into a particular role. The best "DevOps" I've seen are generalists that can fit in on SRE, Systems/platform engineering, network, security types of teams, etc. Same goes with technology. If you find yourself early on spending 2 years working on nothing but Jenkins and CI/CD pipelines, guess what your next job is gonna be about. Challenge yourself, always be learning a new thing. If you don't like learning, or can't learn fast, this isn't the job for you. If you don't like potentially brutal on-call schedules, this isn't the job for you. If you don't like mostly thankless work that is invisible if you are doing it correctly, this isn't the job for you. Also look at job postings frequently and see what companies are asking for proficiency in and make sure you at least are somewhat competent in those areas.
Also I wish more DevOps had more of a CS background. I can't tell you how many times I've seen multiple senior DevOps looking at a machine that is clearly and very obviously thrashing and have no idea what they're looking at.
Just wanted to emphasize this. Additionally I'd say that every developer should be able to build DevOps pipelines. There is no make file engineer whose entire job is to write make files for other folks projects. There's no compiler engineer who takes the code from other devs to compile it for them. These, like devops, are fundamental skills a developer needs to know to be effective in modern dev teams. A developer who can't automate the build and deployment of their code is at a huge disadvantage.
DORA metrics don't mean anything if we are underperforming as a company and losing money.
I like to think of the role as hospitality; you don't particularly have to like the guest but try to create a good working atmosphere.
A specific example: if a particular dev runs to you every time a build fails and tries to blame the environment: force them to check their own work first. If there's another branch that builds, ask if it's related to one of the changes in this branch. Ask if the code builds locally. Ask them what they've tried so far to debug the issue. These questions will help out anyone who does not know how to actually troubleshoot build failures and discourage anyone who is simply trying to pawn off their work.
Why do we need a two month lead time now to ship a new static page?
How could we have drifted so far that we need kubernetes for that?
How is it possible that we need a platform team to build yet another later of abstraction from our cloud providers?
Why do we have more yaml than the code we're shipping?
The DevOps team's sole existence is there to enable developers to ship better code faster. If DevOps practices are preventing this, that needs to be addressed.
I left.
I'll say it takes 3 to 18 months to become a domain expert at a company depending on the scope, if you are fresh out of school. Less if you already have relevant experience. And then years to become company/subject expert, and those you have to pay to keep them.