Live data from Hacker News

Learning to code vs. learning to automate

daedtech.com

151–160 of 190 posts

Re: Learning to code vs. learning to automate

#151

Earlier quoted context omitted.

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

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

Re: Learning to code vs. learning to automate

#152
post #57

Earlier quoted context omitted.

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

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

Re: Learning to code vs. learning to automate

#153

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…

I wonder why is it immoral. I understand that mind control would be, but voluntary external muscle control?

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.

Re: Learning to code vs. learning to automate

#154
post #79

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…

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

Re: Learning to code vs. learning to automate

#155
post #79

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…

[deleted]

Re: Learning to code vs. learning to automate

#156

Earlier quoted context omitted.

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

I thought there was an AHK clone for Linux? Also, I've had good luck with xdotool.

Autokey.

Re: Learning to code vs. learning to automate

#157
post #151

Earlier quoted context omitted.

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

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

Thanks for the clarification!

Re: Learning to code vs. learning to automate

#158

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

If it wasn't a phalange how would they point it out?

Re: Learning to code vs. learning to automate

#159
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…

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.

Re: Learning to code vs. learning to automate

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

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.

Post reply on HN