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

Learning to code vs. learning to automate

daedtech.com

Post reply on HN
Print view View original

131–140 of 190 posts

Re: Learning to code vs. learning to automate

#131

Post by Sebb767 »

beefield wrote: post #108
andrepd wrote: post #71

Earlier quoted context omitted.

>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.

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) yo…

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.

Re: Learning to code vs. learning to automate

#132

Post by blotter_paper »

iudqnolq wrote: post #128
blotter_paper wrote: post #109

Earlier quoted context omitted.

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

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.

Re: Learning to code vs. learning to automate

#133

Post by hnick »

duxup wrote: post #79
rurcliped wrote: post #68

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

I worked at a place where coding was not my job (it was technical support) but I wrote some scripts that automated some stuff. It was handy and everyone liked it. Then someone in the process changed things that the scripts did not understand. Management came running to me upset that this thing I automated didn't work. Being technical support managers most didn't understand (not all but most) that when you change thin…

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).

Re: Learning to code vs. learning to automate

#134

Post by hnick »

pytester wrote: post #89
yjftsjthsd-h wrote: post #8

Earlier quoted context omitted.

What would you prefer? Manual is hardly an option.

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

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.

Re: Learning to code vs. learning to automate

#135

Post by hnick »

nickjj wrote: post #78

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.

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.

Re: Learning to code vs. learning to automate

#137

Post by sigmaprimus »

jmull wrote: post #130
sigmaprimus wrote: post #23

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

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?

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.

Re: Learning to code vs. learning to automate

#138

Post by glaberficken »

sireat wrote: post #115
nickjj wrote: post #78

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.

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.

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/

Re: Learning to code vs. learning to automate

#139

Post by lozf »

sigmaprimus wrote: post #82
vsareto wrote: post #52

Earlier quoted context omitted.

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

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!'

Re: Learning to code vs. learning to automate

#140

Post by 3fe9a03ccd14ca5 »

rurcliped wrote: post #68

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

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

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.

Post reply on HN