Hacker News Reader

Comment by rurcliped | Hacker News Reader

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

View on HN

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.

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?

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.

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

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.

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

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

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

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

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

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

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.

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

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.

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.

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

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

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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)

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.

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.

Reply on news.ycombinator.com