Hacker News Reader

Comment by ryanmarsh | Hacker News Reader

Being a consultant with clients in a wide range of industries I concur. Most of the employees I come into contact with have jobs that could be automated with a few days or weeks of programmer effort. They are one successful software project from losing their jobs. Lucky for them their companies are terrible at shipping software.

Conversely, automating the work of a plumber would require a massive investment in AI and robotics.

Also, nobody makes a robot that can be trusted to repaint the trim in my house unattended.

View on HN

"Most of the employees I come into contact with have jobs that could be automated with a few days or weeks of programmer effort."

After looking at some of the business processes at my company I am not so sure about this anymore. There are a lot of jobs that are pretty mundane but when you look a little closer most of the processes have a lot of exceptions where the employee makes decisions that don't follow the process exactly. From what I have seen it's really hard to come up with a recipe that can be 100% automated because of all these exceptions. It seems to me that humans are a buffer that sometimes corrects unforeseen things and without that buffer the organization would do stupid things.

The key bit that companies that shift hard to software seem to figure out: How many of those corner cases are actually worth bothering with? Is the net loss associated with a corner case greater than the significant gain of dropping an FTE or FTEs? Sometimes it is (safety related things, etc.), but many times, it's not...just because you CAN handle something doesn't mean it's worth it do so.

It’s something the organization needs to decide. If you automate a process it means you are setting it in stone and lose flexibility . Maybe that’s a good thing or not but something people need to be aware of and accept.

> "If you automate a process it means you are setting it in stone and lose flexibility"

If you automate a process, you can in future build in variations, and gain flexibility.

And because you automated the process, your code shows how it works, and so you can quickly see what needs to be changed.

This is often a process issue more than anything else. For instance, our finance team spends insane amounts of time dealing with a variety of invoices with varying information and structure.There are a number of exceptions, rules and etc. However what's often ignored,is the fact that we are much bigger than any of our supplier and it would be pretty easy to convince them to invoice us the way we want instead the way they want. With some clever automations, I could easily replace a couple of my colleagues with software, however I would not be in a better situation at all,so no point of doing it.

While that would eliminate jobs within your organisation, it would clearly create development work in your suppliers.

On balance I would guess you would create work overall rather than reduce it.

Tangentially related: The German industry is working on a standard for digital invoices. Invoices would be a human-readable PDF file with an additional XML payload containing a machine-readable version of the same data. I can't say anything about adoption though. The Google keyword is "ZUGFeRD" for those who are interested.

colombia is also implementing the same thing, their customs/tax authority has a custom XML schema (!!) where large business are rolling out .pdf and .xml receipts.

https://globaleinvoicing.com/en/electronic-invoice/colombia - for an english link

Plenty of companies still use EDI for this.

This is a great example. I automated away the jobs of a few people at a transportation company that had a few large clients that expected to be invoiced in particular ways with additional documentation.

We put together a document imaging solution to gather all the relevant docs from all loads and made the pickiest customer the default for all invoices and automated the entire system. Instead of laying those people off though, we focused them on calling on unpaid invoices which greatly helped accounts receivable.

Similarly, at an oil and gas company we took the better of several business processes, molded them into one optimized process, automated it, and after a dip in the price of oil and layoffs many jobs were never rehired for.

At both of these places the leadership saw the value of getting the software right, hired for it, and we got the job done. I estimate the oil & gas company saved themselves $1 Billion over the next 10 years.

The only thing I don't like about these situations is how little money the developers get for doing things like this. Any other profession would be rolling in money after bringing such savings,yet the developers end up getting pennies ( relatively).

While the software I've written hasn't caused anyone to lose their job, my software has certainly kept new people from being hired. The people doing "mundane" processes are now handling considerably more transactions than they were 10 years ago and even more than 20 years ago. We keep automating more and more of the process and less people are ultimately needed. It will almost certainly always require someone but they'll be doing the job (but not necessarily the same work) that used to take 5 people.

So there'll be one or two people taking care of those human decisions when necessary... when there used to be ten people taking care of the whole process.

So it doesn't automate all the jobs out of existence; it just automates most of them out of existence

Personally I have seen many cases where isn't the automatability of the job that is the obstacle but the capabilities of the user as the limitation. Essentially a sufficiently technically sophisticated user would be perfectly capable of doing so but not the end user in that case and economics are against it.

As in "Yes this office job could be replaced by three shell scripts but the boss wouldn't be capable of using them and they make six figures so it is cheaper to just add a minimally skilled and paid underling than to try to teach them."

It may be maddening to see the needless extra expenses and pointless job but doing so makes some economic sense. A "roll-over" to those capable of doing it themselves would likely be a slow process as inertia must be overcome. Since even if you have "also technically competent enough to automate it" there wouldn't be a selective pressure and jumping the gun on this issue may prove pound foolish if the replacements aren't up to snuff or worth the added expense from supply vs demand let alone politics.

> They are one successful software project from losing their jobs.

Maybe. However, consider how successful Google has been at automating customer service.

If google is the example, then the world is in for an automated hands off hellscape for consumers and their true customers--advertisers.

The two have nothing in common. Many people have trivial useless office jobs.

> jobs that could be automated with a few days or weeks of programmer effort

Governments don't want the workers in their countries to not have a job, even when there's plenty of wealth to go around. Such people will actively demonstrate against all sorts of abuse by government employees and property owners, and even cause socialist revolutions at home and create terror abroad.

Even better for governments are when the workers in the country have heavily mortgaged houses and children with medical expenses. That's the main reason for BS jobs, high house prices, and fast food.

Reply on news.ycombinator.com