You know how sometimes you love an article so much that you are annoyed you didn't write it? This does a better job than I could have of tieing together a dozen threads of conversation that I've had with various friends for years.
I actually believe that there's a culture war implied in this debate; the question of who deserves to reap the gains of automation is more than just philosophy or ethics. The question "is there inherent nobility in work itself?" seems to be just as much a political divide as any of the current popular hot-button issues. Your gut reaction says a lot about the regional values of where you grew up, whether you'd ever support a basic income, and whether you believe that someone's refusal to work should condemn them to destitution.
The closest comparison is the attitude people have if they find a wallet. In Japan, you will get your wallet back with cash intact. Yet in the west, there exists a large contingent of people who believe with all of their heart that God wanted them to find it, that the person who lost it should have been more careful, that they are just having a lucky day. Unless God shows up and declares one side to be ethically correct, it will remain a toss-up.
One thing I find fascinating about the article is that it's assumed the cleverness was the code written to automate. This is incorrect; the cleverness is in noticing when a task can be automated. Typically, the code itself is trivial.
Anyhow: automation is surely one of the best reasons every person should learn a little bit of programming. And even with that task accomplished, I suspect that the rate of people seeing the opportunity to automate will stay roughly flat.
One thing I find fascinating about the article is that it's assumed the cleverness was the code written to automate. This is incorrect; the cleverness is in noticing when a task can be automated. Typically, the code itself is trivial.
I have told my work more than once that if they wanted to get the most out of me they should put me on the "front line" for a month or two, and let me decide what needs to be automated. It has always been laughed off as me being cute.
> there exists a large contingent of people who believe with all of their heart that God wanted them to find it, that the person who lost it should have been more careful, that they are just having a lucky day.
A large part of how America sees work, poverty and wealth was historically influenced by the Protestant Work Ethic, and I think that lingers quite a bit today. I think it's why a lot of people view the poor as lazy (because obviously if they weren't lazy, they wouldn't be poor, right?).
If you fervently believe hard work will lead to success, how else do you explain the unsuccessful?
One thing that I find maddening about this topic is the assumption that people who automate their jobs won't take the new time they get back and put it to better use. For some, that could be learning skills or working on a startup, and others might just want to spend time with their kids.
That said, it seems incredibly wrong to judge someone for being clever enough to relax and get paid for it. And if someone enjoys relaxing as much as I enjoy coding, who am I to say that I'm righteous and they are a loser?
With the way things are going, I’m not sure learning a little bit of programming will help. Digitization has really begun rolling with RPA, because we now automate system processes for systems with no apis and no direct data manipulation.
But even though RPA is mostly screengrapping and macros, we’ve found it impossible to teach to people who aren’t developers.
Similar with better BI tools it’s become possible for sql savvy business process people to do BI, but without s fundamental understanding of data efficiency, which we can’t seem to instill in these highly educated people, what they make is often useless because it slows the systems.
Programming is completely trivial, but understanding what you’re doing, and why. Is much harder to teach than programming. Especially when you’re working toward productiveness where you can’t just write best practices for everything because best practices are often unnecessary for some systems and necessary for others.
I know this wasn’t really that related to the article, it’s just a general observation, and believe me, we tried to decentralize our RPA processes because maintaining them is hell.
> You know how sometimes you love an article so much that you are annoyed you didn't write it?
I love this article because it changed my mind. I was one of the redditors who urged FiletOFish1066 to fess up to his employers on the basis of some moral high ground I felt I occupied. I see now that I made the mistaken assumption that work == goodness and went on from there.
When most people or organisations are purchasing a service, they're usually mainly concerned about the value that service will bring them.
The amount of effort required to produce that value, helps to dictate market conditions and the amount of competition; aside from this, ultimately I don't think effort matters so much when you consider it in terms of B2B transactions.
Eventually, if a service is easy to supply—competition will drive down the price—and the economic system will readjust accordingly.
--
Strangely, it's only when you consider an individual in permanent employment that automation seems to present itself as a dilemma.
There's definitely a lot being said about automation. We're regularly told via news outlets that a large percentage of the populations' jobs will be replaced by robots.
But aside from the idea of universal basic income; I believe there's a more general trend towards working independently, i.e. in a freelance capacity.
Maybe automation becomes far less of a dilemma when this is this case?
The problem is automation is never truly automated in most jobs. There's always things that go wrong, always changes being proposed, always explaining needing to be done. Sure, you may find it easy to automate a report or data entry, but what if that data changes or the format changes? Then you have to fix the code.
The code is almost never trivial either. It often involves integrating complex systems and making sure that they work which, if done right, involves writing several unit tests.
Using God is a poor excuse to determine ethics because there's no evidence one exists. It's especially a problem when you don't share the code because then, instead of creating improvement to the job for the company as a whole, you've written a pass to be lazy. The real job comes from supporting whatever you write to the masses. If you don't have any interest in that, you're simply selfish.
The problem is people react in different ways, but it seems like the most common way is to not tell anyone which in my mind is foolish because even if you do get fired, you've improved your skills enough to find a better job anyway. Not only that, I can just as easily come up with an example of someone getting promoted for automating job tasks.
> the cleverness is in noticing when a task can be automated. Typically, the code itself is trivial.
> Anyhow: automation is surely one of the best reasons every person should learn a little bit of programming. And even with that task accomplished, I suspect that the rate of people seeing the opportunity to automate will stay roughly flat.
Absolutely. A minor observation I have, living in Operations/Finance. Don't merge cells in Excel. Observing a spreadsheet is a fantastic indicator of an individual's knowledge of automation vs manual process. Someone that uses lists without merged cells is someone that not only can save days of of the year with pivottables, various forms of looking up, but probably has the idea of 'tables' 'if' and 'for' in their head.
This is a great kicking-off point for coaching through ugly VBA. I like VBA. It's also often the only choice in corporate environments. But it is an option, and the chance to coach someone that's on the edge of...
> I suspect that the rate of people seeing the opportunity to automate will stay roughly flat.
> I actually believe that there's a culture war implied in this debate; the question of who deserves to reap the gains of automation is more than just philosophy or ethics. The question "is there inherent nobility in work itself?" seems to be just as much a political divide as any of the current popular hot-button issues.
Agreed, there's a lot of meaty ethics and philosophy tied up in this issue.
For most of my life I've tended to believe in the nobility of work, that it gives my life meaning and purpose.
But as rates of automation increase my children (or more likely their children) may well seek different ways of defining themselves.
Before that can happen though there'll have to be some fraught and difficult changes to our societies.
the cleverness is in noticing when a task can be automated. Typically, the code itself is trivial.
I’d actually argue the reverse. It’s trivial, especially with a little programming background to say “we could automate X”.
The devil is in the details. Robustly automating anything of reasonable complexity involves a lot of implementation hickups, dealing with corner cases, gracefully failing, and adding structure and regularity to otherwise disparate, adhoc and unstructured components.
It takes skill, experience and a lot of effort to do this without it immediately falling over.
> One thing I find fascinating about the article is that it's assumed the cleverness was the code written to automate. This is incorrect; the cleverness is in noticing when a task can be automated. Typically, the code itself is trivial.
I thought about this too. Pretty much everything I've automated turned out to be way easier than I assumed and I ended up feeling dumb for not realizing I could have saved myself time by doing it sooner.
> ...whether you believe that someone's refusal to work should condemn them to destitution.
I don't understand what you're getting at there. If someone refuses to work, that would seem to mean that they are able to work but choose not to.
We're not talking about someone who is actually unable to work because of some physical or mental limitation and may need assistance of some sort. We're taking about someone who could work but doesn't want to.
What possible obligation do I have toward that person? I don't see any. Of course I don't think they should be, as you put it, condemned to destitution. But what on earth makes it my responsibility to give them anything at all? Do I owe them a living, simply because they refuse to work?
Having a good worth ethic is respectable. However, working smart can be as effective as working hard. Still, lying about doing work is unethical in my opinion, even if it's clever. Depending on the situation though, I think that letting your employer know that a job can be automated may lead to better opportunities in the future... maybe?
"is there inherent nobility in work itself?"
there certainly is benefit called experience, who cares about nobility. in certain parts of the world nobility is last concern
I think you'll find that most people who 'keep the wallet' are probably not religious and don't think about it the morality of it all that much, whereas those who are regular temple/church/mosque attenders would be among the least likely to 'keep it'.
It should be noted that programmers are not automating themselves out of programming jobs. They're automating themselves out of data entry, or testing, or any number of other mindless tasks easily done by computers.
We may not (yet) be able to automate ourselves out of programming jobs, but we can certainly leverage smart development practices into making the job a lot less labor-intensive.
I'm experiencing a shift in that thinking right now. I write reusable, modular, tested code. My co-workers don't. I use a project management system (Phabricator, on my own personal server, which I maintain); the company doesn't. For most of the last year, I've used these to produce more and better code than others have, but my responsibilities have only expanded while my pay hasn't.
I've vocally evangelized these practices and I'd love nothing more than to see them get adopted by the other developers, but so far it's not getting any traction.
So I'm shifting towards logging the value of the work I produce -- regardless of whether I'm just copying in a file from my extensive library -- rather than the time it took me to accomplish the task.
Re: programmers are not automating themselves out of programming jobs. They're automating themselves out of data entry...
That's not always true. In at least 2 different organizations I worked at they were creating a combinatorial mess of search screens and/or reports.
Using a little bit of meta programming, query-by-example forms, data dictionaries, click-able drill-downs, and modular design; such "reporting stacks" could often be simplified into either a fewer number of screens and/or designed in such a way that a non-programming power user could configure most reports on their own. Allowing CSV exports of query results also reduces the number of "paper" report requests because Excel users can then format their own.
The result is something that needs roughly 1/3 as many programming hours to update and maintain.
One caveat is that you have to know the domain fairly well for it to be practical. You have to learn the domain patterns and habits in order to factor those patterns into meta-patterns. When I tried it as a newbie to the org, I usually did it wrong.
They do that to and have always done so. It's barely remarkable because it is expected and part of the job. The problem is you can't benefit from that, as soon as you automate one part, you are given other tasks.
If you think about it, the existence of programming languages and compilers is due to programmers automating their jobs away. They no longer had to tediously translate higher level algorithms to machine code.
And really, the existence of computers is the result of automating the job of human computers away. The entire history of computer science is this.
The difference is that these guys hit a local maxima, and just ... stop. Instead of moving up to the next level and making more money.
I think the story of the Indian IT crisis is that good programmers have been automating them out of jobs. Good programmers in India are doing fine at modern tech companies there, but the code-monkeys at Infosys et. al. are struggling.
Exactly. Automate away the mundane tasks, so you can spend more time on the interesting tasks. In some regards, programmers are fortunate to have this ability; many careers do not have the skills to automate away the boring parts of their own jobs.
What about programmers automating other programmers out of jobs? My employer's core product line is designed in such a way that it can be configured for specific customers via an API. Much of that work is done by "operations developers." The complexity of their work varies based on the customer's needs. We are currently developing a designer tool that will allow the configuration to be developed via a graphical interface that will allow much of the work to be done by non-programmers (and eventually the customers themselves). As the tool matures, it will generate the code necessary to handle more complex requirements.
GeneXus™ streamlines application development by automatically generating everything from databases to code, frontend to backend, and server-side to client-side services. It’s not magic — just a smarter way to create smart technology.
Yes. In programming, laziness is a virtue. To some degree, so is the desire to work on interesting problems instead of boring problems. Those generally intersect to provide an enormous benefit to everyone.
That may be true in some cases like testing, build automation etc however when CS engineers are developing AI services and Bots, in the long run they will be automating programmers who used to do those things by hand. So Technology will eventually disrupt Coders as well and they will have to skill up or find a new job.
This article really highlights how odd our methods of valuing output are. Ultimately if someone is idling for 6 years because they've written a program to do their job for them, who cares? They are delivering the same output which hopefully the company deemed was valued at X amount BECAUSE it delivers Y amount of profit/returns. This article is actually touching on a deeper level of dysfunction in how we do things like calculating salaries for people. Instead of making things about how much value is created, we tend to tie things to "seniority" or "experience" in isolation. Just because the two are sometimes correlated with value produced it does not justify making that the measure on its own.
I remember going up to one of the senior management people in the company I worked at a long time ago and pointing out how I'd saved the company from having to spend salaries and other overheads on 12-20 more people by automation. If the salary for each person was X, I asked for a salary bump of 3X. They gave me a bump of only 0.5X . I eventually pushed it to 1X but that experience taught me that most of the time, extra value you deliver rarely flows back to you in a reasonable way.
And from that point on, I stopped treating my job as an extension of my identity or fulfillment of purpose. It became a place where I primarily had a cold hard contract to deliver X value in exchange for Y returns. And if I was ever to work again in a company with similar opaque practices on salaries, any increase in Y returns would be best negotiated before showing my entire hand on how much I could increase the delivery on value X.
> If the salary for each person was X, I asked for a salary bump of 3X [and they didn't]. ... And from that point on, I stopped treating my job as an extension of my identity or fulfillment of purpose.
Indeed, the best work is done when you do it for yourself. People basically sign their brains away when they go to work for Facebook and Google. Those companies will be likely to get B players no matter how many seemingly great people they hire. The 4.0 MIT grad who can recite chapters from his CS401 class isn't necessarily an A player. Most of the A players I know are either ex-Facebook/ex-Google or turned down working at those places because they have more important things to do with their time.
The real A players are much harder to find and are much harder to value. Without ownership in what you do, there is a high probability that you will not be at your best. If you need to be paid to do something, it is unlikely to be what fulfills you.
> They are delivering the same output which hopefully the company deemed was valued at X amount BECAUSE it delivers Y amount of profit/returns.
The output is actually even better in my experience. I know in the tasks that we've automated the output is always 100% consistent, which is more than can be said for the previous human output.
Also there's a lot of value in having someone on hand who actually understands the process rather than blindly trusting in a script. They'll more than pay for themselves when it comes to future enhancements or debugging.
And I say all of this as an employer - my employees are positively encouraged to automate as much as possible.
An important thing to realize is that you are not paid based on the value you added during the year. You are paid to make sure you do not leave (for a competitor).
I think in the long run, acting in the best interest of the business when you are employed for that business would result in superior income/career than doing otherwise.
Another option is finding possibilities for automation that could apply to other companies with similar problems, and starting a separate company selling such automation services. A consultancy could work, too.
> This article really highlights how odd our methods of valuing output are. Ultimately if someone is idling for 6 years because they've written a program to do their job for them, who cares? They are delivering the same output which hopefully the company deemed was valued at X amount BECAUSE it delivers Y amount of profit/returns.
Their boss cares. This is capitalism, and capitalist ethics say you should be fired if you're idling and not continuing to actively labor for the boss anymore. She's not getting anything in return for your salary. You more than likely signed away all rights to the fruits of your labor when you took the job. That means "your" automation is really your boss's capital, and you have no rights to be perpetually compensated for it.
So, if you ever automate your own job, don't tell anyone. Also make sure to make your automation so arcane and impenetrable that no one else can hope to use it.
> This article really highlights how odd our methods of valuing output are. Ultimately if someone is idling for 6 years because they've written a program to do their job for them, who cares? They are delivering the same output which hopefully the company deemed was valued at X amount BECAUSE it delivers Y amount of profit/returns.
This is why, in 19th century, they've used to call wage labor, as opposed to self-employment, "wage slavery".
You are selling your time, not the goods you produce.
At some level of understanding, all workers know they don't get the full value of their labor. You just got to see it happen right in front of you in real time.
This is related to Taleb's observation that employment is a kind of "slavery". What he means by this is that you effectively have sold your option to own those to outsized returns in exchange for a regular paycheck.
Why did you ask just for a 3X increase instead of 12-20X?
If you don't value what you did, why should your employer?
Also, why should an employer raise your salary based on the fact you are automating stuff? It's part of your job, after all. That's what programming is about.
If you're coding for a non-technical business, i.e. one in which they're not directly selling your productive output, then it's not hard at all to get to a point where your daily tasks don't take more than a few minutes a day. After all, it's other people that are actually driving the revenue. You can ask for more duties, but their capacity to define tasks for you is never going to outpace your ability to deliver.
My advice is to not fight this state of affairs. Figure out your own way to stay productive. Divide up your spare time between coming up with ideas for your employer and doing side projects. Take long lunches with your coworkers and leave at 4.
You can find happy professional nirvana but you have to believe in it first.
As a former trader/developer/quant I often felt that "automating myself out of a job" was my goal. If we could build properly architected systems that were self-healing when things went wrong, turned themselves on before the market opened, traded all day, made money and shut down for the night... then eventually my role would devolve into monitoring and ultimately into nothing...
In practise, achieving some sort of "steady state" or status-quo doesn't work for a few reasons:
1. Inherent system complexity ensures something always breaks. Human attention is always needed.
2. Markets evolve rapidly due to technology changes, regulatory changes and the very nature of markets: Strategies and ideas that worked in the past cease to work in the future.
> Wary self-automators, he speculates, “don’t trust our workplaces. The boss is going to say thank you, good work, now do it again.”
Well, no shit. That is what the job of a programmer is - to keep automating things.
There are an INFINITE number of useful things we need to do as a society, so we shouldn't be upset if we automate one of them away. Move on to the next.
Of course, programmers should make sure they negotiate strongly to get compensated fairly for the work. I think it is a bit short sighted, however, to worry that you will end up like the guy who automated his job and was then fired and replaced by a lower skilled guy - who cares, you SHOULD move on at that point if the company doesn't want you to automate something else. There are plenty of companies that will hire you, and you can use the example of the previous company to show you can do it. This time, negotiate better compensation.
> Well, no shit. That is what the job of a programmer is - to keep automating things.
I think that many of these scenarios are occurring when NON-programmers realize that their jobs are automate-able and they set out to automate them. It means picking up new skills, practicing them and putting them to use without the consent nor permission of management.
It is not necessarily an easy path, it takes time, and there's going to be trial and error involved and although the discussion is about automating 100% of a job away, there's many other possible outcomes such as effort-multiplication, getting rid of the grunt work and gaining more time to focus on deeper problems.
This is effectively "out-of-band" work that is a great experience for the individual but which _many_ organizations do not condone. A LOT of workplaces don't tolerate workers doing stuff that they're not being "told" to do.
I've told this story a few times and I always get surprisingly diverse reactions to it, especially on Reddit.
Back in the late 90s I worked at a place that sold all kinds of automotive parts. Everything from nuts and spark plugs to turbochargers and large assemblies. The secret sauce of this company was a small team of people who worked through thick supplier (paper) catalogs and figured out which parts from different suppliers are in fact interchangable by comparing their specifications. This all went into the database for the sales team's use.
Well one younger guy in this team worked out a way to largely automate his job using OCR and spreadsheets. Instead of taking 8 hours to work through his day's load, he would do it all in an hour or two. Then he'd slack off for the rest of the day.
Soon the manager found out but the manager was not upset, instead the manager was disappointed. Why didn't this employee share this system with the others? Why did he think it was OK to slack off for 6 hours a day instead of doing 4 times as many catalogs? If this employee worked for me, I'd be putting him to work finding other things to automate!
In the past I've had many comments from people saying 'oh he should have kept it a secret' or 'he is getting paid to do X and if he is more efficient then why cant he slack off' or even 'oh no this is a disaster now most of that team will be laid off'
I'd bet many employees would be happy to work an hour or two per week. I'd be few employers would be happy to have employees work that little. It's not just a fear of being fired. It's a fear of the managerial mindset of "if they can do more each week, they aren't being challenged enough."
This reminds me of Toyota, which (allegedly) never let anyone off after process improvements, because that would undermine the trust which is necessary for employees to feel safe when suggesting improvements.
These stories seem to me like management failures — leaders haven’t built the necessary trust.
It's interesting how people expect workers to "earn" their salaries through suffering. It's almost religious. At the same time, lots of businesses charge their clients a percentage of their earnings and it's ok.
Readit News
I actually believe that there's a culture war implied in this debate; the question of who deserves to reap the gains of automation is more than just philosophy or ethics. The question "is there inherent nobility in work itself?" seems to be just as much a political divide as any of the current popular hot-button issues. Your gut reaction says a lot about the regional values of where you grew up, whether you'd ever support a basic income, and whether you believe that someone's refusal to work should condemn them to destitution.
The closest comparison is the attitude people have if they find a wallet. In Japan, you will get your wallet back with cash intact. Yet in the west, there exists a large contingent of people who believe with all of their heart that God wanted them to find it, that the person who lost it should have been more careful, that they are just having a lucky day. Unless God shows up and declares one side to be ethically correct, it will remain a toss-up.
One thing I find fascinating about the article is that it's assumed the cleverness was the code written to automate. This is incorrect; the cleverness is in noticing when a task can be automated. Typically, the code itself is trivial.
Anyhow: automation is surely one of the best reasons every person should learn a little bit of programming. And even with that task accomplished, I suspect that the rate of people seeing the opportunity to automate will stay roughly flat.
I have told my work more than once that if they wanted to get the most out of me they should put me on the "front line" for a month or two, and let me decide what needs to be automated. It has always been laughed off as me being cute.
Loading comment...
Loading comment...
Loading comment...
Loading comment...
Loading comment...
Loading comment...
Loading comment...
Loading comment...
Loading comment...
Loading comment...
A large part of how America sees work, poverty and wealth was historically influenced by the Protestant Work Ethic, and I think that lingers quite a bit today. I think it's why a lot of people view the poor as lazy (because obviously if they weren't lazy, they wouldn't be poor, right?).
If you fervently believe hard work will lead to success, how else do you explain the unsuccessful?
1: https://en.wikipedia.org/wiki/Protestant_work_ethic
Loading comment...
Loading comment...
Loading comment...
Loading comment...
Loading comment...
That said, it seems incredibly wrong to judge someone for being clever enough to relax and get paid for it. And if someone enjoys relaxing as much as I enjoy coding, who am I to say that I'm righteous and they are a loser?
Loading comment...
Loading comment...
But even though RPA is mostly screengrapping and macros, we’ve found it impossible to teach to people who aren’t developers.
Similar with better BI tools it’s become possible for sql savvy business process people to do BI, but without s fundamental understanding of data efficiency, which we can’t seem to instill in these highly educated people, what they make is often useless because it slows the systems.
Programming is completely trivial, but understanding what you’re doing, and why. Is much harder to teach than programming. Especially when you’re working toward productiveness where you can’t just write best practices for everything because best practices are often unnecessary for some systems and necessary for others.
I know this wasn’t really that related to the article, it’s just a general observation, and believe me, we tried to decentralize our RPA processes because maintaining them is hell.
Loading comment...
Loading comment...
Loading comment...
Loading comment...
I love this article because it changed my mind. I was one of the redditors who urged FiletOFish1066 to fess up to his employers on the basis of some moral high ground I felt I occupied. I see now that I made the mistaken assumption that work == goodness and went on from there.
Nietzsche would hate this question: https://en.wikipedia.org/wiki/Master%E2%80%93slave_morality
Working is the opposite of noble in the traditional sense of the word.
Loading comment...
Loading comment...
Loading comment...
The amount of effort required to produce that value, helps to dictate market conditions and the amount of competition; aside from this, ultimately I don't think effort matters so much when you consider it in terms of B2B transactions.
Eventually, if a service is easy to supply—competition will drive down the price—and the economic system will readjust accordingly.
--
Strangely, it's only when you consider an individual in permanent employment that automation seems to present itself as a dilemma.
There's definitely a lot being said about automation. We're regularly told via news outlets that a large percentage of the populations' jobs will be replaced by robots.
But aside from the idea of universal basic income; I believe there's a more general trend towards working independently, i.e. in a freelance capacity.
Maybe automation becomes far less of a dilemma when this is this case?
Loading comment...
Loading comment...
The code is almost never trivial either. It often involves integrating complex systems and making sure that they work which, if done right, involves writing several unit tests.
Using God is a poor excuse to determine ethics because there's no evidence one exists. It's especially a problem when you don't share the code because then, instead of creating improvement to the job for the company as a whole, you've written a pass to be lazy. The real job comes from supporting whatever you write to the masses. If you don't have any interest in that, you're simply selfish.
The problem is people react in different ways, but it seems like the most common way is to not tell anyone which in my mind is foolish because even if you do get fired, you've improved your skills enough to find a better job anyway. Not only that, I can just as easily come up with an example of someone getting promoted for automating job tasks.
> Anyhow: automation is surely one of the best reasons every person should learn a little bit of programming. And even with that task accomplished, I suspect that the rate of people seeing the opportunity to automate will stay roughly flat.
Absolutely. A minor observation I have, living in Operations/Finance. Don't merge cells in Excel. Observing a spreadsheet is a fantastic indicator of an individual's knowledge of automation vs manual process. Someone that uses lists without merged cells is someone that not only can save days of of the year with pivottables, various forms of looking up, but probably has the idea of 'tables' 'if' and 'for' in their head.
This is a great kicking-off point for coaching through ugly VBA. I like VBA. It's also often the only choice in corporate environments. But it is an option, and the chance to coach someone that's on the edge of...
> I suspect that the rate of people seeing the opportunity to automate will stay roughly flat.
...to push over that edge.
Loading comment...
Agreed, there's a lot of meaty ethics and philosophy tied up in this issue.
For most of my life I've tended to believe in the nobility of work, that it gives my life meaning and purpose.
But as rates of automation increase my children (or more likely their children) may well seek different ways of defining themselves.
Before that can happen though there'll have to be some fraught and difficult changes to our societies.
The devil is in the details. Robustly automating anything of reasonable complexity involves a lot of implementation hickups, dealing with corner cases, gracefully failing, and adding structure and regularity to otherwise disparate, adhoc and unstructured components.
It takes skill, experience and a lot of effort to do this without it immediately falling over.
Loading comment...
Called the guy when I found it. He totally panicked. Was odd.
When I handed it to him, that face! Worth it.
Amazingly, he proceeded to try and give me the cash. Was an effort to decline.
At the time, I really needed a warm fuzzy. The lost wallet was a great opportunity, and I got a good one.
But, our conversation basically centered on, "who does that?"
Indeed. The stories of Japan make me want to visit just to soak a little of that in.
Loading comment...
Loading comment...
I thought about this too. Pretty much everything I've automated turned out to be way easier than I assumed and I ended up feeling dumb for not realizing I could have saved myself time by doing it sooner.
I don't understand what you're getting at there. If someone refuses to work, that would seem to mean that they are able to work but choose not to.
We're not talking about someone who is actually unable to work because of some physical or mental limitation and may need assistance of some sort. We're taking about someone who could work but doesn't want to.
What possible obligation do I have toward that person? I don't see any. Of course I don't think they should be, as you put it, condemned to destitution. But what on earth makes it my responsibility to give them anything at all? Do I owe them a living, simply because they refuse to work?
There are tremendous financial opportunities waiting behind automation of expensive tasks usually performed by developers.
For many of those tasks, the moment is right now, and the code itself is not trivial.
Loading comment...
these days I get brain chills whenever I do something un-intellectual but very sensory-based: crafting wood, molding things, taichi..
Work today is a twisted version of sharing group survival/happiness.
I think you'll find that most people who 'keep the wallet' are probably not religious and don't think about it the morality of it all that much, whereas those who are regular temple/church/mosque attenders would be among the least likely to 'keep it'.
Loading comment...
Loading comment...
I'm experiencing a shift in that thinking right now. I write reusable, modular, tested code. My co-workers don't. I use a project management system (Phabricator, on my own personal server, which I maintain); the company doesn't. For most of the last year, I've used these to produce more and better code than others have, but my responsibilities have only expanded while my pay hasn't.
I've vocally evangelized these practices and I'd love nothing more than to see them get adopted by the other developers, but so far it's not getting any traction.
So I'm shifting towards logging the value of the work I produce -- regardless of whether I'm just copying in a file from my extensive library -- rather than the time it took me to accomplish the task.
And starting to look for a new job.
Loading comment...
Loading comment...
Loading comment...
Modern web dev is fantastically more productive and efficient than it was 10 or 15 years ago.
Most/many SAAS apps are substitutes for aspects of what previously would have been part of a developers job to put into place.
Loading comment...
Loading comment...
Loading comment...
Loading comment...
That's not always true. In at least 2 different organizations I worked at they were creating a combinatorial mess of search screens and/or reports.
Using a little bit of meta programming, query-by-example forms, data dictionaries, click-able drill-downs, and modular design; such "reporting stacks" could often be simplified into either a fewer number of screens and/or designed in such a way that a non-programming power user could configure most reports on their own. Allowing CSV exports of query results also reduces the number of "paper" report requests because Excel users can then format their own.
The result is something that needs roughly 1/3 as many programming hours to update and maintain.
One caveat is that you have to know the domain fairly well for it to be practical. You have to learn the domain patterns and habits in order to factor those patterns into meta-patterns. When I tried it as a newbie to the org, I usually did it wrong.
They do that to and have always done so. It's barely remarkable because it is expected and part of the job. The problem is you can't benefit from that, as soon as you automate one part, you are given other tasks.
Loading comment...
And really, the existence of computers is the result of automating the job of human computers away. The entire history of computer science is this.
The difference is that these guys hit a local maxima, and just ... stop. Instead of moving up to the next level and making more money.
Loading comment...
Loading comment...
Not pretending for a second I'm safe.
Loading comment...
Loading comment...
Loading comment...
Loading comment...
Loading comment...
One such tool is very popular here in South America:
https://www.genexus.com/en/global/products/genexus
GeneXus™ streamlines application development by automatically generating everything from databases to code, frontend to backend, and server-side to client-side services. It’s not magic — just a smarter way to create smart technology.
It ends up being a kind of DSL.
Loading comment...
Loading comment...
I remember going up to one of the senior management people in the company I worked at a long time ago and pointing out how I'd saved the company from having to spend salaries and other overheads on 12-20 more people by automation. If the salary for each person was X, I asked for a salary bump of 3X. They gave me a bump of only 0.5X . I eventually pushed it to 1X but that experience taught me that most of the time, extra value you deliver rarely flows back to you in a reasonable way.
And from that point on, I stopped treating my job as an extension of my identity or fulfillment of purpose. It became a place where I primarily had a cold hard contract to deliver X value in exchange for Y returns. And if I was ever to work again in a company with similar opaque practices on salaries, any increase in Y returns would be best negotiated before showing my entire hand on how much I could increase the delivery on value X.
Indeed, the best work is done when you do it for yourself. People basically sign their brains away when they go to work for Facebook and Google. Those companies will be likely to get B players no matter how many seemingly great people they hire. The 4.0 MIT grad who can recite chapters from his CS401 class isn't necessarily an A player. Most of the A players I know are either ex-Facebook/ex-Google or turned down working at those places because they have more important things to do with their time.
The real A players are much harder to find and are much harder to value. Without ownership in what you do, there is a high probability that you will not be at your best. If you need to be paid to do something, it is unlikely to be what fulfills you.
Loading comment...
The output is actually even better in my experience. I know in the tasks that we've automated the output is always 100% consistent, which is more than can be said for the previous human output.
Also there's a lot of value in having someone on hand who actually understands the process rather than blindly trusting in a script. They'll more than pay for themselves when it comes to future enhancements or debugging.
And I say all of this as an employer - my employees are positively encouraged to automate as much as possible.
Loading comment...
I think in the long run, acting in the best interest of the business when you are employed for that business would result in superior income/career than doing otherwise.
Another option is finding possibilities for automation that could apply to other companies with similar problems, and starting a separate company selling such automation services. A consultancy could work, too.
Their boss cares. This is capitalism, and capitalist ethics say you should be fired if you're idling and not continuing to actively labor for the boss anymore. She's not getting anything in return for your salary. You more than likely signed away all rights to the fruits of your labor when you took the job. That means "your" automation is really your boss's capital, and you have no rights to be perpetually compensated for it.
So, if you ever automate your own job, don't tell anyone. Also make sure to make your automation so arcane and impenetrable that no one else can hope to use it.
Loading comment...
Loading comment...
Loading comment...
This is why, in 19th century, they've used to call wage labor, as opposed to self-employment, "wage slavery".
You are selling your time, not the goods you produce.
https://en.wikipedia.org/wiki/Wage_slavery
Loading comment...
Loading comment...
Loading comment...
Loading comment...
Loading comment...
If you don't value what you did, why should your employer?
Also, why should an employer raise your salary based on the fact you are automating stuff? It's part of your job, after all. That's what programming is about.
Loading comment...
My advice is to not fight this state of affairs. Figure out your own way to stay productive. Divide up your spare time between coming up with ideas for your employer and doing side projects. Take long lunches with your coworkers and leave at 4.
You can find happy professional nirvana but you have to believe in it first.
Loading comment...
Loading comment...
In practise, achieving some sort of "steady state" or status-quo doesn't work for a few reasons:
1. Inherent system complexity ensures something always breaks. Human attention is always needed.
2. Markets evolve rapidly due to technology changes, regulatory changes and the very nature of markets: Strategies and ideas that worked in the past cease to work in the future.
Loading comment...
Loading comment...
Loading comment...
Loading comment...
Well, no shit. That is what the job of a programmer is - to keep automating things.
There are an INFINITE number of useful things we need to do as a society, so we shouldn't be upset if we automate one of them away. Move on to the next.
Of course, programmers should make sure they negotiate strongly to get compensated fairly for the work. I think it is a bit short sighted, however, to worry that you will end up like the guy who automated his job and was then fired and replaced by a lower skilled guy - who cares, you SHOULD move on at that point if the company doesn't want you to automate something else. There are plenty of companies that will hire you, and you can use the example of the previous company to show you can do it. This time, negotiate better compensation.
It is not necessarily an easy path, it takes time, and there's going to be trial and error involved and although the discussion is about automating 100% of a job away, there's many other possible outcomes such as effort-multiplication, getting rid of the grunt work and gaining more time to focus on deeper problems.
This is effectively "out-of-band" work that is a great experience for the individual but which _many_ organizations do not condone. A LOT of workplaces don't tolerate workers doing stuff that they're not being "told" to do.
Loading comment...
Back in the late 90s I worked at a place that sold all kinds of automotive parts. Everything from nuts and spark plugs to turbochargers and large assemblies. The secret sauce of this company was a small team of people who worked through thick supplier (paper) catalogs and figured out which parts from different suppliers are in fact interchangable by comparing their specifications. This all went into the database for the sales team's use.
Well one younger guy in this team worked out a way to largely automate his job using OCR and spreadsheets. Instead of taking 8 hours to work through his day's load, he would do it all in an hour or two. Then he'd slack off for the rest of the day.
Soon the manager found out but the manager was not upset, instead the manager was disappointed. Why didn't this employee share this system with the others? Why did he think it was OK to slack off for 6 hours a day instead of doing 4 times as many catalogs? If this employee worked for me, I'd be putting him to work finding other things to automate!
In the past I've had many comments from people saying 'oh he should have kept it a secret' or 'he is getting paid to do X and if he is more efficient then why cant he slack off' or even 'oh no this is a disaster now most of that team will be laid off'
Loading comment...
Loading comment...
Loading comment...
These stories seem to me like management failures — leaders haven’t built the necessary trust.
Loading comment...
Loading comment...
Loading comment...
Loading comment...