I don't agree with this generalization for good communication "In my experience more extroverted and “chaty” engineers have it better on average."
Often times we conflate loud communication with good communication. In my personal experience there are lots of verbose individuals that are poor communicators.
My personal experience with a room full of very smart introverts is that they do not communicate near enough information, or simplify it to the proper level. I assume it is because their expectation of "common knowledge" is much higher.
You don't have any idea what introversion means. Introversion doesn't mean withholding information nor being afraid to speak out loud nor being unable to synthetise information.
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.
You had the opportunity to explain what introversion actually is, but instead this comment is only what it is not. I don't think that's useful if you are actually trying to help the commenter to which you replied.
Indeed. I'm an introvert who is in a leadership position at a large consulting company. My natural inclination is to be quiet unless things are going off the rails. But that doesn't work for the job I have, so I have to put myself out there more and communicate things much more explicitly and clearly than I'd prefer. But I can do it. I can lead calls and projects. I can "charm" CTO's with my ability to understand and breakdown the challenges they are facing. I can be persuasive and an effective mediator. But it's exhausting for me.
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.
> It does not mean to be shy, nor uncomfortable with people.
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.
I was just discussing this with my girl last night. This is technically irrelevant to the overall context but in this specific comment thread, it's hard to figure out how to make content for the general population. I feel a lack of confidence because I surround myself with people who are smarter and better at things than me a lot of the time. So when I want to make them interested in something it's got to be super complex.
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.
> I feel a lack of confidence because I surround myself with people who are smarter and better at things than me a lot of the time.
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.
I look at it as signal to noise ratio. If someone communicates a lot but has a very low signal to noise ratio, parsing what might be valid from everything else, becomes a chore and adds cognitive overhead.
I'm an introvert. I talk a lot, I like being around people but they tire me. The day I'm in the office, I feel like dying in the last hour. Thank god it's 90% WFH.
Because DevOps is systems administrator working with dev team and understanding application that this team is working on.
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.
It really depends, in smaller companies you often have to wear multiple hats - I've had a combined systems administrator/programmer roles, worked in embedded systems programming, done devops roles, now I'm a technical manager.
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.
DevOps is not a role, but a culture inside an organization
I think we need to give up on fighting this fight. The thousands upon thousands of job postings with that job title clearly indicate otherwise.
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."
Like the fight between being called a QA and a tester = "we'll get the QA guy to QA the latest release" - oh, you want the tester to check the release as part of the QA process
It's hard not to agree but this is a total loss. DevOps as a culture works, and what most organizations do doesn't.
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.
Spitballing here but perhaps it's because people don't realise the DevOps work that can be done in a team, rather than just what has to be done.
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.
The problem is that management needs there to be zero slack in the system, or they don't think they're doing their job well enough. I've seen this pattern over and over:
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.
> 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 think you're a lot more optimistic than I am on the number of companies who have gotten QA right.
Grouping the minority of good organizations where DevOps actually means DevOps with the majority of clueless organizations who hire "DevOps engineers" meaning System Administrators is morally and practically wrong.
It's sad and ironic. Organizations that have DevOps as a role often have DevOps teams, which tend to operate in silos, which is the antithesis of DevOps.
> I think we need to give up on fighting this fight. The thousands upon thousands of job postings with that job title clearly indicate otherwise.
> 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.
Most recruiters don't know the difference between C-shell and a seashell, why would you expect them to understand a topic most IT people can't fully grasp?
This saddens me. Part of the blame is on the side of product namings like "Azure DevOps" which indicates to inexperienced devs that this is some kind of operations role if all they ever use are the build and deployment features. Then again, many junior devs start out as devs without ops experience so they don't have much knowledge about end-to-end development in state-of-the-art teams. Some even start out in shitty teams so they never learn much of the established best practices.
Could we get rid of this "junior/senior" crap? I have never worked anywhere it was ever useful. You are a programmer - that's it. The only people that think otherwise are self-agrandising so-called "seniors".
Junior / senior / staff titles are typically used for HR to justify a lower salary (typically called pay band) . It artificially suppresses your salary even though all roles do extremely similar work.
If your staff engineers are doing extremely similar work as your junior engineers, you've either got garbage staff engineers or you're criminally abusing your juniors. It shouldn't be surprising that a developer with a couple decades of real experience work differently and have different areas of focus than someone fresh out of college. This isn't saying that every dev with 20 years of experience is significantly better than fresh out of college devs. But it's crazy to ignore the different experience can make.
I think better terms should be describing general expert/domain expert/company expert.
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.
This is a ridiculous take only justifiable by those who are juniors. I'd agree that Senior+ the titles are mostly meaningless, but the distinction between a junior (Not able to complete full projects independently) and a senior (Able to lead teams / able to solo complete projects) is very needed.
The line between Junior and senior is arbitrary, but there is a difference. The difference is not skill, but experience. And experience cannot be learned from boot camps or man pages.
One additional one I would add is: don't be an ass. I have seen a fair share of people in this role belittle QA, Devs, and interns because they're not able to follow along or understand how to use DevOps tooling.
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.
I try to think about developer experience in my day-to-day. K8s might make deployment for the DevOps team easier but more painful for the devs, and that's not good because they are the ones who make the company money. So work together with the developers if they're complaining to make it possible to ship code as fast as possible. If the devs don't like settings in yaml files, find a way to abstract that away (use standardized naming so there's fewer values they have to care about, give sane defaults that won't be overwritten 90% of the time).
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.
The last one, Focus, is very import. At school, I had time to think and work on two or three different stuff. When I was a junior 'developper' (basically I was developing filters to clean data to feed it to an OCR), I continued doing 2-3 different part at the same time. And then I kept doing it as a devops. This was a mistake. As a devops, you really have to be focused on your subject, you can't afford to half-ass your projects, and the scope is so large you will always forget important details if you continuously jump from project to project. Keep focus, takes notes (temporary or in comments). And communicate. The rest is easy
DRY. Don't contribute to shrapnel infrastructure architecture -- consolidate configuration. Build effective abstractions as an organization. Use terraform only where you have to and use better abstractions everywhere else.
I disagree that there is no place for a junior role. I can spec out tons of projects a reasonably junior person could handle that would take away a lot of "busy" work for me. The problem is this - very few people actively choose DevOps. I've heard it said that DevOps (I started calling it just "ops" because many devops jobs have very little dev) isn't something someone chooses, it's something that just happens to you. For me, one minute I'm volunteering to help out with the builds at a small startup, blink and then 5 years later I'm a DevOps engineer.
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.
> The best "DevOps" I've seen are generalists that can fit in on SRE, Systems/platform engineering, network, security types of teams, etc.
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.
Ah, but it is so difficult to stay focus with all kinds of shit blown up and getting pinged in 10 channels. This is one skill that the military people are super good at.
54 comments
[ 2.7 ms ] story [ 131 ms ] threadOften 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.
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.
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.
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 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.