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

171–180 of 190 posts

Re: Learning to code vs. learning to automate

#171

Post by dicytea »

vasili111 wrote: post #122
freetonik wrote: post #101

Earlier quoted context omitted.

Can Auto HotKey recognize images and click on them? For example, a specific button in an app or a web page? This is one of the features that keeps me with Keyboards maestro, which keeps me from switching away from macOS.

Yes it is very easy to match image and click on it with AHK. For image matching use https://www.autohotkey.com/docs/commands/ImageSearch.htm for matching use bmp files! bmp files works mach better then png or jpg. For clicks there are several commands, just google them. Also take a look at https://www.autohotkey.com/docs/commands/CoordMode.htm

Is there any reason bmp would work better than png? I've always used png all this time.

Re: Learning to code vs. learning to automate

#172

Post by hhas01 »

duxup wrote: post #79
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 thin…

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

Change control is an utter pig in any system, and bad process is bad process anywhere. The difference is that humans, being highly adaptable, tend to dynamically mask defects in manual processes, whereas automation—efficient but utterly unforgiving—reveals those defects for all to see.

“when you change things you need to tell people before the day of and they were quite upset with me”

And this is why we always put things in writing.

In an ideal world, the organisation’s [manual] processes would all be nailed down and documented first, before any automation is introduced. This not being an ideal world, it’s not until the automation is being brought in that anyone stops to think about how things work. Alas, you can talk till you’re blue in the face about how the company really needs to formalize and document all of its change management processes, especially now that automation is in the mix, but you can’t make the bastards do their jobs; especially when they don’t even understand what those jobs now entail.

Thus the challenge in achieving successful automation is not in delivering a task-specific software but in cultivating a more general culture change across the organisation; one that understands that the purpose of automation is not to replace humans but to provide them tools to do their jobs more efficiently. Which means providing those humans the additional information and resources they require to use those tools both safely and effectively, even as the organisation and its processes and requirements continue to evolve.

If software design is about managing complexity, systems design is about managing liability.

You can be the best task automator in the world, but if you can’t protect the greater system—or at least ensure a damn good CYA papertrail—then you should seriously consider if introducing automation at this stage is the right thing to do. Never underestimate the strengths of manual processes, nor the immediate incremental benefits to be had in fine-tuning those first; even as you play the long game in your head.

Re: Learning to code vs. learning to automate

#173

Post by hhas01 »

scrapcode wrote: post #105
duxup wrote: post #79

Earlier quoted context omitted.

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 thin…

I have had similar experiences. I've taken very tedious tasks that involved a lot of monotonous paperwork and automated them and that turns everyone's problems into my problem when they don't work the way the user thinks they should. I've also had people use the fact that my tool, which just automates a process that everyone had to do manually in the past anyways, use me and my tool not functioning correctly for them…

“use me and my tool not functioning correctly for them as an excuse to not having the work done on time”

Sorry, bud, that one’s on you. If you don’t understand your users—really get in their shoes and walk around in them—how can you hope to build automation that works for them?

Change is Risk, and here you are trying to sell them on the mother of all Changes. Burn them, they won’t give you another chance.

--

[And yeah, I know some users will always be obtuse reactionary assholes who blindly reject any sort of change as a direct threat to their status quo. Work to accommodate them—if you can make your solution work for them then it’ll work for anyone—and if they’re just being a petty sabotaging asshole after you’ve done all that then bump the issue with the full papertrail up the management stack. Let their superiors handle their crap; they don’t pay you to deal with it. Take solace in knowing that once all their rivals at smashing it with terrific automation, those backwards losers will be first out their jobs.]

Re: Learning to code vs. learning to automate

#174

Post by _8ljf »

ozfive wrote: post #117
duxup wrote: post #79

Earlier quoted context omitted.

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 thin…

I can attest to this. I had similar experiences when I was in Aerospace. The complete incompetence of management is staggering and the mentality to stick with what has worked keeps efficiencies down. They instead went after the workers to "work harder" instead of allocating time and money to automation. I finally left and went to work on automation for industries that were receptive to creating tools that would make…

“I finally left and went to work on automation for industries that were receptive to creating tools that would make them more efficient.”

Congrats on finally realizing: Not your paygrade, not your problem to fix.

First rule of automation success: choose the jobs that are amenable to it, not the ones that aren’t. And never forget that people, not machines, are the heart of it.

Re: Learning to code vs. learning to automate

#175

Post by criddell »

IggleSniggle wrote: post #152
criddell wrote: post #65

Earlier quoted context omitted.

I made it for fun, but it ended up being kind of useful. I say to Siri "record my weigh" and it response "how much do you weight?" I say the number and it records that number, along with the data and time, in a Google spreadsheet. Khoi Vinh wrote about shortcuts on his blog[1]. He uses one to automatically archive screenshots to a particular Evernote notebook. [1]: https://www.subtraction.com/2019/12/04/shortcuts-and…

If there's a way to share it, I'd actually love this one.

I'm not sure how to share it, but the key was using ifttt to add a or of data to the Google Spreadsheet.

If you search for shortcuts for logging weight, there are a bunch that log it to the Apple Health App, which is probably a better solution. I only have an iPad though and for some reason Apple won't let you run the Health App on an iPad.

Re: Learning to code vs. learning to automate

#176

Post by hhas01 »

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

Fine-grained automation means Apple event IPC, which is very powerful and elegant, which for practical purposes means AppleScript, which is… not.

I wrote production-quality Apple event bridges for half-a-dozen major languages (Apple even considered bundling a couple of them in Leopard). It’s an amazing ecosystem once unlocked with languages that aren’t a bad joke. Thousands of productivity apps with not one but two very high-level User Interfaces: one graphical, one programmatic.

