3 ms·

> Really? As a dev, the vast majority of my projects/roles have required all 3 to some extent. I can run photoshop and mock some images at home and it's good e

> Really? As a dev, the vast majority of my projects/roles have required all 3 to some extent. I can run photoshop and mock some images at home and it's good enough, but does that make me a photoshop guru? I think not. edit: bad example.

morgante 10y ago
> To some extent maybe, but running something on a heroku engine Talk about a straw man. I would agree with you that deploying to Heroku hardly constitutes ops. I'm talking about things like running a multi-AZ Kubernetes cluster.
- llama052 10y ago
  Following a guide online and getting something online is different from running something in production that a company relies on. Learning a infrastructure piece thoroughly can take months alone in resilience testing, failover testing, and system design/architecture choices. It's a huge fallacy in the infrastructure side of things that because something "works" means it's setup correctly, and that couldn't be further from the truth. You'll get an environment built on technical debt. Outages will occur and you'll be playing sysadmin full time before long. You won't be a developer at this point anymore, you'll be the sysadmin/ops role of your company. I've seen this happen at multiple companies, and I doubt this is the last time I will see it happen.
  - morgante 10y ago
    You continue to be extremely insulting and making significant assumptions about my experience. What shibboleth do I have to provide to prove that I know what I'm doing? This inherent assumption that other people don't know anything is incredibly damaging to the industry: I don't assume a SRE is an incompetent programmer, so you shouldn't assume I am barely competent at ops. > Following a guide online and getting something online is different from running something in production that a company relies on Where did I say that I had simply "followed a guide online" instead of "putting something in production." Like I said in my original comment, I have been the primary on call engineer for multiple projects with millions of users. Despite that, I still find time to develop new features and push the product forward. Yes, I occasionally deal with outages/failures and have to write some new automation to remediate them. But that doesn't make me a full-time sysadmin. I don't really feel like engaging with you further, since you're apparently more interested in arguing with a straw man of your own construction.
    - llama052 10y ago
      > You continue to be extremely insulting and making significant assumptions about my experience. What shibboleth do I have to provide to prove that I know what I'm doing? This inherent assumption that other people don't know anything is incredibly damaging to the industry: I don't assume a SRE is an incompetent programmer, so you shouldn't assume I am barely competent at ops. My mistake for projecting, the comment you posted about sysadmin age being dead gave me the opinion that you think infrastructure is just something you can deploy and forget, again my mistake. I also spoke in my original message that some 10x engineers can do both, but they are not the majority. I guess you're a 10x full stack engineer then. > Like I said in my original comment, I have been the primary on call engineer for multiple projects with millions of users. That's great, so you're a developer, and operations engineer then (devops)? Do you think that developers should be expected to do both? Genuinely curious
      - morgante 10y ago
        > My mistake for projecting, the comment you posted about sysadmin age being dead gave me the opinion that you think infrastructure is just something you can deploy and forget, again my mistake. I didn't mean to imply that. The "who is not also a strong programmer" part of my comment is important. Of course infrastructure breaks, but in the modern era we have the tooling that your next step should be figuring out how to automate things so that never happens again. > Also looking at your linkedin on your profile led me to believe that you worked with small niche infrastructure setups that don't need to scale. I'm not sure where you got that from. As much as people on HN hate Business Insider, it's hardly a "niche" site. And for the record it's not even the biggest site I've worked on. > I also spoke in my original message that some 10x engineers can do both, but they are not the majority. I agree that the majority of engineers can't do both, but I also don't think it's only small minority who can. Infrastructure is just another skill-set that some engineers can/do build. > That's great, so you're a developer, and operations engineer then (devops)? I wouldn't call myself an "operations engineer" but I've done quite a bit of devops work. > Do you think that developers should be expected to do both? Genuinely curious I don't think every engineer should be expected to do both, but I do think at least one developer on every team should have DevOps experience and be capable of coaching the rest of the team. The role of ops teams (if they still exist) should be primarily in building tools/frameworks for the embedded DevOps engineers to use. From that perspective it's much closer to a traditional internal tools team than a traditional ops team.

