5 ms·

Some advice I would give to a junior DevOps Engineer

31 points by donutshop 3y ago

donutshop 3y ago
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.
- scrapcode 3y ago
  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.
  - jiscariot 3y ago
    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.
  - sph 3y ago
    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.
    - buggy6257 3y ago
      That was a lot of words telling us all what introversion isn’t, but not a single word telling us what you think it actually is. Care to try again?
    - hiatus 3y ago
      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.
      - tstrimple 3y ago
        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.
        donutshop 3y ago
        Same. I could totally relate. Comfortable isolation sounds blissful. After a long day I tend to zone out and my partner tells me it's like they're talking to a wall.
    - 3y ago
  - chankstein38 3y ago
    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.
    - tstrimple 3y ago
      > 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.
- zht 3y ago
  Introversion vs extroversion is more about how you recharge 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.
  - orwin 3y ago
    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.
- markus_zhang 3y ago
  I do believe that more communication (even useless ones such as "I have completed stage 1 and now moving to stage 2) are better than less or none. 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.
nineteen999 3y ago
None of those skills listed are any more "DevOps" than they are systems administrator, systems programmer, embedded programmer etc.
- deleted 3y ago
  [deleted]
- ozim 3y ago
  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.
  - nineteen999 3y ago
    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.
spicyusername 3y ago
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."
- philk10 3y ago
  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
  - pavlov 3y ago
    "I've got a great idea for an app. Just need a coder to code the codes"
  - Bilal_io 3y ago
    That's why we use Quality Engineer (QE) at my job
- lucasyvas 3y ago
  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.
  - tennis_80 3y ago
zabzonk 3y ago
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".
- SamuelAdams 3y ago
  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.
  - tstrimple 3y ago
    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.
    - orwin 3y ago
      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.
  - blackmesaind 3y ago
    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.
- 3y ago
BeastMachine 3y ago
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.
- donutshop 3y ago
  The siloing causes tons of issues from what I have observed. 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?
  - BeastMachine 3y ago
    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.
Always42 3y ago
after "DevOps is not a role, but a culture inside an organization" and "If we’re going to use it as a role, it’s not an entry level role" I left.
orwin 3y ago
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
JohnMakin 3y ago
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.
- tstrimple 3y ago
  > 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.
- RyeCombinator 3y ago
  To be blunt I wished more DevOps had common sense. DORA metrics don't mean anything if we are underperforming as a company and losing money.
waffletower 3y ago
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.
markus_zhang 3y ago
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.

31 points by donutshop 3y ago

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.

scrapcode 3y ago
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.
- jiscariot 3y ago
  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.
- sph 3y ago
  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.
  - buggy6257 3y ago
    That was a lot of words telling us all what introversion isn’t, but not a single word telling us what you think it actually is. Care to try again?
  - hiatus 3y ago
    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.
    - tstrimple 3y ago
      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.
      - donutshop 3y ago
        Same. I could totally relate. Comfortable isolation sounds blissful. After a long day I tend to zone out and my partner tells me it's like they're talking to a wall.
  - 3y ago
- chankstein38 3y ago
  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.
  - tstrimple 3y ago
    > 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.
zht 3y ago
Introversion vs extroversion is more about how you recharge 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.
- orwin 3y ago
  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.
markus_zhang 3y ago
I do believe that more communication (even useless ones such as "I have completed stage 1 and now moving to stage 2) are better than less or none. 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.

nineteen999 3y ago

None of those skills listed are any more "DevOps" than they are systems administrator, systems programmer, embedded programmer etc.

deleted 3y ago
[deleted]
ozim 3y ago
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.
- nineteen999 3y ago
  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.

spicyusername 3y ago

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."

philk10 3y ago
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
- pavlov 3y ago
  "I've got a great idea for an app. Just need a coder to code the codes"
- Bilal_io 3y ago
  That's why we use Quality Engineer (QE) at my job
lucasyvas 3y ago
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.
- tennis_80 3y ago

zabzonk 3y ago

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".

SamuelAdams 3y ago
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.
- tstrimple 3y ago
  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.
  - orwin 3y ago
    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.
- blackmesaind 3y ago
  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.
3y ago

BeastMachine 3y ago

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.

donutshop 3y ago
The siloing causes tons of issues from what I have observed. 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?
- BeastMachine 3y ago
  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.

Always42 3y ago

after "DevOps is not a role, but a culture inside an organization" and "If we’re going to use it as a role, it’s not an entry level role" I left.

orwin 3y ago

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

JohnMakin 3y ago

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.

tstrimple 3y ago
> 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.
RyeCombinator 3y ago
To be blunt I wished more DevOps had common sense. DORA metrics don't mean anything if we are underperforming as a company and losing money.

waffletower 3y ago

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.

markus_zhang 3y ago

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.