Learning to code vs. learning to automate(daedtech.com)
daedtech.com
Learning to code vs. learning to automate
https://daedtech.com/dont-learn-to-code-learn-to-automate/
189 comments
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.
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.
“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.
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 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 as an excuse to not having the work done on time.
> that turns everyone's problems into my problem
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?
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?
True, but software is only one such department that this reasoning works for. Legal, Public Relations, Accounting, HR, facilities, etc, are examples of other departments that need specialists for fields that everyone really ought to get some literacy in.
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.
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.
“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.]
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.]
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 them more efficient. It's exceptionally frustrating to be in such a position, and you are right, it's better to do nothing and find yourself a place that fully understands what it means to save time and money by spending a fraction of it to fix while putting functioning processes in place to mitigate the risk of someone changing anything without going through the proper channels to ensure that the tools continue to work.
“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.
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.
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 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).
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).
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.
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.
> My incentive to automate anything for them ever again was gone.
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.
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.
[deleted]
There's also:
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).
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).
"A slow sort of country!" said the Queen. "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"
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.
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.
In my company, each engineer spends about ¼ of their time building or improving tools for sales, marketing, support, or operations. Notice the preposition “for” there.
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.
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.
I'm not at all convinced that automation only results in the loss of future, and not present, jobs. In some cases the company will use the currently available worker hours for other tasks, but I can also imagine situations where workers that currently have jobs are laid off. A brief googling turned up a Forbes piece that claims millions of jobs have already been lost to automation[0], which seems believable to me whether or not the claim is accurate (Forbes has unapologetically lied in the past). This isn't to say we shouldn't automate things, but we should be aware of the effects of that automation.
[0]: https://www.forbes.com/sites/amysterling/2019/06/15/automate...
[0]: https://www.forbes.com/sites/amysterling/2019/06/15/automate...
I think the comment you're replying to was providing a single example to prove not all automation leads to job loss immediately. You're arguing some automation leads to job loss. These aren't contradictory claims. I found the anecodote interesting because it's not universally representative.
I can see reading it that way. I was under the impression that the comment I was replying to was using a specific case to argue a broader claim, particularly with this sentence:
> 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 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.
My bad, I did word it in a universalist way there, whereas I was trying to give an anecdote to counterbalance the claim I interpreted as “automation is bad for ops people”.
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).
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).
Thanks for the clarification!
> 4. If I successfully automate it, all of my coworkers lose their jobs.
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.
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.
If I had a choice on how to do this, I'd set up an internal productivity team that didn't aim to automate everyone's jobs away, but instead give them the tools to do their jobs better.
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.
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.
I get your point, but is it possible you meant "flange"? A flange can be taken to mean "random mechanical part." A phalange is a bone in your finger.
It's a Friends reference: https://youtube.com/watch?v=DrwVB4vMx-Q
If it wasn't a phalange how would they point it out?
There's a cancelling effect on some of these items, so that the total value in the outcome isn't clear.
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 ;)
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 ;)
>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.
A failure of capitalism when less work and more productivity is a bad thing.
If there is one thing that confuses me, that is productivity.
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...
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...
Folks often assign the output of automated systems to the creator. This seems a fallacy. The output of an engineer creating an automated system is, the automated system. The output of the automated systems is the product of … the automated system. Who owns that? In a capitalist system, whomever paid for it.
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.
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.
But isn't the value of the automated system the engineer produced to the business the sum of the value the system will create minus what has to be spent on it (compute power, maintenance).
(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)
(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)
That 'tired argument' is how capitalism works. So like it or not, an Engineer is paid the going rate.
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.
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 was trying to talk about the value the engineer produces from the perspective of their employer, which is separate from what that employer is willing to pay the engineer. In economics terms, I'm talking about the consumer surplus (the employer is the consumer of the labor the engineer produces, and has a surplus because they get more value than they are paying).
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.
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.
It's been like that since the Stone age. The reason it's like that is the fundamental forces that drive humans: greed, cruelty, ego and all that. Hard to expect someone in power to not get more power if he's blinded by greed. How many people do you know that voluntarily spend 25% of their income on those who are lower on the social ladder? I don't know anyone, myself included.
The problem here is that you measure your productivity in revenue instead of something like products per hour. This is not inherently wrong, but then the benchmark is keeping your revenue by not loosing it to your competitor, who is also automating.
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.
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.
why the heck, given the massive increase in productivity(?) during the last century, we have seen inflation, not deflation?
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.
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.
Another way to look at it, is that your productivity equals your salary, i.e., marginal value added per unit of factor input. You work the same number of hours or years. You receive the same money. So your productivity is the same.
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.
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.
Why is that a failure? I didn't know every job had to last a lifetime.
If capitalism wasn't systemically geared towards creating an underclass of unemployed and desperate part time workers it might not be a failure.
it's a failure because that condition was one of the reasons that he did not automate his job. A success of capitalism would be if it provided some incentive to automate the job.
Heh, good point. But still I wouldn't call it a failure, just a defect, or not optimal. The company as a whole probably works just fine.
[deleted]
Very true. My brother lost his job at Blockbuster when they closed down. Since then he hasn't been able to find a job. When I mentioned to him that unemployment is at a 50 year low and maybe now would be a good time to try again to find a job he was dismissive. He went on to explain to me how due to capitalism he will never work again. Now I can't stop worrying that I'll lose my job and never be able to work again.
Blaming an economic system for one's lack of motivation to search for work sounds like a cheap deflection.
Moreover, it's not like Blockbuster was known for hiring skilled workers.
Moreover, it's not like Blockbuster was known for hiring skilled workers.
I really have a hard time believing that after your brother lost his job at Blockbuster (10 years ago?) that he will 'never work again'.
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.
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.
> A failure of capitalism when less work and more productivity is a bad thing.
Do you believe buggy whip manufacturers should be entitled to their old job even today?
Do you believe buggy whip manufacturers should be entitled to their old job even today?
They may not be entitied to a job... but they certainly are entitled to not be screwed below the poverty line through no fault of their own, just because the the owner wanted an extra buck.
Hence the universal basic income.
Hence the universal basic income.
Capitalism is only bad for those who do not share profits coming from better productivity.
Government regulation is needed to balance inequality created by capitalism: progressive tax, competition laws, professional unions etc. Workers are also responsible to bargain deals that make them share more benefits and raise their bar.
This is everlasting struggle.
Well, as others mention, you capture profits from automation when you automate your own job and don't tell people, so you only make your own life easier.
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.
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.
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.
You can end up with really big quality of life improvements from having a bunch of little things whipped up to solve your problems.
AutoHotkey is an ugly language to write in, but oh boy is it useful for gluing disparate Windows actions together.
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.
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.
> 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.
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:
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-...
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-...
Your hex snippet produced my usual outcry when I read other's AHK scripts: "Wait, you can do THAT?!"
It's been added to my growing toolbox(which I lovingly call i3_emulator.exe), thanks!
It's been added to my growing toolbox(which I lovingly call i3_emulator.exe), thanks!
The fun thing about it is I wouldn't classify myself as an AHK developer. I just picked apart a couple of scripts that I found on Google.
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.
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.
I have used both AHK and AutoIt and find AutoIt much simpler to understand (and also has clearer documentation).
https://www.autoitscript.com/site/autoit/
https://www.autoitscript.com/site/autoit/
I thought it was still just a neat tool to automate clicks, but then I played Path of Exile for a bit and found POE Trade Macro. It stunned me what it could do. Hover over an item, hit a key, it performs an API call to lookup a price and display it in a popup window over the game.
At work we evaluated other solutions like Blue Prism for our internal apps but Auto Hot Key never got a mention. I wonder why.
At work we evaluated other solutions like Blue Prism for our internal apps but Auto Hot Key never got a mention. I wonder why.
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.
This is one of the features that keeps me with Keyboards maestro, which keeps me from switching away from macOS.
I'm not an AHK wizard but to my understanding, the answer is "yes" to almost every "but can it do...?" questions.
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:
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"
I have limited experience with Keyboard Maestro but I do have some with AppleScript. It lets you do as you described, get windows, titles, UI elements. However this only works on native apps, you cant, for example, click a button on a webpage with a CSS selector or by scanning pixels of the window, ad far as I know. Can AHK do that? That would be super useful
While I've never done it, AHK seems to have an API for being able to interact with DOM elements.
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.
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.
You can use Selenium with AHK. https://www.autohotkey.com/boards/viewtopic.php?t=32323
Yes, Autohotkey can search for pixels and stuff:
https://www.autohotkey.com/docs/commands/PixelSearch.htm
https://www.autohotkey.com/docs/commands/PixelSearch.htm
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
Also you can use Selenium with AHK. https://www.autohotkey.com/boards/viewtopic.php?t=32323
Yes! You can search for Bitmaps on the screen. Take a screenshot and crop to the button, save it as a .bmp, and then use the ImageSearch function (https://www.autohotkey.com/docs/commands/ImageSearch.htm).
It will return the (x,y) and you can then use the Mouse functions to interact with that location.
It will return the (x,y) and you can then use the Mouse functions to interact with that location.
I totally agree that learning "just coding" per se should not be a goal. It should also help to solve some of your real problems and automation is one of the topic that is very likely you need to solve. When you do something that you like and at the same time need it pays off twice. In fact I got most of my programming skills by implementing simple automation task that I needed. I highly recommend AutoHotkey ( https://www.autohotkey.com/ ) if you are interested in automation. It is programming language with great automation capabilities and wonderful helpful community (last one is very important if you are new to programming).
I just changed jobs from developing on Windows to developing on a Linux virtual machine in Windows. I miss AutoHotkey so much. There are so many things that the command line can't do -- GUI commands, window switchers, and so on.
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.
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.
I thought there was an AHK clone for Linux? Also, I've had good luck with xdotool.
Autokey.
Pyautogui does some of the things AHK does.
> There are so many things that the command line can't do -- GUI commands, window switchers, and so on.
Check out "xdotool": https://www.semicomplete.com/projects/xdotool/
Check out "xdotool": https://www.semicomplete.com/projects/xdotool/
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
This is a really good book.
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.
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.
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.
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 employment. I never pursued the idea after telling my Dad about it who told me it was an immoral idea.
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.
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.
> Personally I would still be willing to wear a suit like that if the pay was good enough.
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.
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.
My thought was more along the lines of a welder or pottery wheel operator where precise and steady movements are required. I would agree that is the immorality of such a device as it is quite easy to turn it into an electronic whip of sorts.
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. It’s a really interesting premise I think.
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.
You probably mean https://marshallbrain.com/manna.htm
Thank you, this is exactly what I was thinking of
I remember reading this once upon a time, but what a pleasant and hilarious rabbit hole to see again. Thank you for putting this in my feed!
I also love that the actual premise here was automating away MANAGEMENT.
[deleted]
We are tool makers, not robots. Machine level precision is why we design and build machines. Art isn’t a product to be created for museums; it’s a process, a meditation, a discovery, communication. You’ll note that that the rise of abstract expression in painting correlates with the refinement of photography. We no longer needed humans to create realistic depictions, so we explored deeper into the purpose of those depictions.
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.
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.
Discrete versions of this are already being tested for use enhancing micro in competitive e-sports
Also see Stelarc's Movatar[0] for an working human-installed, early-web version, providing a VRML to Human web interface.
[0] - http://stelarc.org/?catID=20225
Also see Stelarc's Movatar[0] for an working human-installed, early-web version, providing a VRML to Human web interface.
[0] - http://stelarc.org/?catID=20225
I wonder why is it immoral. I understand that mind control would be, but voluntary external muscle control?
It still breaks individual autonomy, probably.
It’s not external muscle control, that’s not what a TENS unit does. OP is describing using painful electric shocks to punish a worker for mistakes or for going off-task, i.e. brutalize workers into performing with machine like efficiency.
I think he was proposing using the TENS for muscle control similarly to https://m.youtube.com/watch?v=5QYpD428hAQ
Oh, OK. I also thought it was electroshock motivation.
You still can't just "turn off" your mind, most likely. You'll just be trapped there thinking
You still can't just "turn off" your mind, most likely. You'll just be trapped there thinking
I have actually met people who vehemently insist that when they "space out" they aren't deep in thought, they are literally off -- not thinking at all.
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.
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.
Interesting comment. It's so obviously immoral to me, that seeing someone question it has me considering how morals are instilled in other cultures / generations.
I don't mean to frame this from a moral high ground either. Just mildly curious.
I don't mean to frame this from a moral high ground either. Just mildly curious.
TENS isn't muscle control and what is described doesn't seem to be voluntary but imposed (and economically coerced) use of physical pain as a means of correcting workplace errors.
Your dad is right, but setting morality aside for a moment...
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?
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?
>>>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?
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.
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.
It would make sense if the user could trigger different "motor programs" on demand.
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.
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.
Continuum had something like this. If you owed too much, they would implant the ship right into your spine and it would take full control of your body until your death (since it was impossible for you to pay off the amount).
I believe ready player one also had something along those lines, although in that story they enslaved your mind to play games but they same idea of creating an indentured servant through predatory lending.
Heh, I've been thinking that would be great for distractions. Have to work but are on Reddit? Shock!
Alternatives: automated time waster blocking (on the router probably), self-blackmail (nudes go out automatically, or your important stuff is deleted).
Alternatives: automated time waster blocking (on the router probably), self-blackmail (nudes go out automatically, or your important stuff is deleted).
I bet you could take the capital/development/money from developing that suit and instead put it towards reducing the cost of the robot it's designed to compete with.
There would be several advantages to a suit over a robot over and above cost.
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.
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.
I can hear the ads now:
'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!'
'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!'
This is one of the most amusing Hackernews comments I've read.
Do you by chance play something like Arma, DCS, or Farming Simulator?
Do you by chance play something like Arma, DCS, or Farming Simulator?
Arma? You mean spending weeks learning the controls, then slowly walking towards your objective for hours, only to be sniped from across the map? What’s not to like?
Oh, how I miss the ArmA ACE mod days.
Oh, how I miss the ArmA ACE mod days.
Have you ever had a blue collar job?
Obligatory Monty Python:
https://www.youtube.com/watch?v=vLMFSNIurqs
https://www.youtube.com/watch?v=vLMFSNIurqs
> 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 hundreds of generations at a time while we were evolving, so inventing is not an instinct.
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.
Yes, maybe you're more evolved then they are, or maybe they're just more cynical about an industry where 70% of projects fail to deliver the intended benefit. :-)
That’s why even for creative work, getting into a repetitive work rhythm is important. Most high production authors like Stephen King have a strong writing routine like, wake up at this time and write for four hours using this pen at this desk next to this window.
Are you a perfectionist?
Sure, but I'm not surprised when people don't want to polish things the way I do. I'm surprised when they let things go to waste or spend their time doing boring and pointless things. Like, even Genghis Khan probably spent some time thinking about ways to take cities without having to fight so much, right?
I have automated some things both at work and at home. Sometimes the "time saved doing the thing vs time spent setting it up" calculation looks very shaky, but I persist because when I'm puzzling out how to automate something I'm learning and adding to my skillset that may be useful for the next thing (and is therefore inherently interesting, may lead to greater efficiencies, etc). If I'm just spinning my wheels clicking arbitrary buttons I'm not really learning anything (and I guess in stark economic terms, not adding value to myself as an employee).
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.
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.
As a field service engineer, I would spend 2-4 hours on a new problem and the next time I’ll encounter it I will solve it instantly.
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.
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.
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.
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.
Keyboard Maestro is my go-to tool. It's incredibly powerful and I've automated so many things in so many applications that I really don't even know if I could use a computer without it anymore.
https://www.keyboardmaestro.com/main/
Thanks for this tip.
Another vote for KBM
I used Hammerspoon a few times to automate some mining and building in Terraria (keystrokes, mouse movement and clicks).
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
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
Semi off topic: Workflow (Shortcuts) for iOS is great and it is semi ported to the Mac via Catalyst libraries (https://twitter.com/stroughtonsmith/status/11810213462240583...). Hopefully, Apple actually goes whole hog and ports WorkFlow to the Mac next year.
It seems so promising, but I have yet to identify a real use case. Do you have any genuinely useful examples for everyday life?
I use Shortcuts to automatically set volume and start playing a particular playlist when my gym headphones pair with my phone.
The Shortcuts for the Mac example is a hack that the author did just as a proof of concept.
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.
https://www.macstories.net/shortcuts/
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.
https://www.macstories.net/shortcuts/
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-screens...
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 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.
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.
what's wrong with automator exactly? i've been wanting to get into it on my new mac but i'm not entirely sure what i will use it for yet.
Personally I find it very weird to work with. I don’t see the point of learning a different and less powerful coding paradigm. It would be fine if it had it a current UI but you also should be able to write plain text code.
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.
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.
As I said, you can use Script Editor.app, in the Utilities folder, instead of Automator.
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.
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.
You can call arbitrary scripts from Automator and pass in arguments.
[deleted]
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 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".
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".
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:
..
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.
“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 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.”
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 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.
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.
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 needs.
Your company's accountants can probably write excel statements that are equivalent to complex SQL statements, so I wouldn't underestimate them :)
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 :)
Excel is the world's most popular IDE ;)
One of my weed out questions in programming interviews is to ask their opinion on Excel. Specifically, strengths and weaknesses.
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.
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.
I could bash it in ways you probably haven't heard before...
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.
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.
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 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.
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.
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.
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.
Somewhat related, tools like Quickbase, Google Appmaker, Knack, Zoho Creator all work pretty well with non tech folks. Especially in areas like Finance, where they are already familiar with pushing Excel pretty hard. Gets rid of a lot of manual emailing spreadsheets around and tedious data collection.
I really like the breakdown sequence of "Automation in real life" because it nearly perfectly describes the process I go through to evaluate if something is worth trying to build.
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
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
That's still coding.
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
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
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://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)
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)
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?
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?
"Macro-recorder on steroids" is a surprisingly tricky thing to do well.
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. ;)
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. ;)
Automation is the how, but not the why. We automate things that have become trivial, so that we can do something more meaningful.
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.
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 fully agree, but I still think it's good that people learn how to code. Why? Because it's good to know a little bit -- just a wee little bit -- about how computers work. And while you could just get a good description from a book, nothing beats hands-on experience, which is easy (and mostly fun, initially) to get when it comes to coding.
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.
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.
What's the modern-day equivalent of DeBabelizer?
https://en.wikipedia.org/wiki/DeBabelizer
https://creativepro.com/debabelizer-pro-5-the-ultimate-image...
https://en.wikipedia.org/wiki/DeBabelizer
https://creativepro.com/debabelizer-pro-5-the-ultimate-image...
ImageMagick [1]. You can do all kinds of really cool tasks with it and a little shell script. It’s a free software hidden gem, for sure.
[1] https://imagemagick.org/script/index.php
[1] https://imagemagick.org/script/index.php
Not willing to start a flamewar, but there is also Graphics Magick [0], a fork that, for example, adds multi-threading.
[0] http://www.graphicsmagick.org/
[0] http://www.graphicsmagick.org/
ImageMagick has multi-threading, OpenCL support, and even heterogeneous distributed computing support.
I haven’t seen anyone else mention it, so FYI: Keynote on macOS defaults to exactly your preferred behavior: pasting images exactly in the middle of your slide.
I have to use both Keynote and PowerPoint for work and this is one of those small things I've come to appreciate.
I have to use both Keynote and PowerPoint for work and this is one of those small things I've come to appreciate.
For me automation was learned behavior in lockstep with my ability to solve problems via programming. It eventually became automatic: to the point that my own patience with manual repetition and documentation of manual processes is minimal. This latter attitude does not do me any good in the enterprise infotech world. Especially in heterogeneous environments or where I don't have front to back visibility. I'd argue that while being able to automate is a great good understanding the business constraints and making good decisions about where you work becomes critical if
you must trade toil for time.
The skills are:
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.
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.
I agree. But I am still going to tell my kids to learn to code. Programming is more than automating stuff. It’s even more than solving problems.
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.
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.
I'm reading Charles Petzold's book Code right now and I would highly recommend it if your kids are interested in computers. I'm about 1/3 of the way through it and even though I'm not learning a lot, it's a great read.
Actually, I learned how Braille works and that's something I always wondered about.
Actually, I learned how Braille works and that's something I always wondered about.
Or maybe we should encourage users to be users and provide valuable feedback. As in, actually asking about the possibility of new features and reporting bugs.
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.
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.
> “avoid thinking of writing code as the goal and learn to solve problems.”
Hasn't this been done to death now? Are there still developers out there whose primary focus is writing code rathet than solving problems?
Hasn't this been done to death now? Are there still developers out there whose primary focus is writing code rathet than solving problems?
Every programmer that isn't given the opportunity to refute design choices or question the domain knowledge handed down from above. There's still plenty of programming jobs intentionally structured to be like that.
Edit: Also, this article is from June 10th... 2015.
Edit: Also, this article is from June 10th... 2015.
[deleted]
Select object, select format tab, select align, select align center/align middle?
How to motivate someone to learn a programming language.
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. ;)
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. ;)
"Smarter companies would offer to assign her the role of an internal software tool maker to identify processes and automate them."
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?
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?
Learning alphabets vs learning to speak
To paraphrase a famous quote on regular expressions:
"Some people, when confronted with a problem, think 'I know, I'll automate.' Now they have two problems."
"Some people, when confronted with a problem, think 'I know, I'll automate.' Now they have two problems."
What would you prefer? Manual is hardly an option.
Forest, trees...
There are problems one should automate but there are many problems where automating is not worth the effort.
https://xkcd.com/1319/
https://xkcd.com/1205/
There are problems one should automate but there are many problems where automating is not worth the effort.
https://xkcd.com/1319/
https://xkcd.com/1205/
Part of the payoff of automation is not just time saved, but uniformity of results. Everybody makes errors when constructing reports by hand, and most of them are never even discovered, unless you start writing programs to check them.
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.
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.
Both of those comics assume you are automating your own manual task. It gets even more tenuous when you are fielding stakeholder requests to automate _their_ manual tasks, when developers cost substantially more than the entry level folks that end up being assigned these manual tasks, and you don't know how long the business process that requires this manual task will even persist in its current form.
That's where the opportunity may lie with no-code type platforms, to empower other departments to automate and maintain their own idiosyncratic workflows.
That's where the opportunity may lie with no-code type platforms, to empower other departments to automate and maintain their own idiosyncratic workflows.
What is often overlooked in these sort of discussions, is the fact that there is more to take into consideration than "efficiency".
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.
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.
I'm willing to agree that some problems aren't worth automating, especially when they have nasty or absent API surface, or when the task changes too much. On the other hand, looking only at time spent is also a very incomplete picture; I've written scripts for tasks that I was fine doing manually just because it allowed me to add free sanity checks and cut down on human error. (Story time: We had a regular process to clean up dev environment data. Coworker ran rm on prod data. We now have a script that sanity-checks the environment parameter and does the rm commands for you.) There's also value in speed beyond the pure time saved; as an extreme case, consider deploying a fix for a 0-day with ansible vs by hand to hundreds of hosts.
This a good companion to my sibling comment. Despite what I said about other departments, I do believe in automating all of our own (tech) stuff, basically for the reasons above: decreased error rate on sensitive tasks, ability to execute emergency tasks quickly, etc. But perhaps those are good targets for the type of task that should be automated generally.
Manual is often the best option. I worked for a company that was hell bent on automating a booking process and minimizing the number of humans involved until they realized how much many people preferred having a human guide them through different parts of the process.
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.
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.
When I visited the Philippines, one thing that hit me was how many extra people they have standing around doing jobs that just don't exist back home. A man dedicated to a single door in a mall. Someone who calls a lift for me in the hotel. 4 workers in an empty store instead of just 1 here at home.
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.
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.
Manual is always an option, but that's not my point. I've automated plenty of things in my life and know only too well that the task of automating a task is often a major task in its own right.
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.