morgante 10y ago

> To some extent maybe, but running something on a heroku engine Talk about a straw man. I would agree with you that deploying to Heroku hardly constitutes ops. I'm talking about things like running a multi-AZ Kubernetes cluster.

llama052 10y ago
Following a guide online and getting something online is different from running something in production that a company relies on. Learning a infrastructure piece thoroughly can take months alone in resilience testing, failover testing, and system design/architecture choices. It's a huge fallacy in the infrastructure side of things that because something "works" means it's setup correctly, and that couldn't be further from the truth. You'll get an environment built on technical debt. Outages will occur and you'll be playing sysadmin full time before long. You won't be a developer at this point anymore, you'll be the sysadmin/ops role of your company. I've seen this happen at multiple companies, and I doubt this is the last time I will see it happen.
- morgante 10y ago
  You continue to be extremely insulting and making significant assumptions about my experience. What shibboleth do I have to provide to prove that I know what I'm doing? This inherent assumption that other people don't know anything is incredibly damaging to the industry: I don't assume a SRE is an incompetent programmer, so you shouldn't assume I am barely competent at ops. > Following a guide online and getting something online is different from running something in production that a company relies on Where did I say that I had simply "followed a guide online" instead of "putting something in production." Like I said in my original comment, I have been the primary on call engineer for multiple projects with millions of users. Despite that, I still find time to develop new features and push the product forward. Yes, I occasionally deal with outages/failures and have to write some new automation to remediate them. But that doesn't make me a full-time sysadmin. I don't really feel like engaging with you further, since you're apparently more interested in arguing with a straw man of your own construction.
  - llama052 10y ago
    > You continue to be extremely insulting and making significant assumptions about my experience. What shibboleth do I have to provide to prove that I know what I'm doing? This inherent assumption that other people don't know anything is incredibly damaging to the industry: I don't assume a SRE is an incompetent programmer, so you shouldn't assume I am barely competent at ops. My mistake for projecting, the comment you posted about sysadmin age being dead gave me the opinion that you think infrastructure is just something you can deploy and forget, again my mistake. I also spoke in my original message that some 10x engineers can do both, but they are not the majority. I guess you're a 10x full stack engineer then. > Like I said in my original comment, I have been the primary on call engineer for multiple projects with millions of users. That's great, so you're a developer, and operations engineer then (devops)? Do you think that developers should be expected to do both? Genuinely curious
    - morgante 10y ago
      > My mistake for projecting, the comment you posted about sysadmin age being dead gave me the opinion that you think infrastructure is just something you can deploy and forget, again my mistake. I didn't mean to imply that. The "who is not also a strong programmer" part of my comment is important. Of course infrastructure breaks, but in the modern era we have the tooling that your next step should be figuring out how to automate things so that never happens again. > Also looking at your linkedin on your profile led me to believe that you worked with small niche infrastructure setups that don't need to scale. I'm not sure where you got that from. As much as people on HN hate Business Insider, it's hardly a "niche" site. And for the record it's not even the biggest site I've worked on. > I also spoke in my original message that some 10x engineers can do both, but they are not the majority. I agree that the majority of engineers can't do both, but I also don't think it's only small minority who can. Infrastructure is just another skill-set that some engineers can/do build. > That's great, so you're a developer, and operations engineer then (devops)? I wouldn't call myself an "operations engineer" but I've done quite a bit of devops work. > Do you think that developers should be expected to do both? Genuinely curious I don't think every engineer should be expected to do both, but I do think at least one developer on every team should have DevOps experience and be capable of coaching the rest of the team. The role of ops teams (if they still exist) should be primarily in building tools/frameworks for the embedded DevOps engineers to use. From that perspective it's much closer to a traditional internal tools team than a traditional ops team.