Learning to code vs. learning to automate
daedtech.com
daedtech.com
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 Internal Order app.
My daughter tells me how I can automate this. But I never do it. Why?
1. Even if I were 100% sure the coding would be finished in one day, the daily metrics for the Phalange Team would still signal a problem.
2. It introduces uncertainty. I can tell my manager exactly how long the manual process takes, but I can't tell her how long it takes to write code.
3. It trades off the mean for the variance. Suppose it handles 99.44% of the cases but there's a rare bug where it never sends a delivery date if the Internal Order backend has a timeout error. On average, scheduling is 90% faster but some customers aren't scheduled at all. Not an acceptable outcome.
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.
On top of this, Capitalism is what continues to create new jobs, and ensures, for the post part, that you will be able to find another job if you lose your current one.
Moreover, it's not like Blockbuster was known for hiring skilled workers.
Do you believe buggy whip manufacturers should be entitled to their old job even today?
Hence the universal basic income.
Of course, I'm sure there are people who did that and then lost their job when their boss discovered they didn't do much of anything any more.
You start doing the thing you were doing twice as fast earlier, thus your productivity doubles. Kind of, assuming that the price of your product does not change due to your increased productivity. If the price halves at the same time (e.g due to competitive pressure because you were not the only one to figure how to spend half the time doing same thing) your productivity measured in dollars did not change at all. Weird. You do twice the stuff at same time than before and now I claim your productivity did not change. Makes no sense whatsoever. So did your productivity increase or not? I have no clue.
Even further confusion. Your increased(?) productivity just caused that with same amount of money people can by more of your stuff, i.e deflation. Now, why the heck, given the massive increase in productivity(?) during the last century, we have seen inflation, not deflation? Makes no sense to me.
It looks to me like we would need to have more words for different kinds of productivity. Because at least I am confused as heck what that word actually means...
Also, if your market isn't already saturated, you can even sell more of your product without dropping the price. It really boils down to the fact that selling is what brings money, not producing.
Because the money supply increased even faster than the goods & services supply.
Goods and services are traded in an economy, but finding a way to exchange A (ex: shoes) for B (ex: chicken nuggets) is such a chore that economic activity is limited. Money is a solution, like a hub city for air travel: the easiest way to guarantee a route between all pairs of nodes in the network. Trade shoes for money, then trade money for chicken nuggets. You're still trading shoes for nuggets, but now it's much easier, which helps everyone.
Everything gets priced in money (say, "dollars"), but if something is mispriced, arbitrage takes place. Buy an underpriced thing for a few dollars, trade it directly for an overpriced thing, then sell the overpriced thing for a lot of dollars. Money for nothin'. But once others catch on, they demand trade terms that give them the profit, changing prices until they can't be arbitraged.
So everything gets priced relative to everything else, and all prices can be expressed in "dollars".
If the maker of dollars decides to increase the supply by a factor of ten and no change in goods & services takes place, You have ten times as many dollars being offered for the SAME goods and services as before. Arbitrage will quickly push all prices to where the goods and services still have the same value relative to one another but their price relative to the dollar has changed by a factor of ten. Everything is "ten times as expensive" in dollars but not in terms of what people really need: other goods & services.
If you make the same number of generic shoes, twice as many generic electronic widgets, and ten times as many dollars, shoes will be traded for ten times as many dollars ("price" goes up 10x), and even widgets go up by 5x, because although productivity made 2x as many widgets, the number of dollars went up 10x.
For the employer, the productivity of their capital investment has increased.
You might be able to increase your productivity if you can leverage a salary increase, or figure out how to sell the automation to your employer for more than your salary, or sell it to others.
This is quickly becoming an issue. As industrial output is rapidly becoming exclusively the product of automated systems, the 'worker' becomes irrelevant. The limit is, none of us do appreciable work for standard goods. And since we're not working, we're not getting paid, and we can't afford the goods.
We're gonna need a new system.
(Emphasizing to the business to avoid a tired argument about value really being what the market will pay. In technical econ terms by value I mean the private benefit of the consumer of the automation)
The value of the automated system is clear. The value of the engineer is the automated system. Which might be quite expensive, but nothing like the value of its output.
I called it a tired argument not because it definitely isn't true but because I'm tired of people shutting down unrelated conversations with it to look smart.
A simple scenario that shows these are separate concepts:
Suppose we have an extremely dumb firm that pays the engineer a trillion dollars to create an product that can make whoever owns it a billion dollars.
Suppose we have an extremely dumb engineer that charges a different firm $1 to produce the same product.
Suppose both firms are trying to sell the automation to a third firm. Their expenses are a sunk cost; this firm isn't going to pay the dumb firm that overspent any more. The value of the product is (generally) separate from your cost of making the product.
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.
I see software as a new form of literacy, and this argument is, for me, a clincher.
Imagine a world where, you were the reader/writer in the company. And if there was a problem with the letters sent from head office, then because you are the reader/writer guy who does all the writing the problems are all yours
Yes, that is correct, as the only reader writer they are your problems. but the wider problem is why are you the only one?
If you're head of human resources at your company, any human resource problem the company has, is your problem, because you're the human resources guy.
To be fair, most of those departments demand certification to participate in, but if everyone was able to make spot fixes to the companies software, then I'd start demanding that only certified software people be allowed to touch our git repo.
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.]
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.
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 that it makes sense (sometimes they add extra data columns or she forgot to do contact/tag setup on her end).
I absolutely never have the computer run stuff without me watching unless I control the entire process end to end, it's non-critical, or management has requested it officially so I can point to specs when it goes wrong. Usually when I have a semi-automated process that is proven to work, then that's the time to bring it up with management to try and make it more official (if they're not the sort to drown it in red tape).
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.
I feel that a lot people have this exact problem.
There's not a word for it, but there should be. It's definitely an anti-pattern.
In my case, the way I got into "software development" was by automating things in my work. It has a lot of pluses and it looks like delightful magic to people who aren't expecting it. It can bring enormous value in places that desperately need it.
But there's a dark side to it. The dark side is that you find yourself alone dealing with problems using only stuff that you built. Like you said, you're at the focal point when things go wrong. No Q/A, no help-ticket system, no buffer, no one to manage expectations.
To make it worse, your boss, your peers and your PM's eventually find that, all of sudden, their workplace has a mini "software development department" that is integral to the mission. That's kind of jarring if they're not adaptable enough to handle it. If you try to get involved with actual software development folks in other teams, you're shunned because you aren't "really" a software engineer until you prove yourself to them (which may never happen depending on how rigid the org is).
I've find that to make this kind of arrangement work, I have to be willing to be a "one man band" for much longer than I feel comfortable.
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.
I think the flaw with the scenario you described is that your programs are “replacing” these peoples’ “jobs”, when, in reality, we’re building tools that empower them to perform their jobs more effectively.
In the case where we create a self-service option for our customers, such that they no longer need to call in, our ops friends are grateful that we’ve removed a tedious task from their day to day work. From my POV, internal users are as much our customers as external users are.
Of course, there’s a fine line between “empowering” and “replacing”. As our tools become more powerful, we need fewer hours to do a greater number of tasks, so ops’ headcount can scale sub-linearly with the number of tasks they need to complete.
While that gives us a business edge, it also means that we can invest in making our fewer people more generally-skilled, so that we avoid the case you describe (where a person’s job description is encapsulated in a single task, which is eventually automated away). We can also afford to pay them well, and their work is generally more varied and interesting. It’s a clear win for those on the inside.
The only losers are the hypothetical 100 or so unskilled people we’ll never hire or invest in, because our existing 100 are adequately supported. I don’t know a solution to that problem, but it can’t be to hire 200 people and give them terrible tools.
[0]: https://www.forbes.com/sites/amysterling/2019/06/15/automate...
> I think the flaw with the scenario you described is that your programs are “replacing” these peoples’ “jobs”, when, in reality, we’re building tools that empower them to perform their jobs more effectively.
I took this as an attempted refutation of that comments parent based on the anecdotal account given.
I think that the secret sauce that makes our automation “good”, is that we’re growing as a company, which effectively dictates that both the supply of new ops tasks and the magnitude of existing ops tasks are growing along with us.
If we weren’t growing, we’d be taking away work with our automation (instead of clearing the way for more, different work).
Management will be pleased and then ask the team to achieve 20-50% more per day because your automation sped things up and now you have more free time to do stuff. This adds stress to the team because the script isn't 100% reliable, and when it fails the team is still expected to maintain the 20-50% more benchmark. Your ass is being burnt to fix the script ASAP, and everyone has to work long hours to hit the "new normal" benchmark.
Oh, and of course, you don't get any real reward for improving the team's productivity because "It's awesome you did this but writing scripts isn't what we hired you to do".
I've lived this guy's life:
https://news.ycombinator.com/item?id=21737666
And after a bunch of similar experiences there I decided that I'd never work again in a team where management exhibited such behavior. If improving the team's performance adds stress to everyone in the team, I'm not going to automate. But I became an engineer to solve problems and not to pointlessly spin wheels. The only good option: Leave and find another job (which I thankfully did).
The cynical advice here is: automate your own tasks and keep the extra slack you gain from it - unless there's a compelling reason to do otherwise.
Exactly why you automate it on your own time, for your own enjoyment. Then you do your $DAYJOB with tools you created for yourself at a fraction of the energy it used to take.
This, to me, is one of the greatest joys of knowing how to program. It's like a super power.
Especially when it comes to support roles, there's just no way you can take the human out of that equation (as much as Google thinks you can), but you can do a hell of a lot to make the life of those employees much easier by addressing pain points and giving them the tools they need. This isn't just a case of fixing bugs to reduce support calls, but making sure your back-office/admin setup is solid and gives them everything they need.
This way, you're not automating away their jobs, you're enabling them to do it more effectively.
I'm not sure how this might work outside of a software firm, but I've led a couple of teams like this in the startup world and they've easily been my favourite positions.
It seems to hinge on the specifics of how point 4 would play out, which is largely a moral question.
Points 1 and 2 are negative in the eyes of management, and yet point 4 is so overwhelmingly favorable for management (or at least for the company...) that it would eclipse any negative implications of points 1 and 2.
Point 3 can be circumvented, or at least sufficiently mitigated. I imagine this is how well done software automation typically plays out (though I am only imagining here, really): a fallback is set up for customers who don't receive orders (e.g. a number they can call); initial error rate is unknown, but a mysterious timeout occurs after 100 customers; as soon as that happens the first time, the problem is dug into and solved; next error only occurs after 500 - 1000 customers—when it happens, the problem is dug into and solved; this process repeats, rapidly shrinking the error rate into something vanishingly small while only a handful of customers are affected (and not critically so).
Assuming no major flaws in the preceding, everything hinges on the consequences of point 4. If the moral implications are acceptable (e.g. company has other positions for these people), the main upshot of this is just that the company is now spending much less money, and the person responsible for the automation has hopefully been amply rewarded.
If the moral implications aren't acceptable (seems more likely...), then the whole thing is kinda stalemated—assuming the decision maker cares about that sort of thing ;)
You can end up with really big quality of life improvements from having a bunch of little things whipped up to solve your problems.
This is one of the features that keeps me with Keyboards maestro, which keeps me from switching away from macOS.
In your case, from my limited understanding it would be no problem to identify a specific button in an app and then interact with it because you would be hooking into the app's low level window title / class / handles.
AHK comes with a "spy" tool where you can just move your mouse around and it gives you low level details about every window, and then you can write AHK scripts that interact with those things.
The script would look something like:
ControlClick, OK, "My Cool App"
Check the marked answer here: https://stackoverflow.com/questions/49516638/ahk-web-element...
The above answer shows both navigating to a new page that isn't open yet or interacting with an already loaded page based on the title of the tab.
It will return the (x,y) and you can then use the Mouse functions to interact with that location.
Theoretically you can do the same thing that AHK does in a .net language or even Powershell but AHK is just easier to whip up something very quickly.
Still I wish there were better Python wrappers for Windows automation.
This is exactly how I see it too. 10+ years ago I would have written a C# app to do something that I can now do in AHK.
Of course there's limitations (I wouldn't write a super intensive native app in AHK) but for little workflow optimizations it's so good.
For example, I wanted a quick and dirty way to grab the hex color under my mouse cursor and copy it to my clipboard. With AHK it was:
#h::
MouseGetPos, MouseX, MouseY
PixelGetColor, color, %MouseX%, %MouseY%
StringLower, color, color
clipboard := SubStr(color, 3)
A while back I wrote a blog post on using AHK for defining global hotkeys. I still use that method today. If anyone cares, that's at: https://nickjanetakis.com/blog/remap-and-set-global-hotkeys-...
It's been added to my growing toolbox(which I lovingly call i3_emulator.exe), thanks!
You can kind of understand what's going on with general programming experience and double checking their documentation.
In the hex code example it almost reads like pseudo code. Get the mouse position and store it into X / Y variables, grab the color under the mouse position, make it all lower case, copy it to the clipboard but trim out a few extra characters that was returned by a previous step.
How is your i3 emulator going? I tried that one tiling window manager AHK script (bug.n) but found it to be a little too buggy to use.
At work we evaluated other solutions like Blue Prism for our internal apps but Auto Hot Key never got a mention. I wonder why.
It's a great example of how "learn to automate" can beat "learn to code". When you know how to do something by hand, learning enough about a program's API to do the same thing is a separate learning curve and may not be possible. Telling AutoHotkey "Do it like I do by hand, just faster" always works.
Check out "xdotool": https://www.semicomplete.com/projects/xdotool/
Aside from being a good tutorial for beginners, what makes it unique is the scope of what the reader is expected to learn to produce: small scripts that will greatly benefit them in their daily life. It demonstrated the power of computing, gives the reader agency and it is entirely possible to cover enough to be actually useful within one book.
I've believed for a while that scripting should be the emphasis for most primary and secondary education computing courses, and companies should even invest in training witha wider remit than they currently do. There's been many times when knowing some VBA or a small amount of Python would have saved hours or even days worth of effort in repetitive tasks.
Personally I would still be willing to wear a suit like that if the pay was good enough. Put on the suit, turn off my mind and put in a days work.
You still can't just "turn off" your mind, most likely. You'll just be trapped there thinking
It's pretty astonishing how much variation there is in people's inner minds. Some can imagine spatial relationships in great detail. Some can't even imagine a simple stick figure, but can instead remember long lists of information.
I don't mean to frame this from a moral high ground either. Just mildly curious.
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. It’s a really interesting premise I think.
Ability to do an unlimited number a tasks without major retooling would be one.
Minimal maintenence and upkeep would be another.
Thinking abit more about it, there would be more uses other than just automating labour.
I could see a suit being very usefull in a training situation such as learning to dance using the suit then when muscle memory kicks in the suit can be taken off. (This is simmilar to the utube video link posted in the comments)
How about for snipers? With the suit on a sniper could hold steady on a target.
Then theres the whole tele-presence surgery idea.
IMHO the most important thing is it creates a symbiotic relationship with humans and automation rather than getting rid of the human.
All that said I kniw a suit is a pipe dream but maybe a long sleeve glove that allows you to pick up a pen and draw a computer generated picture might not be that far out.
'Wear the suit in your Leisure time, and subscribe to our "Master of X" range of Suit-Apps including "Tennis Pro", "Concert Pianist", "Tri-Athlete", "Chef", and many more!'
That seems like an unlikely premise, and thus a meaningless statement. It's not physical coercion like you imagined, but take a look at how amazon logistics workers get managed by their wearables. Then look at how they describe the job.
I'm gonna go out on a limb here and say this would always be used on people who can't fight back, because they're in some sort of disadvantage (usually economic) and so they would never be paid well enough.
Do you by chance play something like Arma, DCS, or Farming Simulator?
Oh, how I miss the ArmA ACE mod days.
Alternatives: automated time waster blocking (on the router probably), self-blackmail (nudes go out automatically, or your important stuff is deleted).
I don’t know what life is, but I’d consider it a waste to try to turn all of us into machines. Remember John Henry, the steel drivin’ man?
Also, the potential for evil is too great in such a device.
That’s why your father told you it’s an immoral plan.
Why would it be easier or more efficient to program a suit to direct a human to perform a specific operation than program a robot to perform the same operation?
How would it be cheaper or more efficient to maintain a human than a robot?
Just off the top of my head I would say the amount of power needed to drive a humans muscles would be exponentially less. You also may not need to program things like balance, walking, object avoidance or abort sequences if coding for a symbiotic human machine as these would be instinctual on the human side.
>>>How would it be cheaper or more efficient to maintain a human than a robot?
This is bit trickier, but I would say the big one is the fact that humans have a built in regenerative system. Also a human can tell you what hurts, this would require less diagnostics maybe?
This is all speculative anyways, but it would be nice to control even one of my arms via cnc, I could do calligraphy like a pro, paint like a master, even play the piano like a prodigy just by downloading a bit of code. I don't see any issues with morality if someone programs their own body to preform those tasks.
Machines (and the shock suit, presumably) are very good at executing movements precisely and repeatably, but they're not great at determining what to execute. Surgical robots work somewhat like this: the user plans each action (cut here, cauterize there) and then robot executes it.
Also see Stelarc's Movatar[0] for an working human-installed, early-web version, providing a VRML to Human web interface.
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 hundreds of generations at a time while we were evolving, so inventing is not an instinct.
DISCLAIMER: I'm not in such a high-paid position that spending an hour or two down a rabbit hole feels like I'm wasting serious time/money.
I identified several common errors made by other people. They were very confusing the first time, but now I can solve them at a glance.
Apple Events are quite powerful and let you add a lot of functionality.
Personally, I like to write and test Applescripts in the Script Editor, and then throw them into Automator when I'm finished so I can save them as "Services", which means they'll appear in the right click menu of whatever app(s) I choose. But that's entirely optional.
I’ve only done one simple shortcut that lets me say “Get Directions” to Siri and it asks for an address and it launches Google Maps instead of Apple Maps.
Federico Viticci is considered the king of shortcuts in the Mac community.
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-screens...
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.
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 Macintosh which included an object database and a scripting language named UserTalk. At the time of its original release, Frontier was the only system-level scripting environment for the Macintosh, but Apple was working on its own scripting language, AppleScript, and started bundling it with the MacOS 7 system software. As a consequence, most Macintosh scripting work came to be done in the less powerful, but free, scripting language provided by Apple.
Both AppleScript and Frontier supported Apple's "Open Scripting Architecture" (kind of like OLE Automation via Apple Events).
https://developer.apple.com/library/archive/documentation/La...
https://en.wikipedia.org/wiki/AppleScript#Open_Scripting_Arc...
Now Automator lets you use "JavaScript for Automation" instead of AppleScript.
>Under OS X Yosemite and later versions of macOS, the JavaScript for Automation (JXA) component remains the only serious OSA language alternative to AppleScript, though the Macintosh versions of Perl, Python, Ruby, and Tcl all support native means of working with Apple events without being OSA components.
https://hackernoon.com/javascript-for-automation-in-macos-3b...
https://apple-dev.groups.io/g/jxa/wiki/JXA-Resources
https://github.com/JXA-Cookbook/JXA-Cookbook/wiki
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. (Probably the world's first JXA script written in Literate CoffeeScript).
https://github.com/JXA-Cookbook/JXA-Cookbook/wiki/Examples#k...
I wrote more about Frontier and other automation tools:
https://news.ycombinator.com/item?id=20425970
>The thing that's missing from "Google Docs" is a decent collaborative outliner called "Google Trees", that does to "NLS" and "Frontier" what "Google Sheets" did to "VisiCalc" and "Excel".
“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
..
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.
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.
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
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 work, or (b) identify simplified systems that require less knowledge, but are sufficient for the automation tasks being asked of them.
I love learning about multi-level cache heirarchies and performance effects thereof.
But I would rather my company's accountants instead know the accounting-equivalent of that bit of trivia, and yet gain the benefit of being able to write simple automation on their computers.
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 needs.
Your company's accountants can probably write excel statements that are equivalent to complex SQL statements, so I wouldn't underestimate them :)
If they don't come up with at least one strength or spend the whole answer bashing it, that's an instant reject for any position touching UX.
The clashing paradigms of the Data Model and "vanilla" Excel have really been aggravating me recently.
I feel like Excel is underutilized for cultural reasons and it seems like it can do anything I was previously asked to use Qlikview for.
But the fundamental reason I am using Excel these days is because I don't want to be subjected to a programming interview, ever again.
I got my current job without any particular technical requirements, and the interview was entirely about how I manage my time and multitask.
This talk addresses that misconception: https://www.youtube.com/watch?v=g1ib43q3uXQ
The paper discusses "constructionism" (which, loosely put, is the idea you give someone a toy and let them figure it out): http://morganya.org/research/2018-Ames-CSCW-Constructionism....
There is more out there but that's all I have time to find right now.
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.
Introducing the "would someone pay for this" is a key step because it tells me if it's worth pursuing even if I didn't need it myself. The answer is almost always no.
Further, the majority of these small automations increasingly look like they are feature improvements on existing products. This example is also perfect because it was a feature within Powerpoint that would probably take the Microsoft Office team a day to prototype [1] and a few months to build into the next update with backward compatibility etc...
So to me the value at the outset isn't in the code, which is fairly trivial, but the value is in knowing what to code and how to integrate the new automation.
Here's where this breaks down though...you can't evaluate what you should be building and how it would be built, if you have no idea how to build something. So it is important to learn to code, if only to understand how hard it is to do different things. That holds true for everything though, from making a meal to fixing a carburetor or doing braids. You need experience doing things before you can know how to estimate whether they are worth doing in a new context.
[1]Something like...
#Compute centroid of rectangle:
>self = (coord[0]+(coord[2]/2), coord[1]+(coord[3]/2))
#Compute centroid of background rectangle
>other = same formula
>#Align
>def add(self, other): self.x = self.x + other.x self.y = self.y + other.y
The intent here is to build on a better, Excel-user-accessible set of abstractions.
Which generally means:
1) Graphical IDE
2) Automation activities which map directly to their existing manual activities
3) High-level support for highly-used application-specific activities
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://www.uipath.com/product/studio (you're looking for "Community Edition")
Disclaimer: I have no financial interest in UiPath as a product, past running a business user-focused automation enablement team that is currently using it. I've been in the space about a decade, and just happen to think they do it "better" than anyone else currently (YMMV. Pegasystems' RPA offering is also great, but they don't talk to non-Fortune 500s or advertise it)
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?
Think supporting 30+ years of different UI frameworks, over process variants that may be dissimilar (e.g. when code = 5, the "OK" button is actually a different class).
All while hiding enough of the underlying complexity that a business user ignorant of all the above can write 95%+ of the automation.
So yes, I'd say it's one of those things that seems easy, but is difficult to actually get working for compatibility reasons.
There are no physical robots involved. ;)
It’s important to understand the functional value of programming (ie. automation), but what really inspires learning is the underlying purpose. What are we achieving through automation? What have we unlocked? That process of discovery is what’s most exciting, to me at least, about coding. It’s what I seek to learn.
I think of it as learning a little bit of math or science -- good for your general understanding of the world, and how the thing that is your interface to most of the world operates, it's basic functions and limitations. It's even a bit like learning civics or economics -- as code makes more important decisions every day, a naive yet fundamental understanding of omgow these things work among the general population helps a lot. Everyone should learn how to code a little bit as part of a general education. If you want to do it professionally, then yes, learning problem solving and automation is the way to go.
And it would be nice if people practiced a tiny bit of debugging, so we could see fewer horror tales from tech support.
https://en.wikipedia.org/wiki/DeBabelizer
https://creativepro.com/debabelizer-pro-5-the-ultimate-image...
I have to use both Keynote and PowerPoint for work and this is one of those small things I've come to appreciate.
1) Problem identification. Get the target wrong and it doesn't matter how wonderful your code is. 2) Problem solving. 3) Creative thinking. Most code is science, but occasionally it takes art. You have to be willing and able to be an artist.
With these in hand, coding is a means not an ends. The obcession with code as an ends is fool's errand.
Automation? You're gonna need these base skills as well.
Certainly, these things can be taught. But some of us are wired better than others for this skills stack. We don't need more people who write code. We need more problem solvers with an occasional flare for rule breaking, creativity, etc.
Programming is a process, a way of thinking about things, it is entertaining, it’s creative, it’s beautiful in many ways, in and of itself.
Learning to program sharpens so many parts of once mind, I want everyone to get a glimpse of that.
Actually, I learned how Braille works and that's something I always wondered about.
It'd make engineering a bit easier without trying to encourage people who might not really be interested into wasting their time and everyone else's.
Hasn't this been done to death now? Are there still developers out there whose primary focus is writing code rathet than solving problems?
Edit: Also, this article is from June 10th... 2015.
1. Assign a repeatable task.
2. Incentivize to complete higher number of tasks. This can be a flat rate per task or flat number of tasks per day or something similar.
3. Let them work for a while to understand the process.
4. Now the idea to automate gradually appears in their head.
5. First automation appears. I usually start with command line loops and encoding strings into barcodes.
6. GUI automation appears and the user starts running into limitations of easy tools.
7. User makes the decision to invest time into learning a programming language.
8. User automates their entire job.
Smarter companies would offer to assign her the role of an internal software tool maker to identify processes and automate them.
Some of these toolmakers might be like me and perfectly happy to simply do a lot less and get paid the same or more.
Other companies will make her realize she might be valued higher elsewhere.
Learning a programming language without a concrete goal to solve is not as being able to completely automate your job.
I once identified a great opportunity as a field service engineer. The company unknowingly offered me an incentive. After arriving on-site, I can identify additional broken equipment that’s not in my original scope and add it to my scope. I negotiated flat rate compensation per unit fixed rather than per location or per hour. My marginal cost to fix additional equipment is a few extra minutes.
The company sending me that work creates additional scope on their end after I am finished and so we all get paid more money. The service call gets closed in a single visit. I call that a textbook example of all incentives aligned.
So, after identifying this opportunity, I explored all bottlenecks inhibiting me from working faster. A single additional service call per day results in significant extra money.
Bottlenecks:
1. Talking to dispatch to verbally relay serial numbers, shipping numbers, and other phonetically spelled data. Solution: start transmitting data as structured text dispatch can copy/paste. Result: most loved vendor, no more waste of time. ;)
2. Verify equipment is properly configured. Solution: if it can be pinged, it will work, else redo the previous task. Result: knowing the arp and ping commands lets me test equipment without walking to it.
3. Verify output integrity. Solution: (currently implementing this) use a personal IP KVM with a WiFi AP to remotely operate the on-premises server while standing next to equipment. Motivation: running upstairs at least 30 times at one troublesome location not long ago.
4. Repetitive entry of text strings into multiple contexts. Solution: encode those strings, like passwords, into barcodes on my iPad and scan them while also scanning serial numbers and such. Result: this saved a ton of time.
My first automation was to write a script to ping all devices as part of a health check.
Now that I reached the limit of easy automation, we enter software engineering. I am working on a tool to automatically generate my paperwork based on OCR-ed screenshots. I am also working on a tool for the dispatch to have better visibility into what their techs are doing.
At the same time, I have a huge incentive not to share my shortcuts with other techs.
By the way, the next generation of our control equipment runs Linux. I was constrained by archaic tools running on Windows, but we all know to which extent we can automate Linux. ;)
Ah, but should she take that? Isn't a job as a developer/programmer really just a subterfuge by management to extract all the value produced by automation and not pay for it?
"Some people, when confronted with a problem, think 'I know, I'll automate.' Now they have two problems."
There are problems one should automate but there are many problems where automating is not worth the effort.
That's where the opportunity may lie with no-code type platforms, to empower other departments to automate and maintain their own idiosyncratic workflows.
Certain tasks are in theory executable without specialised tools, if one is willing to pay for "the inefficient ways", but in practice they are just not feasible because the lengthy / convoluted workflow that results means that you are always having to focus on the minutae, which prevents treating all but the simplest issues.
For example, I could in theory write the space shuttle code in pure assembler, using a pen and paper, and huge teams. "It would just take very long". In practice you would never get it working.
Also, doing things quickly and easily can have all sorts of benefits, like allowing you to adjust to the unexpected.
Edit: Someone already said much the same thing. Oh well.
They hired 100x as many call center workers as they thought they'd end up needing and sales skyrocketed.
My (largely younger, tech savvy) friends are always slightly shocked to hear this story - because they didn't appreciate having a human guide them.
The low cost of labour must have an impact on creative solutions. You have little need for automation and AI when you can just throw more bodies and minds at it for a pittance.