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

141–150 of 190 posts

Re: Learning to code vs. learning to automate

#141

Post by sigmaprimus »

WrtCdEvrydy wrote: post #120
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…

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.

Re: Learning to code vs. learning to automate

#142

Post by deepnet »

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…

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

Re: Learning to code vs. learning to automate

#143

Post by sean2 »

lifeisstillgood wrote: post #107
scrapcode wrote: post #105

Earlier quoted context omitted.

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…

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

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.

Re: Learning to code vs. learning to automate

#144

Post by dreamcompiler »

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

Re: Learning to code vs. learning to automate

#145

Post by mattkrause »

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?

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.

Re: Learning to code vs. learning to automate

#146

Post by ljm »

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…

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.

Re: Learning to code vs. learning to automate

#147

Post by benhurmarcel »

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…

Have you ever had a blue collar job?

Re: Learning to code vs. learning to automate

#148

Post by westoncb »

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…

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

Re: Learning to code vs. learning to automate

#149

Post by joshvm »

dreamcompiler wrote: post #144
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 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

Re: Learning to code vs. learning to automate

#150

Post by vandal_at_your »

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.
Post reply on HN