8 ms·

I've automated large chunks of my job away, but I've never felt that I ended up not having things left to do as a result. There are always more tasks to automat

I've automated large chunks of my job away, but I've never felt that I ended up not having things left to do as a result. There are always more tasks to automate and more problems to solve. I get the impression from these stories that the dishonest part of what the self-automaters are doing is that they could do other tasks and use automation to increase their productivity, but instead chose to keep their productivity the same and relax with the extra downtime.

zyang 8y ago
Just curious, what's in your automation toolbox?
- eindiran 8y ago
  I usually write scripts in Python or Bash, depending on the task. I've had a fair amount of success using a cron for scheduling, but I've come to really enjoy using Jenkins for automated tasks. A lot of tasks make sense to trigger off of events other than the time and Jenkins is quite flexible in that regard.
  - gaius 8y ago
    Some kinds of automation only create more work. Looking at you, Chef.
    - __blockcipher__ 8y ago
      Heh. I’m an intern on the ops team at a small-medium company (just under 150 employees, at least 50 or so engineers, ~$20 mil rev), and we use Chef for configuration management. I’ve observed that some members of the ops team are actually afraid to converge servers. I also find the precedence rules, node variable (?) rules etc to be horrifically confusing. I haven’t worked with Ansible before, but it sounds more similar to how I would implement it if I hacked away at the problem for a few months (my understanding is ansible basically just lets you run arbitrary scripts thru ssh). Being able to have chef integration tests (or are they considered unit tests?) seems really powerful. But holy fuck does Chef have a ton of (what feels to me like) cruft
      - bradknowles 8y ago
        Chef got to where it is today because people used it to build systems at a scale that was simply not feasible before. And as it grew more capable, people built more tooling in and then leveraged that to build even larger systems. So, if you're not building systems at the Netflix or Amazon scale, then Chef might have features and tooling that you don't need -- today. But as you grow and you find you do need those tools, they will be there. I can tell you that Chef was a key part of the system for taking the Raytheon GPS OCX system and letting us build out an entire virtual datacenter in a matter of hours instead of months. Once everything is racked and stacked and cabled together, just press the "Go" button and everything builds itself and installs itself in a fully automated way. If you're not familiar with GPS OCX, that's the next-generation ground control systems for GPS satellites -- both the current generation of satellites that is currently aloft and the next-generation fleet that is being developed. With regards to Ansible, there are many lessons that the Puppet and Chef communities learned years (or decades) ago that are being re-learned yet once again -- like ssh isn't a very scalable communications mechanism when you start talking about handling thousands of servers. The concept of "just let me run my custom scripts everywhere" is a nice one, so long as you're talking about a dozen or so machines, each of which is a unique snowflake "pet". But when you want to start building a cattle farm, that method stops being so useful.
        gaius 8y ago
        there are many lessons that the Puppet and Chef communities learned years (or decades) ago It’s funny because I would say that Chef has yet to fully re-learn what the CFEngine community knew.
        gerbilly 8y ago
        > The concept of "just let me run my custom scripts everywhere" is a nice one, so long as you're talking about a dozen or so machines This is not the recommended way to use Ansible at all. Ansible encourages the use of modules, to perform tasks on the server in an idempotent manner. There are modules[1] for installing packages, creating, 'editing files' and so on. Running custom shell scripts for everything is specifically discouraged in their documentation. [1] https://docs.ansible.com/ansible/latest/modules/modules_by_category.html https://docs.ansible.com/ansible/latest/modules/modules_by_c...
lrem 8y ago
Come to SRE. We are seriously expected to fully automate our job away twice a decade and still manage to just keep growing.
- eindiran 8y ago
  How did you get into SRE? Did you start off as a software engineer and transition over?
  - lrem 8y ago
    Straight out of PhD. The interviews went smoothly in part due to earlier experience in an ISP, but these days Google takes in SREs with 4 x coding and 1 NALSD interview. It's the stuff talked about in https://www.oreilly.com/library/view/the-site-reliability/9781492029496/ch12.html https://www.oreilly.com/library/view/the-site-reliability/97... and there's quite a few Google-organized workshops on this.
- anticensor 8y ago
  Does SRE stand for Site Reliability Engineer?
  - lrem 8y ago
    Yes.
onemoresoop 8y ago
Does "increase their productivity" equate to increase their pay? In most cases that's a no unfortunately. It's up to the "automator" what they make of their time imho. If they're wasting time playing games it's their loss since these opportunities don't come by too often. If they use it to grow their knowledge and skills that's great and well earned since the company only expected them to do their workload, the hard way. And it's fair. And it is only not fair to the peers whose work cannot be automated, and as someone here said, it's a temporary privilege to be working in programming, we're in a different world, higher pay, more learning opportunities, more leverage than other jobs. But, nothing lasts forever. We're going to be automated away eventually.
- gitgud 8y ago
  I agree it's a privilege to have the ability to automate your job. The programmer who has extra time from automating his jobs has a choice on how to spend that time. - Waste it playing games - Learn other skills - Work on other side projects Only the first option is negative to the employer.
