← Back to context

Comment by k__

20 days ago

Yeah, but I studied with a bunch of guys who said they'd go into IT, because they hated coding.

You can hate coding and be an excellent network engineer or even DBA.

I'm an infrastructure guy and I learned to code, but I don't code today. The other poster who talked about good people in the old days using Perl and suchlike tools is right. Competent people care about automation.

But there are all sorts of automation tools that don't require knowing how to write object oriented code or do a ton of code reviews. Terraform is one - it's yaml, and the complexity is one of design patterns. Another is Ansible. GitHub Actions. Many many more.

Let me throw out a grenade. Software developers often over estimate their capabilities in technology. Because a person is an expert in Ruby or Go, and on the weekend they stood up a hosted app on ECS, now magically they're geniuses and understand DevOps.

False. DevOps engineering, network engineering, DBA, and a lot of other non-developer jobs take 5-10 years to get right.

Hopefully I've slammed our Leetcode hiring practices, but really I'm just venting at this point.

  • It’s a red flag anytime I see a company with a dedicated “database administrator” usually they want you to put all of your business logic in stored procedures and have a dozen GetCustomer_n copies for versioning.

    What can a modern operations person do that can automated anything via coding?

    BTW: I am “expert” in cloud by any definition (did at a startup, worked at AWS ProServe, staff consultant at a 3rd party consulting company) and I develop. How hard do you really think it is for someone with a developer mindset to learn how system design works at scale and bring their same developer mindset to infrastructure as code?

    It took me exactly 2.5 years from opening the AWS console for the first time to being hired at AWS.

    Everyone in my division at my current company at my level can hold their own as either a developer or a “senior cloud engineer”. We just find infrastructure babysitting incredibly boring

    Half the reason I learned cloud was not because I didn’t want to manage servers - I didn’t want to deal with server administrations.

    • >BTW: I am “expert” in cloud by any definition (did at a startup, worked at AWS ProServe, staff consultant at a 3rd party consulting company) and I develop. How hard do you really think it is for someone with a developer mindset to learn how system design works at scale and bring their same developer mindset to infrastructure as code?

      It depends! Do you mean clicking in the AWS console and spinning up infrastructure? It takes a few days.

      Learning terraform/CloudFormation so it's repeatable? Probably a few weeks.

      Kubernetes design patterns and troubleshooting? I feel like it takes at least a few months of hands on and theoretical.

      To build infrastructure that lasts, is monitored with an APM as well as infrastructure specific tooling (not Cloudwatch) has cost dashboards set up to account for workloads across a dozen product lines (not Cost Explorer), has a CI CD pipeline automation for hundreds of repos including automatic onboarding of new ones, understands cloud security enough to have designed a tight perimeter with some automation around detection and remediation, has strong network level knowledge and knows how to deal with external vendor/client connectivity options (since you have to adapt to their limitations or demands)... Instead of server babysitting, you know in advance how to prepare the inevitable situation where workloads need to scale, and already have tooling and horizontal and vertical auto scaling either automated or ready to go...

      If you know these things after 2.5 years, and I say this fully seriously, you are in some sort of .5 percent elite in this industry and deserve something like 1M a year, or you should be leading something huge.

      Otherwise there's a risk here that you don't know what you don't know, which was my original point about over confidence by software engineers when it comes to infrastructure.

      2 replies →