Learning to code vs. learning to automate

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

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