Automate the boring parts of your job | Hacker News Reader

Automate the boring parts of your job

stackoverflow.blog

39 pointstybulewicz16 comments

In my experience in larger software companies, the hardest part of automation is convincing management that it's worth it to stop other development for long enough to automate a problem away. A lot of managers are fine throwing people at a problem if it means meeting a date and making the team look good while under the hood all the knobs are being turned by hands by an ever struggling staff.

And then the worst case I've found myself in is where the people you hire specifically to automate are told to do things manually at first "until we get the automation out." Then you end up in a constant cycle of promising automation that will never exist because all of the workload is falling to the automators who have no time to fix anything.

It actually amazes me the degree to which people just don't realise that what they are doing can be automated - even in software companies.

I caught my manager one day, manually traversing application screens taking screenshots and then clipping them down to size.

At least an hour's work, with each and every release (or at least those with configuration changes).

"Raise a ticket, I can do that automatically."

An hour later I sent her back the task for testing - now taking mere seconds, and with pixel perfect clipping.

It never even occurred to her to ask if that was something I could do.

> "Raise a ticket, I can do that automatically."

Can you elaborate what you did? One option I can think of - Selenium like UI testing\navigation tool and taking screenshots?

It was a swing application (the company's deployment tooling).

I ran through the configuration definitions and for each element created a BufferedImage the preferred size of the associated component.

Then I rendered the component to the BufferedImage using BufferedImage::getGraphics, and Component::paint.

Then I saved the image as <definition>.PNG.

Nothing magical.

Why have we ended up in a place where a developer is asking a manager to raise a ticket so they are allowed to create something only she will see. What happens if you just did it without the ticket?

Could just be so you have a ticket to record time against.

For the commit message, for time-keeping, in order to assign it back to her when the changes were made.

How do i automate going to status update meetings?

Convince your team to use async updates on Slack or whatever.

Or just deepfake your face and voice and give it a new prompt every day.

Having great end-to-end tests are awesome for this exact reason. I spend 99% of my time adding new cool features instead of fixing bugs. While people I work with spend all their time complaining and moaning about all the bugs that keeps popping up in their production code.

Obligatory XKCDs:

- Is It Worth The Time? https://xkcd.com/1205/

- Automation https://xkcd.com/1319/

That is why I went for totally stupid-silly automations.

I don't write "reusable" automations - I don't write scripts with parameters. I write a lot of scripts where I open it in notepad to edit and fill in variables.

Most of the times I just put copies of these scripts on specific servers and have variables filled in.

Variables need to change only if I change server or really change config of a server which is almost never.

This way "Automation" xkcd "Theory" fits reality.

Because then instead of rehearsing commands and what was the configuration I just go to the server and run the script and instead 30mins simple task takes me 2 mins.

XKCD 1319 gets the economics of automation wrong because it makes the assumption that you value the time spent on every activity the same, in particular that you equally value drudge work and programming.

The reality (for me at least, and I’m sure for others) is that I’d much rather be writing a program than doing drudge work.

XKCD 1205 is completely wrong because it fails to account for the fact that manual work tends to introduce random errors into the mix which are difficult to reverse. Whereas if automation is well designed, it's often very possible to correct any errors you made in the automation, and once you get it right it will always be right.

The other thing is that a task that takes 30 seconds doesn't just take 30 seconds, the context switch is actually quite a burden and even just having to remember to do the thing.

With an error rate of 10%

Would you rather have 10% errors each time or 10% of the time the script has an error and could wipe everything out.

Every place I've worked with accepts 10% returns, 10% of visitors leaving immediately, 10% of a customer's data being incorrect somehow.

Very few accept perfect flawless followed by completely breaking everything 1/10 times.

You should be fired if your automation is breaking 10% of the time.

All I'm saying is that the true costs of manual work usually isn't accounted for correctly. I see these costs spiralling into so much wasted work that it starts incurring more and more risk. Preference for gradual decay over Big Bang collapses isn't nessecarily rational, people tend to prefer living next to coal plants than nuclear plants despite the fact they're far far far more likely to die living next to the coal plant. It is in fact that irrational bias which needs to be resisted.

Reply on news.ycombinator.com