Alas, even the best software in the world won’t fix PEBKAC, and the Mac Automation Product Manager was one of these:

https://daedtech.com/how-software-groups-rot-legacy-of-the-e...

A few thousand hours of solving their problems only for them to promptly un-solve them again, I finally gave up in disgust.

http://appscript.sourceforge.net/status.html

As say upthread, there are better ways to spend your life than trying to fix stuff that others are determined to keep broken. At least I had a laugh when Apple finally sacked that jackass, even if he did take Mac Automation down with him.

For better or worse, the future of macOS Automation now lies in the hands of the Siri squad and their conversational shortcuts. Let’s hope they do better.

https://twitter.com/stroughtonsmith/status/11359563313603461...

#InterestingTimes

Re: Learning to code vs. learning to automate

#177

Post by vasili111 »

dicytea wrote: post #171
vasili111 wrote: post #122

Earlier quoted context omitted.

Yes it is very easy to match image and click on it with AHK. For image matching use https://www.autohotkey.com/docs/commands/ImageSearch.htm for matching use bmp files! bmp files works mach better then png or jpg. For clicks there are several commands, just google them. Also take a look at https://www.autohotkey.com/docs/commands/CoordMode.htm

Is there any reason bmp would work better than png? I've always used png all this time.

I cannot tell why it is so but bmp image matching worked for me much faster then png on several PCs.

Re: Learning to code vs. learning to automate

#178

Post by duxup »

hnick wrote: post #133
duxup wrote: post #79

Earlier quoted context omitted.

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 thin…

I always keep a manual safety step for unofficial automation for this exact reason. Current example: I have a script I run for my wife that de-duplicates some data against historical excel files and submits it via an API to Mailchimp, to tag members for a triggered email. I run this manually for her about once a week. It does not alter anything unless I supply the '--go' option. That lets me check the output to see t…

Oh absolutely.

My scripts ran, then quit as soon as they saw something wonky.

The real result was that they didn't do anything other than check the data.

I had tried to get them handed off to IT for official support but it got lost in the years due to silly politics.

Re: Learning to code vs. learning to automate

#179

Post by hhas01 »

DonHopkins wrote: post #29
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

There used to be Userland Frontier, which was actually earlier and better than AppleScript! https://en.wikipedia.org/wiki/UserLand_Software#Frontier >UserLand's first product release of April 1989 was UserLand IPC, a developer tool for interprocess communication that was intended to evolve into a cross-platform RPC tool. In January 1992 UserLand released version 1.0 of Frontier, a scripting environment for the Macint…

Unfortunately, JXA’s Apple event support is buggy and broken, and not a competent replacement for AS. AppleScript may suck as a language but at least it speaks Apple events right. JXA could’ve been Apple’s answer to Node.js, but it failed so hard that Apple scrapped the Mac Automation team and fired the PM responsible. The whole stack’s in maintenance mode now.

“As an example task similar to what the article discusses, whose source code is actually readable, here's a script to change the font of all text in all master slides in Keynote.”

That’s a good example of how not to use Apple events, which are notoriously high latency. Here’s the simpler, efficient canonical solution:

    Application('Keynote').documents[0].masterSlides.textItems.objectText.font = TARGET_FONT
Apple event IPC is not OOP/DOM, it’s RPC plus queries. Sending lots of simple messages manipulating one object at a time is far slower than sending a more complex message that manipulates all objects at once.

..

As to Userland, yeah, Frontier was first and, crucially, knew how to speak Apple events right. But Dave got huffy that Apple didn’t take it and flounced for the nascent Web dev market where they promptly got eaten by PHP.

A pity: ol’ Dave could’ve taken a lesson from Napoleon (“never interrupt your enemy when he is making a mistake”). Mac Automation should be pure geek catnip, but AppleScript is so hideously programmer-unfriendly and unscalable, programmers’ instant loathing of it is the major reason Mac Automation has failed to thrive. Userland could’ve stayed where it was and easily won a robust audience of professional users and developers begging for a non-atrocious alternative. Ah, hindsight’s a wonderful thing.

Re: Learning to code vs. learning to automate

#180

Post by hhas01 »

noelwelsh wrote: post #24
aj7 wrote: post #11

The whole nature of coding is that is essentially motivationally self-taught. As for automation- that’s what better coders do. Perhaps this is being confused with “Find a good problem that motivates you, and fight a knock-down, drag-out battle to solve it.”

I'm struggling to parse "essentially motivationally self-taught" but if you mean to say something like "only self-taught programmers will successfully learn to program" that's a myth that isn't backed up by the evidence and serves to exclude people from programming. This talk addresses that misconception: https://www.youtube.com/watch?v=g1ib43q3uXQ The paper discusses "constructionism" (which, loosely put, is the ide…

Yeah, decades of dragging myself over programming’s coals have made me super cynical, but I think that lots of programmers are really good at building tools and knowledge that are horribly inaccessible to anyone not already like them. And then being surprised and unhappy that no-one else appreciates what it is they do.

If the barrier to programming is raised so high that only a career programmer can do it, all that happens is we end up with lots of users—professional experts in their own problem domains, mind—who don’t understand programming, and a bunch of professional programmers who don’t understand anything else. And then those programmers complain bitterly because they don’t understand why users hate so much the systems they’ve built for them.

And yet, Seymour Papert demonstrated how to make computing open and accessible to eight year-olds, back in an age when cutting-edge HCI was a fricking Teletype! So it’s definitely an instance of PEBKAC; it’s just a matter of which chair.

Post reply on HN