gerbilly 8y ago
>I get the impression from these stories that the dishonest part of what the self-automaters are doing is that they could [...] increase their productivity, but instead chose to keep their productivity the same I get the impression that the dishonest thing the employers are doing when they become aware of the automation is that they could increase the person's salary, but instead they keep it the same...

zyang 8y ago

Just curious, what's in your automation toolbox?

eindiran 8y ago
I usually write scripts in Python or Bash, depending on the task. I've had a fair amount of success using a cron for scheduling, but I've come to really enjoy using Jenkins for automated tasks. A lot of tasks make sense to trigger off of events other than the time and Jenkins is quite flexible in that regard.
- gaius 8y ago
  Some kinds of automation only create more work. Looking at you, Chef.
  - __blockcipher__ 8y ago
    Heh. I’m an intern on the ops team at a small-medium company (just under 150 employees, at least 50 or so engineers, ~$20 mil rev), and we use Chef for configuration management. I’ve observed that some members of the ops team are actually afraid to converge servers. I also find the precedence rules, node variable (?) rules etc to be horrifically confusing. I haven’t worked with Ansible before, but it sounds more similar to how I would implement it if I hacked away at the problem for a few months (my understanding is ansible basically just lets you run arbitrary scripts thru ssh). Being able to have chef integration tests (or are they considered unit tests?) seems really powerful. But holy fuck does Chef have a ton of (what feels to me like) cruft
    - bradknowles 8y ago
      Chef got to where it is today because people used it to build systems at a scale that was simply not feasible before. And as it grew more capable, people built more tooling in and then leveraged that to build even larger systems. So, if you're not building systems at the Netflix or Amazon scale, then Chef might have features and tooling that you don't need -- today. But as you grow and you find you do need those tools, they will be there. I can tell you that Chef was a key part of the system for taking the Raytheon GPS OCX system and letting us build out an entire virtual datacenter in a matter of hours instead of months. Once everything is racked and stacked and cabled together, just press the "Go" button and everything builds itself and installs itself in a fully automated way. If you're not familiar with GPS OCX, that's the next-generation ground control systems for GPS satellites -- both the current generation of satellites that is currently aloft and the next-generation fleet that is being developed. With regards to Ansible, there are many lessons that the Puppet and Chef communities learned years (or decades) ago that are being re-learned yet once again -- like ssh isn't a very scalable communications mechanism when you start talking about handling thousands of servers. The concept of "just let me run my custom scripts everywhere" is a nice one, so long as you're talking about a dozen or so machines, each of which is a unique snowflake "pet". But when you want to start building a cattle farm, that method stops being so useful.
      - gaius 8y ago
        there are many lessons that the Puppet and Chef communities learned years (or decades) ago It’s funny because I would say that Chef has yet to fully re-learn what the CFEngine community knew.
      - gerbilly 8y ago
        > The concept of "just let me run my custom scripts everywhere" is a nice one, so long as you're talking about a dozen or so machines This is not the recommended way to use Ansible at all. Ansible encourages the use of modules, to perform tasks on the server in an idempotent manner. There are modules[1] for installing packages, creating, 'editing files' and so on. Running custom shell scripts for everything is specifically discouraged in their documentation. [1] https://docs.ansible.com/ansible/latest/modules/modules_by_category.html https://docs.ansible.com/ansible/latest/modules/modules_by_c...

lrem 8y ago

Come to SRE. We are seriously expected to fully automate our job away twice a decade and still manage to just keep growing.

eindiran 8y ago
How did you get into SRE? Did you start off as a software engineer and transition over?
- lrem 8y ago
  Straight out of PhD. The interviews went smoothly in part due to earlier experience in an ISP, but these days Google takes in SREs with 4 x coding and 1 NALSD interview. It's the stuff talked about in https://www.oreilly.com/library/view/the-site-reliability/9781492029496/ch12.html https://www.oreilly.com/library/view/the-site-reliability/97... and there's quite a few Google-organized workshops on this.
anticensor 8y ago
Does SRE stand for Site Reliability Engineer?
- lrem 8y ago
  Yes.

onemoresoop 8y ago

Does "increase their productivity" equate to increase their pay? In most cases that's a no unfortunately. It's up to the "automator" what they make of their time imho. If they're wasting time playing games it's their loss since these opportunities don't come by too often. If they use it to grow their knowledge and skills that's great and well earned since the company only expected them to do their workload, the hard way. And it's fair. And it is only not fair to the peers whose work cannot be automated, and as someone here said, it's a temporary privilege to be working in programming, we're in a different world, higher pay, more learning opportunities, more leverage than other jobs. But, nothing lasts forever. We're going to be automated away eventually.

gitgud 8y ago
I agree it's a privilege to have the ability to automate your job. The programmer who has extra time from automating his jobs has a choice on how to spend that time. - Waste it playing games - Learn other skills - Work on other side projects Only the first option is negative to the employer.

gerbilly 8y ago

>I get the impression from these stories that the dishonest part of what the self-automaters are doing is that they could [...] increase their productivity, but instead chose to keep their productivity the same I get the impression that the dishonest thing the employers are doing when they become aware of the automation is that they could increase the person's salary, but instead they keep it the same...