Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning to code vs. learning to automate

daedtech.com

Post reply on HN
Print view View original

71–80 of 190 posts

Re: Learning to code vs. learning to automate

#71

Post by andrepd »

rurcliped wrote: post #68

The problem often isn't ability to automate. It's that the workers closest to the problem have an overwhelming disincentive to automate. Suppose I have a low-level job in Peloton operations. Our Phalange Team must ensure that, before a bike's in-home delivery date is confirmed, the delivery technician has placed an internal order for a left phalange. Each of us spends all day navigating between the Sales app and the…

>4. If I successfully automate it, all of my coworkers lose their jobs.

A failure of capitalism when less work and more productivity is a bad thing.

Re: Learning to code vs. learning to automate

#72

Post by carapace »

ethbro wrote: post #21

Obligatory RPA: GUI-based automation to mimic user interactions, leveraging existing application and web GUIs as an API to automate against. Not something I'd recommend to backend developers / data crews. But it's pretty awesome stuff for non-developer, front-line business users. What is RPA? - https://www.uipath.com/rpa/robotic-process-automation UiPath free, "unlimited time for non commercial use" trial - https://w…

So, this looks to me like a marketing layer ("Robots!") over a macro-recorder on steroids.

I'm not complaining, I bet you can make a lot of money doing this, and it's arguably helpful to the clients, but am I missing something?

Like, there are no actual robots involved, yeah?

Re: Learning to code vs. learning to automate

#73

Post by sosborn »

Ididntdothis wrote: post #46
Wowfunhappy wrote: post #34

Earlier quoted context omitted.

You _can_ write plain text code, add an Applescript or Javascript block. Or just use Script Editor directly instead of going through Automator. Apple Events are quite powerful and let you add a lot of functionality.

I hope you would agree that this unnecessarily cumbersome. A plain text script file is hard to beat.

You can call arbitrary scripts from Automator and pass in arguments.

Re: Learning to code vs. learning to automate

#74

Post by simlan »

monkeydust wrote: post #16

Just brought print version of https://automatetheboringstuff.com/ (2nd edition just released) - thought it would be a good way to learn some code in a practical interesting setting of automation

That book encapsulates how i learned my Python, Bash, and whatever else i tinker with. I only browsed it a couple times because it was too late for me. Just reiterating that i highly recommend it.

Re: Learning to code vs. learning to automate

#75

Post by darkkindness »

save_ferris wrote: post #5

Any recommendations on a good MacOS GUI automation tool that isnt Automator? Seems like the windows automation ecosystem has several options, but I’m struggling to find a good Mac solution that’s capable of automating desktop apps with fine-grained workflows

I'm a big fan of Alfred (https://www.alfredapp.com/) however the GUI automation feature called Workflows is paid.

The killer feature for me is being able to create global keybinds or custom Spotlight commands that can be linked control flow blocks to different drag-n-drop blocks of editable shell script / Applescript / Python / whatever. The keybinds themselves and everything else are drag-and-drop blocks, too. The edge over other keybinding software IMO is that you can define variables and do otherwise complex control flow within a workflow without being limited to "define a list of things to run". For example I could have a 'compile this' keybind that detects language, compiles, and displays stdout of whatever code I'm highlighting.

For Android I'm currently using Tasker, which is a "list of things to run" so it suffers from sometimes having to define multiple tasks for one command. But it's better than the drag-n-drop alternative (Automate), which doesn't allow arbitrary shell commands last I checked.

Re: Learning to code vs. learning to automate

#76

Post by dsjimi »

solinent wrote: post #22
ethbro wrote: post #15

Earlier quoted context omitted.

Programmers drastically underestimate the amount of poor abstractions we've created. There's no reason someone should have to learn object oriented programming in order to be able to do 4 actions across 2 apps. Fundamentally, that's what this article was getting at for me. Should we (a) encourage more people to learn to code (in existing languages / frameworks), so that they might use coding to automate their own wor…

To put what you've said more succinctly, even though reductionism is valid for a computer, there is no reason for us to reduce everyone to transistors. My mother is an accountant for example, and she could easily pick up SQL or a programming language, but the issue with teaching her one is that it doesn't solve any of her immediate problems. Excel already automates most of that work away, so for her that's all she ne…

Excel is the world's most popular IDE ;)

Re: Learning to code vs. learning to automate

#77

Post by swozey »

Noumenon72 wrote: post #36

> Throughout human history, there’s been a sort of “pain is gain” approach to the repetitive. There was value in putting your head down, getting into a rhythm, and working hard at menial tasks. I was surprised when my sister told me, "I don't think everyone has that instinct to make things better all the time". That's like my fundamental drive! But she doesn't, and I guess I see why. Things didn't get better for hund…

Are you a perfectionist?

Re: Learning to code vs. learning to automate

#78

Post by nickjj »

If you're on Windows, Auto HotKey is the ultimate tool for automating day to day little things that are hyper specific for your daily work flow. For everything else there's Bash / some scripting language.

You can end up with really big quality of life improvements from having a bunch of little things whipped up to solve your problems.

Re: Learning to code vs. learning to automate

#79

Post by duxup »

rurcliped wrote: post #68

The problem often isn't ability to automate. It's that the workers closest to the problem have an overwhelming disincentive to automate. Suppose I have a low-level job in Peloton operations. Our Phalange Team must ensure that, before a bike's in-home delivery date is confirmed, the delivery technician has placed an internal order for a left phalange. Each of us spends all day navigating between the Sales app and the…

I worked at a place where coding was not my job (it was technical support) but I wrote some scripts that automated some stuff. It was handy and everyone liked it.

Then someone in the process changed things that the scripts did not understand.

Management came running to me upset that this thing I automated didn't work. Being technical support managers most didn't understand (not all but most) that when you change things you need to tell people before the day of and they were quite upset with me.

I had saved them enormous time over several years ... but the result was I really just kept doing the same job I always was, not rewarded, and then the day they changed their processes without telling anyone they got upset with me.

My incentive to automate anything for them ever again was gone.

Re: Learning to code vs. learning to automate

#80

Post by [deleted] »

bransonf wrote: post #44
sigmaprimus wrote: post #23

When I was younger I dreamed up an idea of a shock suit, basically it would have been a set of long underwear top and bottom with electrodes that would act like a TENS machine to gently(or not so gently) nudge the wearers into performing a repetitive task with machine accuracy. I figured this would be great for an assembly line and could provide a cheaper alternative to a very costly robot while still providing emplo…

There is a sci-fi story somewhere that talks about this premise. It’s a machine that just gives constant orders to the employees of an establishment. Like “grab the mop”, “go to the bathroom”, “mop from left to right” (you get the idea) The story makes the cases that the employees are actually satisfied because they don’t have to do any thinking for themselves. They just follow these methodical simple and timed tasks…

[deleted]
Post reply on HN