I realized at my last job that I was working to essentially replace myself and my co-workers. It was a pretty sobering thought.
We often joke about training our replacements but we're definitely in an age where it's just as easy (if not easier) to build our replacements.
This doesn't have to come in the form of AI which can ingest requirements and write code. It typically comes in the form of automating specific aspects of our current job. Build systems, pipelines, workflows, etc.
It's nice to kid ourselves and think of it as work intended to improve productivity but from a company's point of view the value is decreasing overhead and cost which comes in the form needing 1 person to do the work instead of 10.
Cross your fingers that you're the 1 and not one of the 9 :).
No need to cross your fingers. The demand for software is still out-pacing the creation of new developers. Those 9 have nothing to worry about, other than perhaps dusting off their resume.
> I realized at my last job that I was working to essentially replace myself and my co-workers. It was a pretty sobering thought.
You've just described the purpose of the entire software industry. Did it really not occur to you that writing systems to automate tasks would displace anyone doing those tasks manually?
Replacing yourself with something you built is what engineers should strive for.
Engineering problems just move higher up in the stack. Few people are coding assembly code now days, and in the future few people would be writing in other low level languages.
Yes the employer is dumb for not realizing the job can be automated. Yes you are smart for writing code that automates the job. But I feel, as an employee of the company, it is un-ethical for you to knowingly see an extreme inefficiency and hide it for your own personal gain.
Also, it seems like a huge way to waste your life. Find another job where they can actually use your skill set to do something meaningful.
It may or may not be a waste, but why do you believe it to be unethical? The employer employee job is a contractual one. When it is the company that sees me as an inefficiency I will be eliminated for the companies gain. Similarly when I the employee see an inefficiency in the company, I can eliminate (automate) it for my gain. This is the symmetry in the contractual relationship. To say that this relationship should be asymmetric is to grant even more power in the employer-employee relationship to the employer.
It's only unethical if you're being paid hourly, where you're being paid to work a certain amount of time, and you're just sitting around goofing off while your scripts run. If you're getting paid salary, then you're getting paid to get the job done, regardless of how you do it. However, if part of your salaried job description is to find ways to do things more efficiently, and you don't share your efficiency implementation, then I can see how that would be unethical, but that is usually at the executive level, not the coder level.
So its perfectly ethical for a company to hire you for $50K to produce say $100K revenue, and continue paying you $50K even though you produce $1M in revenue after automating (or even fire you and keep the code)?
Why is it ethical for companies to get away with paying you FAR less than the value you produce for them?
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.
imho a great sweet spot is turning most of that free time into learning new skills. It's fun, productive, and not frowned upon, even if the class has nothing to do with the current job.
The key for this type of setup is to make sure that they understand your job is like that of a security guard. You're there for when all your carefully coded alarms start going off. You're not there to help shovel the sidewalk because then you might miss your alarms.
As long as that is properly understood you can get a contract that is permissive enough to allow you to work on something else at work when nothing is burning. Even if you have to offer a reduced salary, it's worth it.
Another option is to go the work on OSS route, especially on tools you use for work. After a couple years of doing semi-fulltime OS work you'll be commanding double the salary.
The key to this, and I meant to edit this into my comment, is to be super-responsive to any requests. Always be willing to drop whatever you're doing at a second's notice and help whoever it is that thinks you might be able to help them out. The word gets out and everyone in the company just loves you.
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.
A system that requires no outside intervention to perform its job optimally is equivalent to a solved problem. So quants will be out of a job once we understand how to perfectly trade on the stock market.
I disagree, the solution to remove stock market traders is to figure out a way to examine financial data and projections to such a fine degree that stock trading is no longer a sensible thing. Imagine a currency trader focused on USD & CAD, what would happen to their job if Canada decided to permanently pin their currency on the USD with a guaranteed exchange of .5 USD for 1 CAD, the markets surrounding arbitraging the currency would dissolve as .5 USD would always be 1 CAD (now in the real world there might be stability speculators, if Canada was viewed as politically unstable there might be a purpose to purchase .4 USD for 1 CAD, but ignore that for the purpose of the scenario).
Well, you are making quite a lot of assumptions here:
- currency is very different from equities - while one could argue that a central bank deciding to peg it's currency to $ is a realistic scenario, it simply doesn't make sense for equities (an equity is basically a right for present and future earnings of a company - good luck 'perfectly' predicting that !)
- as you note, there would still be speculators, since there is always uncertainty. There are numerous examples of countries pegging their currencies and then when unexpected happens...
- traders / sales would still compete for order flow of the clients (and get the cut), so there would still be a game to be played albeit for smaller margins
To name just a tiny fraction of things that'd be required for a perfect stalemate between automated stock trading platforms (due to them all being able to predict the market with perfect accuracy):
* actions of any given platform doesn't meaningfully influence the market
* all have ability to forecast weather with 100% accuracy
* all have ability to perfectly predict human behavior
* all acquire the exact same news at the exact same rate
* all connect to the same exchanges with the same latency
* all have the same amount of capital to leverage trades
Simply put, there are incalculable ways for a trading platform to gain advantage over another, so I don't think this will be an issue in many lifetimes.
>> * actions of any given platform doesn't meaningfully influence the market
Yes - this... Buying or selling even 1 share in the markets adds information to this giant calculating engine. Anything you do will alter the course of the future.
I've never seen a backtested strategy that didn't look great on paper. The moment you drop it into the market - you can take a steep discount to your expectations.
I have the same feeling that "automating myself out of a job" is the goal. Personally, I can't imagine anything else because it always feels incomplete (sometimes even dishonest).
Hi! I am a co-founder @ KloudTrader. The get started buttons don't work because we haven't launched yet. And the list under "What does Narwhal offer" are not links, they are just a list of features. Anyway we are launching this week, we would love if you could signup for our early access list(https://www.kloudtrader.com/#getnotified). We will notify you as we launch. Cheers!
And the beauty of being a trader/quant is that once you come up with such an automation, you will capture a lot of the upside as the company will not want to have you leave for a competitor and implement a similar strategy there.
The employer is paying you for the product, not the effort. I see no moral quandary here, nor any compulsion to notify the employer. They're getting what they want, that should be the end of it.
EDIT: And I would add, for anyone that has automated their job in this way...what you should really be doing is scaling it up, and finding other companies who are probably paying employees to do the same thing. Then start your own company that does whatever this task is as a service.
Maybe we both have loose morals but I don't see it as cheating the employer anymore than one "cheats" an employer by driving to work instead of walking.
I'd say it's that driving is easier for you, but they get the same result - you attend as necessary. They shouldn't care how you get there as long as you do your job.
>and finding other companies who are probably paying employees to do the same thing. Then start your own company that does whatever this task is as a service.
Careful, if it gets out that you wrote the code to automate your job as a coder while actually at your job, your company most likely owns that IP.
I am still in academics so I have a question about this. If your company owns this is, what shouldn't they be rewarding you generously for making it? They are making money out of your extra effort/work. I get that employees who want their own ip should have the right but if the company is paying you extra and giving other rewards and removing the headache of managing your own company, is that not good?
Only if your employment agreement says so. Most people hired as programmers, yes, that's true. People who are hired as other things, and end up automating things, well, that's not so clear.
shouldn't they be rewarding you generously for making it?
Yes, in theory.
In practice, an employee's power to negotiate wages is limited. At some point, the employee just needs to work to eat/pay rent/etc.
Now, in most areas (of the US), software developers already are paid generously. Even in lower paying secondary markets, software dev are usually paid significantly above local averages.
And, anecdotally, that pay is often for a much "easier" job, where "easier" means less stress and fewer hours than professions that generate similar salaries (engineering, accounting come to mind).
True, though presumably if you have an automatable job, you're not actually employed as a programmer and as such may not have a clause like that in your employment agreement.
You probably do. IP assignment is boilerplate. I had it in my contracts at Ross (the discount clothing store), Radioshack, and a local cheesesteak joint between 2012 and 2015.
The employer chooses what he wants to pay for, unfortunately. Some employers will feel like doing this is a breach of trust, and some will use it as a base for firing, and some might even call it theft and press charges.
> for anyone that has automated their job in this way...what you should really be doing is scaling it up, and finding other companies who are probably paying employees to do the same thing. Then start your own company that does whatever this task is as a service.
These tasks might not be worth selling as a service, they could be relatively trivial yet very context specific... I suspect this is the case, and that the real issue is with the employers lacking the insight to realise the these tasks _should_ have been automated and have the initiative to do so as soon as possible.
More specifically they probably neglected to employ people between the grunt worker and executive positions that would _have_ the insight to automate these tasks as soon as possible. That's basically corner cutting in terms of employees, in which case perhaps they deserve to be exploited, the funds are correctly being appropriated to the people who realised they needed to be automated.
EDIT: to be clear I don't find it 100% morally acceptable, going behind the employer like this is underhanded of course, but it can be somewhat justified as I outlined above. I suppose the alternative is to explain to the employer how it should be done and do so and hope to gain some kind of promotion or compensation, but that entirely depends on the moral standards of that company.
I completely disagree with your first point, and agree with your second with caveats. The employer is usually not paying the employee for "the product"; they're usually paying for the employee's time and general ability. You can see this simply by the fact that most employees are explicitly paid a rate per hour/day/year and not something closer to a piecework basis. Differences in productivity don't effect the pay rate nor does the estimated value of the product. Employees don't work on a "fixed fee basis" on their assignments and for maintenance like work their pay doesn't fluctuate downward when the value of their product diminishes nor upwards when it increases. The product is a consequence of how the employee is directed to spend their time. If the trade is something else, it should be clearly stated in the employment agreement/contract that they employee is paid on some other basis. Unilaterally recasting the terms of your employment into some other basis is merely rationalizing not providing the real thing for which you're being paid.
For those that might say that a job description sets product based terms for employment, it's rare that they are offered that way. Almost all the job descriptions that I've ever seen (and all that I've written) have some sort of phrase to the effect of, "...and other work as might be assigned." A job description isn't a Statement of Work, they're usually just general expectation setting devices.
I've automated large chunks of my job away, but I've never felt that I ended up not having things left to do as a result. There are always more tasks to automate and more problems to solve.
I get the impression from these stories that the dishonest part of what the self-automaters are doing is that they could do other tasks and use automation to increase their productivity, but instead chose to keep their productivity the same and relax with the extra downtime.
I usually write scripts in Python or Bash, depending on the task. I've had a fair amount of success using a cron for scheduling, but I've come to really enjoy using Jenkins for automated tasks. A lot of tasks make sense to trigger off of events other than the time and Jenkins is quite flexible in that regard.
Heh. I’m an intern on the ops team at a small-medium company (just under 150 employees, at least 50 or so engineers, ~$20 mil rev), and we use Chef for configuration management. I’ve observed that some members of the ops team are actually afraid to converge servers. I also find the precedence rules, node variable (?) rules etc to be horrifically confusing. I haven’t worked with Ansible before, but it sounds more similar to how I would implement it if I hacked away at the problem for a few months (my understanding is ansible basically just lets you run arbitrary scripts thru ssh).
Being able to have chef integration tests (or are they considered unit tests?) seems really powerful. But holy fuck does Chef have a ton of (what feels to me like) cruft
Chef got to where it is today because people used it to build systems at a scale that was simply not feasible before. And as it grew more capable, people built more tooling in and then leveraged that to build even larger systems.
So, if you're not building systems at the Netflix or Amazon scale, then Chef might have features and tooling that you don't need -- today. But as you grow and you find you do need those tools, they will be there.
I can tell you that Chef was a key part of the system for taking the Raytheon GPS OCX system and letting us build out an entire virtual datacenter in a matter of hours instead of months. Once everything is racked and stacked and cabled together, just press the "Go" button and everything builds itself and installs itself in a fully automated way.
If you're not familiar with GPS OCX, that's the next-generation ground control systems for GPS satellites -- both the current generation of satellites that is currently aloft and the next-generation fleet that is being developed.
With regards to Ansible, there are many lessons that the Puppet and Chef communities learned years (or decades) ago that are being re-learned yet once again -- like ssh isn't a very scalable communications mechanism when you start talking about handling thousands of servers.
The concept of "just let me run my custom scripts everywhere" is a nice one, so long as you're talking about a dozen or so machines, each of which is a unique snowflake "pet". But when you want to start building a cattle farm, that method stops being so useful.
Straight out of PhD. The interviews went smoothly in part due to earlier experience in an ISP, but these days Google takes in SREs with 4 x coding and 1 NALSD interview. It's the stuff talked about in https://www.oreilly.com/library/view/the-site-reliability/97... and there's quite a few Google-organized workshops on this.
Does "increase their productivity" equate to increase their pay? In most cases that's a no unfortunately. It's up to the "automator" what they make of their time imho. If they're wasting time playing games it's their loss since these opportunities don't come by too often. If they use it to grow their knowledge and skills that's great and well earned since the company only expected them to do their workload, the hard way. And it's fair.
And it is only not fair to the peers whose work cannot be automated, and as someone here said, it's a temporary privilege to be working in programming, we're in a different world, higher pay, more learning opportunities, more leverage than other jobs. But, nothing lasts forever. We're going to be automated away eventually.
>I get the impression from these stories that the dishonest part of what the self-automaters are doing is that they could [...] increase their productivity, but instead chose to keep their productivity the same
I get the impression that the dishonest thing the employers are doing when they become aware of the automation is that they could increase the person's salary, but instead they keep it the same...
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.
I hate to burst GP's bubble, but the attitude and environment at his next job probably won't be any better in regard to "best practices." It's extremely difficult to gauge how your attitude toward development compares with a prospective team's after an hour of chatting. I became a manager last year and quickly discovered that changing others' behavior and habits is next to impossible. And if he does happen to find a new team that matches his work ethic he can be certain that 1 or 2 years down the line it won't any longer.
I think the only two ways to avoid this is to become a contractor and switch gigs every 2 years, or start your own company and hope the people you hire share your attitude.
I've had very good luck changing the behavior of junior developers and moderate luck changing the behavior of mid level developers that are hungry for a promotion. I can count on my fingers (couldn't say if that's one hand or two) how many senior devs I've gotten to come around.
If you're interested in progress and growth, I can say with a high degree of certainty that what you don't want to do is apply to work on a very stable team. These people are always confident that they know what they're doing - even when they agree that the outcomes aren't great. They've had lots of time to practice their rationalizations and that kind of cognitive dissonance can be pretty jarring/aggravating.
By definition, starting your own company or contracting will avoid that situation, but you don't need to take your ball and go home just to get the right kind of environment.
I had senior people change habits and practices but at the expense of huge failures or years of leading by example. The patience and the effort are humongous and almost ridiculous when you compare them to how quarterly or even bi-quarterly planing cycles look.
Early in my career, the concept that someone might know of a showstopping problem and chose to do nothing left me appalled and feeling rather betrayed.
Fifteen years later I sit in meetings telling people (some of them still older than me) not to touch the stove because it will hurt, and I have to patiently wait until someone gets hurt before we can discuss the proverbial oven mitts.
The problem with doing something right the first time is nobody appreciates how hard it was.
> The problem with doing something right the first time is nobody appreciates how hard it was.
Sometimes if you do put in quality and do it right in development it costs you in time and then by perception.
When you hit the ship date over finishing the iteration/version/product you have problems after ship from external customers, when you do it right and handle the problem in development before ship, you take a hit in perception internally.
The problems after ship can harm a product/company more than a slight delay in shipping, but today it seems people don't care as much as there is more specialization and larger teams where it is 'not my problem'. Some clients/project managers see a bad product shipped on time as good, and a good product shipped late as always bad. The external perception should play more into that perception not just hitting their part of the project goals/milestones.
Hitting dates is hugely important, but messing up a product with the customer can be deeply problematic. Noone truly remembers a late product after it ships and is quality, creative and functional, they remember a bad product.
I prefer the Valve Time [1] philosophy, get the product right over the date, and don't set dates until you have the product actually ready.
Why would one need to become a contractor to switch gigs every 2 years? Seems like that’s the new normal with employers not wanting to invest in employees anymore.
As a non-developer, how can I hire someone (or a team) like OP that focuses on automating menial stuff and focuses on the most important?
Does a development agency that focuses on this model exist? Of course they should be paid more per hour (or other unit) than your average, less optimized agency, but the sum total should be less than hiring inefficient agencies.
(P.S. I understand the best developers probably don't want to start or work at development agencies, but assuming there are some.)
I’d hope they all do. If you get an experienced developer they should want to automate all of this. My former boss took the model of improving processes and revenue, then taking a cut of the difference ongoing. He had financial freedom already, so this was the best use of his time. With some companies you aren’t given all of the information to make the right decision for efficiencies sake, or they write such a rigid spec there’s no room for improvement. Personally I love spending the time where I can see it saving so much time for the end. You might not need an agency, you might just need a developer to help write what you want to create and work a spec that you can give to an uncreative team/agency to create. Agencies make a decent amount on the discovery phase, so you’d be cutting that out. At that point you could go directly to someone that could implement it.
That's a great idea, will definitely try this out.
Seems to be a good idea to separate out the architecting from the actual implementation. Makes sense, because if someone knows they'll have to be implementing, it could cloud their plan for the ideal solution. Similar to separating out design, UX, and development roles.
Body shops don't work like this. Their purpose is to put butts in seats, regardless of whether or not that butt is attached to anything else that is functional. Functioning in this manner would actually be counter-productive for them, because it would reduce the number of butts that they have to put into seats, and would reduce the number of seats into which they could put butts.
If you know of a development agency, odds are that it is probably a body shop.
The places that do work like this are more like Unicorns. And Unicorns are damned hard to find and hire -- or get hired by them.
Part of the problem is that to effectively automate a task or series of tasks you need to fully understand what is being done. The person currently doing this knows what they are doing (you would hope), and may understand why they are doing it (this is not guaranteed).
In many cases, what somebody does (and why) is not documented, or if it is the documentation is most likely out of date and inaccurate.
To effectively automate a task, you need to fully understand what needs to be done as well as have the skills to do the actual automation. Getting somebody in who is unfamiliar with the job, can work, but in most cases you will end up with an off the shelf system that has been customised to perform the original task but come with a large overhead of maintenance that may take more work than the original task.
My suggestion would be that rather than get an outsider to create the automation tools, up-skill and authorise the staff doing the work now to allow them to gradually automate the process. Make sure you make it worth their whiles to automate.
1) As person with business knowledge, vision, plan, etc, I should fully document the business goal and why we're doing it and what we're trying to achieve at the highest level, then work with the developer to figure out what should be developed to achieve that and where to automate.
2) Don't hire outside person or agency, but bring someone in full-time or as a part-time partner for the long term and incentivize them to get better and better?
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.
I don't hand-create machine code. I don't write assembly.
I write in the highest-level language that still lets me fully specify everything I care about, and then all of the lower levels of code generation are completely automated. Programmers have always automated programming jobs as much as possible.
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.
CS encompasses way more than automation. Graph theory, ADTs, complexity analysis (just by way of example) are all very relevant, even if the computation is done manually, by hand.
A lot of computer science presumes a very abstract computer; a human and a modern machine apply equally well.
> Instead of moving up to the next level and making more money.
That's assuming your employer will "move you up" and you'll make more money. Or that a future employer will see value in you automating your job. Then there's this story from TFA:
> a user posting as AcceptableLosses wrote, “They took what I had developed, replaced me with an idiot that they showed how to work it, and promptly fired me for ‘insubordination.’ I had taken a business asset that was making them $30 grand a year profit and turned it into a million dollar a year program for the company, and they fired me for it to save ~30 grand a year on my salary. Job creators my ass.”
Which sounds so entirely stupid as to be almost incredible. Why not just take this guy and move him, even sideways, to another role he can automate? But I believe him, because I've seen a lot of stupidity in Big Companies, especially the old school ones.
Re: Modern web dev is fantastically more productive and efficient than it was 10 or 15 years ago.
I have to disagree. The esthetical expectations of the user/customer are higher now. If it's not "in style" they think you are sticking them with old tech. And you have the desktop/mobile split that frameworks only get half right and require days of black-box fiddling to get working right on all devices. And JavaScript gizmos often "break" as new browser versions or related components come out. It's almost as bad as the "DLL hell" that desktop applications used to face.
From a purely utility standpoint, I was much more productive back then because I only had to make it work and be easy to use, not "pretty" and animated with toys or the latest style fad.
Hmmm, I just tried to install emacs on windows. With all dependencies is 210meg! Tried installing vnc on Ubuntu following commonly found instructions. Required installing 119 packages (each of which is likely built from several libraries). I also tried building smb from source. It required tons of dependencies to be installed. Is npm actually any worse than any other environment?
> If it's not "in style" they think you are sticking them with old tech
Is that even true? Is there any survey showing that users consider those bad or old tech? Because with things like the reddit, ebay, paypal, gmail redesign, the common thing i ve noticed is that nobody asked for those.
That's just my experience. If a customer pays for a new gizmo, they want the "latest and greatest". If it doesn't look latest and greatest to them, they feel slighted. I'm not saying it's necessarily rational, only that it's the way customers on average react. They don't always say it directly, but word gets around. I've seen it many times. Humans judge books by covers.
As far as old-looking sites like Ebay, if an Ebay competitor appeared with equivalent services and product choices, yet LOOKED fancier/stylish, Ebay would start to lose customers. Lucky for Ebay, no such site exists. (If they appeared, Ebay would probably spend on a visual revamp.)
True, but it's hard to get new customers unless your "art" keeps up with the Joneses. A revised product is still usually more similar to the last version than another vendor's product such that existing users will usually stick around because a same-vendor overhaul is the least of two evils to them.
A lot of work that many programmers/coders do is not maintained and no one will use it after they leave the company. Not always but often enough for me to notice it. Every company has derelict projects that once had use or are still used but in a non maintained way. Like a Jenkins installation that everyone uses but no one has any clue how to modify.
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.
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.
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.
That's been happening ever since the first computers. The first programmers hand-entered machine code, then someone automated that with an assembler. Then the first compiler automated much of the work in writing assembly code. Since then we've gotten ever more powerful languages, libraries, and all sorts of tools. None of this has reduced the demand for programmers.
Couldn't agree more, that doesn't mean it's always going to be the same. A lot of programming jobs these days are putting information from a database on a screen, then updating it in the database after it's been edited. Doesn't feel like that should be an impossible thing to automate in a fairly sophisticated way. Though that's been true for a long time and we don't seem to have made much progress.
I spent a lot of my career doing that. There was usually a fairly large gap between what made sense in relational database design, and what was convenient and sensible for users.
More importantly, "what is convenient for users" will frequently change and be expressed only vaguely by those users in natural language bug reports or feature requests. Converting that natural language into something machine-readable is programming, whether it involves typing cryptic strings into emacs or hooking together components graphically a la LabVIEW.
I remember that someone was considering making a program to automate a co-workers job, since it was just simple data entry. They never actually did it though.
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.
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.
As a sysadmin who started out replacing power supplies as a datacenter tech, and nowadays wrangles AWS auto-scaling groups, the idea of _not_ automating away the tedious parts of my job is pretty hilarious. I had one operations/support job where this was the case, and thankfully, I quit after one month.
If anyone out there has the gumption to cobble together a dev environment and automate away their BS job, yet can't get recognition from your employer; it is time to seek out a new job, you've certainly got the skills for something better!
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.
Think about the cottage industry of programmers who produce and maintain Wordpress websites for their clients. I think just like any other industry, there is need for products on many points of the [mass produced <--> bespoke] spectrum.
Those "operations" engineers can be moved to making sure Ops are running well at home (you apparently have an API) or into Technical Sales if they'd rather stay in the field. Informing the customer of all the configuration that is available to them, for example. Just because there's a nice graphical configuration tool, doesn't mean any clients are actually going to look at it when they have an issue. They'd much rather call you up and bitch about it. Operations guy's job is safe, but he might be able to address more customers than he could before.
Operations is a pure cost center. Cost centers only exist for the express purpose of being compressed twice as much this month as they were last month, so that you can make them half as expensive.
Developers are valuable. They create value.
When all the good Operations staff has left because they're tired of being treated like mushrooms, all the Operations stuff gets thrown over the wall and then the Developers get told that they are now DevOps.
That’s a really good point as it relates to costs between security and ops. My hunch would be downtime is your own business, but data and financial loss is everyone’s (either through liability, legislation, or insurance costs).
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.
One of the only discussions I've "Favorited" on Hacker News was related to this: "Is it unethical for me to not tell my employer I've automated my job? "
I see this possible in only 2 kinds of organizations
1. Very large - where you are a practically a number and work in a department buried deep.
2. Small - where there is a reasonable amount of technology but no desire or budget to upgrade. It's working, so don't touch it.
I look forward to the blog post in a few years with someone detailing how they're earning $1M/yr because they have 20 data-entry jobs they've fully automated.
I once landed a job by telling the CEO something like, "If you're doing it right, programming is all about replacing yourself with automation."
In Cybernetics there is a formal measure called Variety which is something like a limit or measure of complexity of a system. Programming can be considered the art of extracting the low-variety parts of a process into automation, leaving the high-variety parts to the (high-variety) humans. This process itself is low-variety. Therefore, from first principles, programming is automatable. Our programming environments will eventually look like automatic systems that we instruct with our intentions, and then they consult us as oracles to determine the high-variety parts of the necessary process, having automatically computed the low-variety parts.
In fact, this is already happening as fast as people can accept it. The limiting factor is not in the machines (they are already superbly fast) but in the psychology of the people involved. Most of the research and much of the technology already exists and is in many cases decades old. (Cf. "The Mother of All Demos" and Prolog.)
As time goes on, given the exponential nature of the meta-process, it will feel like a step function for many of us: one day relevant and employable, then the next day replaced by a machine and unemployable, and unable to learn the next thing fast enough to beat the masses of your peers competing against you in the same boat.
I realized all this years ago, and have been asking peers and coworkers, "If you could write a program that could replace yourself, would you?" However, to date, no one has taken the question seriously.
I find this article, appearing in a non-geek publication, to very heart-warming. Maybe people are finally catching on?
Anyhow, this is why e.g. Universal Basic Income is important: You're going to need it sooner rather than later.
Unless there is some essential economic activity that humans can perform that machines can't we are all on the "discard pile" of history.
I actually think we'll just mellow out and enter a Golden Age, but again, only as fast as we can accept it. Certainly the Universe is willing for us to live in peace and harmony, it's up to us to choose to, or not.
> "If you could write a program that could replace yourself, would you?"
I've done it a bunch of times, sometimes by accident.
In one case I was going to be assigned to do testing every evening. But I wanted to go home at 6 every day, so I automated the tests on my first day, then came back in the morning and started 'working on my next task'; never realizing that previously the testing job had been a full time position.
I ended up doing about 5 people's worth of work there that summer.
Of course, it's probably because the project wasn't particularly organized, and our team was explicitly given a free hand to find inefficiencies and fix them. Still, it's a nice story to tell people ;-)
It's great to do that, in the puzzles we're all trying to sort out in our daily jobs actually managing to entirely automate yourself out of a job is basically solving the equation.
Granted the value created by such tasks usually isn't fairly compensated so there are a lot of societal issues.
I use a calendar pretty heavily to stay on task. I automatically accepted meeting invites because my job was so boring going to meetings was probably the only good part. My managers found out I accepted them automatically and told me to turn it off. Instead of turning it off I put a 5 minute delay on the invite receipt. I was laid off for "attitude problems".
They said I didn't look at a meeting so they were mad when I'd show up a minute or two late. Of course no one cares when other managers showed up a minute or two late. This was at Charles Schwab. I'd never work or invest there.
> 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.
> Or they fire you because they don't need you anymore.
This is the kind of ridiculous thinking I'm talking about in my other comment. You just made your job into a cheap, automated process. That's the most valuable thing you could do in a company! If you did that in my company, you'd get a promotion and you'd be put to work finding other things to automate. You're the kind of person every company wants! Why would we fire you? If we're dumb enough to fire someone like you, you're better off at another company anyway.
If companies were run in a logical manner, then your thought process would be reasonable.
Sadly, while there may be some logical people in a company, many companies (most?) wind up not being run in a logical manner due to a wide variety of internal politics and societal issues.
What you hope (and pray for) is that the logical people in a company are not also sociopaths, in which case you are really well and truly screwed.
That's crazy, I don't understand how people are so negative about this. Sociopaths will NOT fire that person, they'd put that person to work automating other jobs. This is just how you run a business.
> Or they fire you because they don't need you anymore.
I think people are just assuming that the typical case here is someone automating their job to a degree where they literally don't have to do anything. I suppose that happens sometimes if we are to believe anonymous reddit and stackexchange postings.
What actually happens is that regular people who you would not assume are "programmers" start picking up computer skills and employ them in a piecemeal fashion a little bit at a time until eventually their day-to-day work becomes something quite different from when they started out.
This has been going on for at least as long as there has been a computer on every desk. I think "software engineers" should not be so smug to think that everything worth doing is something that they're going to get a chance bid on and then get a project managers or scrum teams to implement.
As for whether the person that does this gets fired or promoted depends on their skills at managing their peers and superiors, and what kind of environment they work in.
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."
That is a larger societal question, though - how long should you be able to live off work you do? Is it fair for a worker to work for a few weeks, automating a job that used to be paid year after year, and then earn that money forever?
Obviously there is a balance - a company shouldn't get ALL that savings (although in the long run, that savings would need to be passed on to customers, since competitors will also be able to automate the same tasks).
At the same time, I don't think it is fair (or sustainable as a society), to expect to live forever off of work you did over a few weeks (no matter how valuable that work might be).
If we allow people who automate things to live off the work of that automation FOREVER, then we are creating that sort of distopia that anti-technology people claim; that WOULD be taking jobs, because ALL of the benefit for the automation would be going to the automater and none to society. Society would still be paying the same amount for the resource, it would just all be going to the person who made it.
Obviously, it shouldn't all go to a company either, but if ALL (or many) companies in the same field also automate, they will HAVE to pass on the savings to customers to compete. This will provide a net gain to society, since the resource is now cheaper for everyone (at the cost of the people who used to do the job).
The cost decreasing with automation is REQUIRED to make it a net positive for society, and the automater taking all the rewards for the automation in perpetuity ruins that.
Take the complexities of society out of the picture for a moment and reduce the scenario to a family unit living on subsistence farming with nobody else around: if the family is somehow able to automate their food, water, shelter and energy needs, are they entitled to live forever on that work?
It's a great question a but obviously the catch is in "nobody else around" - morality only really comes into play when humans interact with one another.
In perhaps the simplest possible example, they live on land that belongs to a country that defends and otherwise manages it. In that case, paying a basic land tax should be enough. If there are other interactions between the family unit and its society, then other arrangements might need to come into play to allow them to maintain the entitlement for that lifestyle.
Right, but that is not what is happening here. Other people are still working full time to provide the things he needs; food, energy, entertainment, etc.
In return, he is giving the output of something he worked a few weeks on.
In your example, it would be like the son invented a machine to do HIS chores for him, but then sat around while the rest of the family still did their work
That's a great example. At that point, it's up to the family and the son to negotiate what's acceptable. Ultimately, whatever arrangement they choose, the family unit benefits.
I think where this analogy breaks down and becomes gray area in modern society is when the group unit that benefits gets too large to ascertain where the gains are accruing.
We're biologically wired to optimally deal with groups of ~150 or fewer people.
Society already accepts that though. Look at copyright or patent law, if you tried to do away with it you'll have protests in the streets, regardless of the societal benefits to tearing down those rent-seeking laws
" 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"
Yeah, but that person still has to feed and house their family. And in some areas there are "plenty of companies", but not in all.
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'
>Why didn't this employee share this system with the others?
Because the consequences of him doing that are unclear. And since one potential (if not likely) consequence is management would simply retain 1/4 of staff doing this work and fire the rest, why would he share that?
Was there a huge sign at his workplace outlining the consequences of automating anything? An explicit policy that would alleviate such (reasonable - read the article!) fears? I don't think so either.
What was clear, presumably, is that as long as he processed X catalogs a day, he was getting his salary paid. That was what he was hired to do. And so that was exactly what he was doing.
>Why did he think it was OK to slack off for 6 hours a day instead of doing 4 times as many catalogs?
Because this is how work works. You pay someone to do something, and the expectations on the amount and kind of work - and the amount and kind of compensation - are discussed in advance.
>If this employee worked for me, I'd be putting him to work finding other things to automate!
Yes, and that's exactly the problem.
What if there aren't any? What if there are, but he doesn't find them? What if he finds them, but doesn't know how to automate the task? He was hired to go trough books and compare specs, automating his employer's business was literally not his job.
You see, your "reward" is not paying the employee 4X salary for being 4X efficient (you left that little part out!). Your reward is making the employee perform a more difficult job that they didn't sign up to do, presumably for the same salary (since you didn't mention paying them more).
If someone with this attitude worked for me, I'd get rid of them ASAP. We don't want people sitting around saying 'thats not my job' or 'I'm not going to look for ways to do things in a better way' or 'I wasnt hired for that'
Our company culture is the complete opposite of that. We want people to help each other. We want people to challenge how things are done. We want to change things all the time, experiment, see what works.
I have NEVER hired someone and said 'heres exactly what you need to do for 8 hours, have at it'. Not even close. All businesses must move forward, lest they die in the dust. The old cushy 9-5 job where you just do the same thing over and over your whole career is dying out quickly.
>Our company culture is the complete opposite of that. We want people to help each other. We want people to challenge how things are done. We want to change things all the time, experiment, see what works.
OK, so you are explicitly making this a part of the job description. Which, arguably, was not the case for that particular employee at that particular job.
>If someone with this attitude worked for me, I'd get rid of them ASAP.
When people are "got rid of ASAP" for their attitude and not due to their performance, that's more than reason enough to keep silent about, well, everything.
Because who knows what kind of attitude the boss might have on that day, or seek from their employees.
----------------------------------
Everything below is skippable
----------------------------------
Now on the me-note: in my current job, I do my best to automate and document processes to save my and my co-workers' time. But, unlike in the case above, that's my job as a software engineer. And I know that when I make things better, I am rewarded - either with a thank-you, a bonus, or joy from improving my own work flow. I don't have to fear being reprimanded or fired for that.
In my previous job, which was a Teaching Assistantship, I went over and beyond trying to improve things (I rewrote the lab assignments that everyone hated, and turned them into something useful and enjoyable) - and got hit with a plain, literal, "it's not your job" from the administration when trying to push these changes. Initiative was unwelcome there.
The moral? I've seen both sides. If you are the manager, it's on you. You create the environment where people will be either eager to be improving things, or will be scared to try (and will keep mum if they do).
>All businesses must move forward, lest they die in the dust.
And so do the employees.
>The old cushy 9-5 job where you just do the same thing over and over your whole career is dying out quickly.
Indeed, and that's why people move on to other jobs. I think the puzzle will solve itself once you put yourself in the shoes of the person your story was about.
>We don't want people sitting around saying ... 'I wasnt hired for that'
But surely you hire people for something? I hope you don't expect your software engineers to, say, clean toilets - and vice versa. And if you do, I hope you pay your cleaning staff as much as you pay your engineers.
Which, again, was not the case in the story you posted (the person doing the automation was neither expected to do it, nor was paid at the level that people whose job it is are).
You're really hung up about this 'not in the job description' thing. If you see a small fire in the cubicle next door, I guess you'll just ignore it cause putting out fires wasn't in the job description. Neither is looking out for fires and reporting it, so just let it burn.
You won't last the probation period working with us, thank god for that. I'd hate to be in an office full of people who only does what's in their job descriptions and never anything else. We hire people who care about each other and help each other in difficult periods. That's one of the reasons our employee retention is so high.
EDIT: If I thought that cleaning a toilet was for some reason the most valuable thing I could do for the company right now, I would do it.
Any potential employee of your company will be asking "what's in it for me"? Do you pay well above market wage to make this extra effort worthwhile? If I automate or eliminate a lot of work how am I compensated for that extra effort?
Every company says they want people like you describe but few actually put the incentives in place.
Well people don't usually like or want to work for little dictators which fire people on a whim for minor things.
So your employees (assuming you have any and this is not some hypothetical scenario) won't straight out say those things, they will just quietly do them :)
Just to be clear, I've certainly never fired someone on a whim and in fact I can't even remember the last time I actually had to fire someone. Probably at least 5 years.
But we do try really hard to hire people that fit in our culture, and we make sure new employees understand how we work. If someone's just sitting there doing their assigned job as they were trained, they'd be fine but they would probably not get promoted or earn a pay raise every year.
And of course if someone DID need to go because we lost some clients or whatever, those are the ones we'd want to let go first.
This is race to the bottom behavior which we largely got away from him post industrial revolution. It's well and good to want employees who are passionate about their jobs, but no one is passionate 100% of the time. The rest of the time, they're going through the motions of pretending to be so they don't get fired. We know this leads to bad results for society in the long run. Mass burnout isn't good for anyone. Which is why we have (mostly cultural) enforced limits on what employers are "allowed" to expect from their employees (like a 9 to 5.) No one has the energy to go above and beyond 100% of the time, and honestly expecting them to do so is delusional. Of course it's beneficial for individual companies to find ways to compel their employees to work more (whether it's "culture" or otherwise,) but it's very bad for the "system" if everyone is doing it. People need to have time to spend money and engage in meaningful leisure to keep the economy spinning.
The only real exception is employees who are really committed to the vision of the company. Ultimately though that's usually only the executive team and early hires since they're the only ones who (usually) materially share in the actual success of the vision beyond just keeping their job. Most of your frontline employees are not going to get any benefit from sacrificing their energy (and there is a real cost to this) and time to fulfill a vision they don't even really contribute to forming, besides just keeping their job. The incentives just aren't usually there. Furthermore, It's common for founders to be very deluded about how "laudable" the vision for their company is. There are very few companies that act as clearly morally good agents in the world. It's not a given that profit-seeking entities inherently behave in a way that's ethical. I just don't see how anyone could possibly expect employees to be 100% committed to executing on the vision of most b2b or even consumer facing businesses. Especially when they don't really reap the benefits of company success.
And yeah, you can argue that you're buying someone's time and you're entitled to expect 100% of their mental capacity etc... during that time. But like anything else in capitalism, you get what you pay for. There are plenty of other employers that don't expect that or don't have the time/resources/collective IQ to determine that you've automated, and I don't see why your employees wouldn't just go work somewhere where they can get away with doing 1/4 of the work for the same salary vis a vis automation unless you provide some extraordinary benefit just for being a "member" of your company. And if being challenged is important to the employee in question (I'm one of these) I'd just go find a job that pays 4x (or make my own) where I could be challenged. In general, you can't eat a corporate vision and it's just not that valuable for most workers (there really are exceptions, companies that are clearly "morally good", but that's the exception and not the rule.)
Which isn't to say it's fun to work at a place where people are just jumping through their daily assigned hoops. But speaking as an employee, I'm certainly not willing to put in extra effort at a company paying at or below market rate with bland corporate vision/culture and/or uninteresting problems. Which seems to be the expectation of most employers. I'm lucky to work at a company where even though I'm ambivalent about moral character of the product (it's b2b stuff, so morally neutral,) I'm well compensated and enjoy a flexible corporate culture and have interesting technical problems to solve. Ultimately though, most companies are bland (in terms of vision) somewhere on the scale of utterly toxic to tolerable (in terms of culture) and totally boring (in terms of the nature of the w...
These days I'm much more inclined to automate my own job than someone else's. It seems many of the times I've taken extra steps to more fully automate other people's tasks, it's had the adverse effect of alerting them that even further automation is possible and they inevitably ask, "why can't you just automate the whole thing?" I then proceed to spend about 7 minutes frustrated and determined to automate their entire job away before cooling down and simply adding them to my list of "non-client people who think I should work hard so they can be lazy."
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.
We need a HOWTO for Job Automators that addresses things like:
* when to automate versus when to quit and
start a company
* who owns the code, and how to find out
* when/if/how to reveal the automation
to your employer
* etc.
One thought that keeps me awake at night is that my past automation work has cost others their jobs. I understand that that's "how the world works", but it still deeply affects me that people have lost their livelihoods because of my actions.
I understand this guilt but it doesn't belong to you. We're rapidly entering a post-scarcity economy and most of the western world are employed in service industries anyways. I think the lack of more societal guarantees to survival is a critical issue especially in the US, it'd be nice to see UBI or alternatives explored more and rolled out so that losing one of these tedium jobs isn't devastating on the former employee.
Yeah, probably. My career started in a job that could have easily been automated, but never was (intentionally). So in a lot of ways, I feel indebted to it and the idea of entry level tech jobs, because it allowed me to build a career without a degree. From that experience, it feels kind of sad that certain automation can displace potential careers.
It's possible that your automation saved jobs by enabling your former employer / client to remain solvent. Sometimes the choice is not "30 jobs without automation or 10 jobs with automation," but rather "10 jobs with automation or 0 jobs without automation."
That makes no sense. If people were doing jobs that could literally be replaced by automation, they were not great jobs and either soul destroying or they would have gone away anyway.
Progress enables productivity which is a net win for everyone, your work has contributed to productivity a LOT more than the work of the people who needed to move on. Without technology we’d almost all be in poverty.
You're making a hell of a lot of assumptions there.
In the end you're probably right for a population of people. I'm not talking about that, though - I'm talking about very specific people with families to feed.
What's disappointing is the opening story of the QA guy who automated his job and then proceeded to spend time playing video games. To each their own how to use new-found efficiency, but if this person had truly automated their job in 50 hours, I'll bet someone within the company could find him something more interesting to do, for a lot more money.
I read r/financialindependence from time and time, and it's not uncommon for me to read about people who have nothing to do at their job. From their account, they ask for more work, but nothing comes, and they spend their days redditing and watching youtube. Thus, they want to retire ASAP as they find this mind-numbing.
This is completely bewildering for me. All managers I've had were always eager to pile on more work on my desk when I was starting to look like I was finishing something, sometimes to a fault.
Is it a US thing? Have you guys experienced something like that? What is it, something like having to keep people around to justify budgets?
I am currently trying to automate my job. This will allow me to focus on more important issues.
In other words, I am automating away the job I don't want to do, to focus on the job that I want to to, and that will bring more value for the company. I don't expect the workload to ever decrease, just that our team will be able to tackle bigger issues.
I am currently building and selling software that automates fx and fixed income otc traders out of a job.... Or rather....allows them to spend more time on higher value tasks (so goes the theory!)
It's fairly addictive automation, I'm finding all sort of functions and jobs that could / should be automated to the growing frustration of my colleagues :-)
Many years ago, one of the secretaries was on holiday and the big boss asked me to write a program that, unbeknownst to me at the time, completely automated her job away. When she came back she came to me in tears, couldn't believe I had stabbed her in the back like that. Well this story has a happy ending, the boss did it so he could promote her, he just thought it would be a nice surprise! But ever since then I have been very conscious of the power we have and I try to work on new things, not merely automating away old ones. I make the exception obviously for using automation to bring work back in-house that had previously been outsourced or offshored. Those jobs are already destroyed, and automation always improves the quality and turnaround.
497 comments
[ 2.5 ms ] story [ 219 ms ] threadWe often joke about training our replacements but we're definitely in an age where it's just as easy (if not easier) to build our replacements.
This doesn't have to come in the form of AI which can ingest requirements and write code. It typically comes in the form of automating specific aspects of our current job. Build systems, pipelines, workflows, etc.
It's nice to kid ourselves and think of it as work intended to improve productivity but from a company's point of view the value is decreasing overhead and cost which comes in the form needing 1 person to do the work instead of 10.
Cross your fingers that you're the 1 and not one of the 9 :).
You've just described the purpose of the entire software industry. Did it really not occur to you that writing systems to automate tasks would displace anyone doing those tasks manually?
Engineering problems just move higher up in the stack. Few people are coding assembly code now days, and in the future few people would be writing in other low level languages.
Also, it seems like a huge way to waste your life. Find another job where they can actually use your skill set to do something meaningful.
Why is it ethical for companies to get away with paying you FAR less than the value you produce for them?
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 long as that is properly understood you can get a contract that is permissive enough to allow you to work on something else at work when nothing is burning. Even if you have to offer a reduced salary, it's worth it.
Another option is to go the work on OSS route, especially on tools you use for work. After a couple years of doing semi-fulltime OS work you'll be commanding double the salary.
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.
Once two different traders discover how to 'perfectly' trade, the game changes and as they say 'here we go again'
- currency is very different from equities - while one could argue that a central bank deciding to peg it's currency to $ is a realistic scenario, it simply doesn't make sense for equities (an equity is basically a right for present and future earnings of a company - good luck 'perfectly' predicting that !)
- as you note, there would still be speculators, since there is always uncertainty. There are numerous examples of countries pegging their currencies and then when unexpected happens...
- traders / sales would still compete for order flow of the clients (and get the cut), so there would still be a game to be played albeit for smaller margins
* actions of any given platform doesn't meaningfully influence the market
* all have ability to forecast weather with 100% accuracy
* all have ability to perfectly predict human behavior
* all acquire the exact same news at the exact same rate
* all connect to the same exchanges with the same latency
* all have the same amount of capital to leverage trades
Simply put, there are incalculable ways for a trading platform to gain advantage over another, so I don't think this will be an issue in many lifetimes.
Yes - this... Buying or selling even 1 share in the markets adds information to this giant calculating engine. Anything you do will alter the course of the future.
I've never seen a backtested strategy that didn't look great on paper. The moment you drop it into the market - you can take a steep discount to your expectations.
Doesn't make the decisions for you but manages the other 80% of the complexity involved in deploying a trading strategy.
EDIT: And I would add, for anyone that has automated their job in this way...what you should really be doing is scaling it up, and finding other companies who are probably paying employees to do the same thing. Then start your own company that does whatever this task is as a service.
Can you expand on this? I don't understand the anology
Perhaps they're saying that the employer has to (indirectly) pay for a parking lot to accommodate them?
Careful, if it gets out that you wrote the code to automate your job as a coder while actually at your job, your company most likely owns that IP.
Yes, in theory. In practice, an employee's power to negotiate wages is limited. At some point, the employee just needs to work to eat/pay rent/etc.
Now, in most areas (of the US), software developers already are paid generously. Even in lower paying secondary markets, software dev are usually paid significantly above local averages.
And, anecdotally, that pay is often for a much "easier" job, where "easier" means less stress and fewer hours than professions that generate similar salaries (engineering, accounting come to mind).
Cause they have more power than you. That's about it.
https://www.copyright.gov/circs/circ09.pdf
These tasks might not be worth selling as a service, they could be relatively trivial yet very context specific... I suspect this is the case, and that the real issue is with the employers lacking the insight to realise the these tasks _should_ have been automated and have the initiative to do so as soon as possible.
More specifically they probably neglected to employ people between the grunt worker and executive positions that would _have_ the insight to automate these tasks as soon as possible. That's basically corner cutting in terms of employees, in which case perhaps they deserve to be exploited, the funds are correctly being appropriated to the people who realised they needed to be automated.
EDIT: to be clear I don't find it 100% morally acceptable, going behind the employer like this is underhanded of course, but it can be somewhat justified as I outlined above. I suppose the alternative is to explain to the employer how it should be done and do so and hope to gain some kind of promotion or compensation, but that entirely depends on the moral standards of that company.
For those that might say that a job description sets product based terms for employment, it's rare that they are offered that way. Almost all the job descriptions that I've ever seen (and all that I've written) have some sort of phrase to the effect of, "...and other work as might be assigned." A job description isn't a Statement of Work, they're usually just general expectation setting devices.
I get the impression from these stories that the dishonest part of what the self-automaters are doing is that they could do other tasks and use automation to increase their productivity, but instead chose to keep their productivity the same and relax with the extra downtime.
Being able to have chef integration tests (or are they considered unit tests?) seems really powerful. But holy fuck does Chef have a ton of (what feels to me like) cruft
So, if you're not building systems at the Netflix or Amazon scale, then Chef might have features and tooling that you don't need -- today. But as you grow and you find you do need those tools, they will be there.
I can tell you that Chef was a key part of the system for taking the Raytheon GPS OCX system and letting us build out an entire virtual datacenter in a matter of hours instead of months. Once everything is racked and stacked and cabled together, just press the "Go" button and everything builds itself and installs itself in a fully automated way.
If you're not familiar with GPS OCX, that's the next-generation ground control systems for GPS satellites -- both the current generation of satellites that is currently aloft and the next-generation fleet that is being developed.
With regards to Ansible, there are many lessons that the Puppet and Chef communities learned years (or decades) ago that are being re-learned yet once again -- like ssh isn't a very scalable communications mechanism when you start talking about handling thousands of servers.
The concept of "just let me run my custom scripts everywhere" is a nice one, so long as you're talking about a dozen or so machines, each of which is a unique snowflake "pet". But when you want to start building a cattle farm, that method stops being so useful.
It’s funny because I would say that Chef has yet to fully re-learn what the CFEngine community knew.
This is not the recommended way to use Ansible at all. Ansible encourages the use of modules, to perform tasks on the server in an idempotent manner.
There are modules[1] for installing packages, creating, 'editing files' and so on.
Running custom shell scripts for everything is specifically discouraged in their documentation.
[1] https://docs.ansible.com/ansible/latest/modules/modules_by_c...
And it is only not fair to the peers whose work cannot be automated, and as someone here said, it's a temporary privilege to be working in programming, we're in a different world, higher pay, more learning opportunities, more leverage than other jobs. But, nothing lasts forever. We're going to be automated away eventually.
The programmer who has extra time from automating his jobs has a choice on how to spend that time.
- Waste it playing games
- Learn other skills
- Work on other side projects
Only the first option is negative to the employer.
I get the impression that the dishonest thing the employers are doing when they become aware of the automation is that they could increase the person's salary, but instead they keep it the same...
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.
I hate to burst GP's bubble, but the attitude and environment at his next job probably won't be any better in regard to "best practices." It's extremely difficult to gauge how your attitude toward development compares with a prospective team's after an hour of chatting. I became a manager last year and quickly discovered that changing others' behavior and habits is next to impossible. And if he does happen to find a new team that matches his work ethic he can be certain that 1 or 2 years down the line it won't any longer.
I think the only two ways to avoid this is to become a contractor and switch gigs every 2 years, or start your own company and hope the people you hire share your attitude.
If you're interested in progress and growth, I can say with a high degree of certainty that what you don't want to do is apply to work on a very stable team. These people are always confident that they know what they're doing - even when they agree that the outcomes aren't great. They've had lots of time to practice their rationalizations and that kind of cognitive dissonance can be pretty jarring/aggravating.
By definition, starting your own company or contracting will avoid that situation, but you don't need to take your ball and go home just to get the right kind of environment.
Fifteen years later I sit in meetings telling people (some of them still older than me) not to touch the stove because it will hurt, and I have to patiently wait until someone gets hurt before we can discuss the proverbial oven mitts.
The problem with doing something right the first time is nobody appreciates how hard it was.
Sometimes if you do put in quality and do it right in development it costs you in time and then by perception.
When you hit the ship date over finishing the iteration/version/product you have problems after ship from external customers, when you do it right and handle the problem in development before ship, you take a hit in perception internally.
The problems after ship can harm a product/company more than a slight delay in shipping, but today it seems people don't care as much as there is more specialization and larger teams where it is 'not my problem'. Some clients/project managers see a bad product shipped on time as good, and a good product shipped late as always bad. The external perception should play more into that perception not just hitting their part of the project goals/milestones.
Hitting dates is hugely important, but messing up a product with the customer can be deeply problematic. Noone truly remembers a late product after it ships and is quality, creative and functional, they remember a bad product.
I prefer the Valve Time [1] philosophy, get the product right over the date, and don't set dates until you have the product actually ready.
[1] https://developer.valvesoftware.com/wiki/Valve_Time
Does a development agency that focuses on this model exist? Of course they should be paid more per hour (or other unit) than your average, less optimized agency, but the sum total should be less than hiring inefficient agencies.
(P.S. I understand the best developers probably don't want to start or work at development agencies, but assuming there are some.)
Seems to be a good idea to separate out the architecting from the actual implementation. Makes sense, because if someone knows they'll have to be implementing, it could cloud their plan for the ideal solution. Similar to separating out design, UX, and development roles.
If you know of a development agency, odds are that it is probably a body shop.
The places that do work like this are more like Unicorns. And Unicorns are damned hard to find and hire -- or get hired by them.
This sort of thing is how I now pay the bills.
In many cases, what somebody does (and why) is not documented, or if it is the documentation is most likely out of date and inaccurate.
To effectively automate a task, you need to fully understand what needs to be done as well as have the skills to do the actual automation. Getting somebody in who is unfamiliar with the job, can work, but in most cases you will end up with an off the shelf system that has been customised to perform the original task but come with a large overhead of maintenance that may take more work than the original task.
My suggestion would be that rather than get an outsider to create the automation tools, up-skill and authorise the staff doing the work now to allow them to gradually automate the process. Make sure you make it worth their whiles to automate.
1) As person with business knowledge, vision, plan, etc, I should fully document the business goal and why we're doing it and what we're trying to achieve at the highest level, then work with the developer to figure out what should be developed to achieve that and where to automate.
2) Don't hire outside person or agency, but bring someone in full-time or as a part-time partner for the long term and incentivize them to get better and better?
I think we instead do the same amount of labor, but accomplish more.
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.
I don't hand-create machine code. I don't write assembly.
I write in the highest-level language that still lets me fully specify everything I care about, and then all of the lower levels of code generation are completely automated. Programmers have always automated programming jobs as much as possible.
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.
CS encompasses way more than automation. Graph theory, ADTs, complexity analysis (just by way of example) are all very relevant, even if the computation is done manually, by hand.
A lot of computer science presumes a very abstract computer; a human and a modern machine apply equally well.
That's assuming your employer will "move you up" and you'll make more money. Or that a future employer will see value in you automating your job. Then there's this story from TFA:
> a user posting as AcceptableLosses wrote, “They took what I had developed, replaced me with an idiot that they showed how to work it, and promptly fired me for ‘insubordination.’ I had taken a business asset that was making them $30 grand a year profit and turned it into a million dollar a year program for the company, and they fired me for it to save ~30 grand a year on my salary. Job creators my ass.”
Which sounds so entirely stupid as to be almost incredible. Why not just take this guy and move him, even sideways, to another role he can automate? But I believe him, because I've seen a lot of stupidity in Big Companies, especially the old school ones.
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.
And perhaps even then not so much: at a minimum you probably need to write unit tests.
I have to disagree. The esthetical expectations of the user/customer are higher now. If it's not "in style" they think you are sticking them with old tech. And you have the desktop/mobile split that frameworks only get half right and require days of black-box fiddling to get working right on all devices. And JavaScript gizmos often "break" as new browser versions or related components come out. It's almost as bad as the "DLL hell" that desktop applications used to face.
From a purely utility standpoint, I was much more productive back then because I only had to make it work and be easy to use, not "pretty" and animated with toys or the latest style fad.
Is that even true? Is there any survey showing that users consider those bad or old tech? Because with things like the reddit, ebay, paypal, gmail redesign, the common thing i ve noticed is that nobody asked for those.
As far as old-looking sites like Ebay, if an Ebay competitor appeared with equivalent services and product choices, yet LOOKED fancier/stylish, Ebay would start to lose customers. Lucky for Ebay, no such site exists. (If they appeared, Ebay would probably spend on a visual revamp.)
Not pretending for a second I'm safe.
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.
As a sysadmin who started out replacing power supplies as a datacenter tech, and nowadays wrangles AWS auto-scaling groups, the idea of _not_ automating away the tedious parts of my job is pretty hilarious. I had one operations/support job where this was the case, and thankfully, I quit after one month.
If anyone out there has the gumption to cobble together a dev environment and automate away their BS job, yet can't get recognition from your employer; it is time to seek out a new job, you've certainly got the skills for something better!
Operations is a pure cost center. Cost centers only exist for the express purpose of being compressed twice as much this month as they were last month, so that you can make them half as expensive.
Developers are valuable. They create value.
When all the good Operations staff has left because they're tired of being treated like mushrooms, all the Operations stuff gets thrown over the wall and then the Developers get told that they are now DevOps.
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.
https://news.ycombinator.com/item?id=14656945
In Cybernetics there is a formal measure called Variety which is something like a limit or measure of complexity of a system. Programming can be considered the art of extracting the low-variety parts of a process into automation, leaving the high-variety parts to the (high-variety) humans. This process itself is low-variety. Therefore, from first principles, programming is automatable. Our programming environments will eventually look like automatic systems that we instruct with our intentions, and then they consult us as oracles to determine the high-variety parts of the necessary process, having automatically computed the low-variety parts.
In fact, this is already happening as fast as people can accept it. The limiting factor is not in the machines (they are already superbly fast) but in the psychology of the people involved. Most of the research and much of the technology already exists and is in many cases decades old. (Cf. "The Mother of All Demos" and Prolog.)
As time goes on, given the exponential nature of the meta-process, it will feel like a step function for many of us: one day relevant and employable, then the next day replaced by a machine and unemployable, and unable to learn the next thing fast enough to beat the masses of your peers competing against you in the same boat.
I realized all this years ago, and have been asking peers and coworkers, "If you could write a program that could replace yourself, would you?" However, to date, no one has taken the question seriously.
I find this article, appearing in a non-geek publication, to very heart-warming. Maybe people are finally catching on?
Anyhow, this is why e.g. Universal Basic Income is important: You're going to need it sooner rather than later.
Unless there is some essential economic activity that humans can perform that machines can't we are all on the "discard pile" of history.
I actually think we'll just mellow out and enter a Golden Age, but again, only as fast as we can accept it. Certainly the Universe is willing for us to live in peace and harmony, it's up to us to choose to, or not.
I've done it a bunch of times, sometimes by accident.
In one case I was going to be assigned to do testing every evening. But I wanted to go home at 6 every day, so I automated the tests on my first day, then came back in the morning and started 'working on my next task'; never realizing that previously the testing job had been a full time position.
I ended up doing about 5 people's worth of work there that summer.
Of course, it's probably because the project wasn't particularly organized, and our team was explicitly given a free hand to find inefficiencies and fix them. Still, it's a nice story to tell people ;-)
Granted the value created by such tasks usually isn't fairly compensated so there are a lot of societal issues.
I learned that I was taken advantage of.
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.
Or they fire you because they don't need you anymore.
This is the kind of ridiculous thinking I'm talking about in my other comment. You just made your job into a cheap, automated process. That's the most valuable thing you could do in a company! If you did that in my company, you'd get a promotion and you'd be put to work finding other things to automate. You're the kind of person every company wants! Why would we fire you? If we're dumb enough to fire someone like you, you're better off at another company anyway.
Sadly, while there may be some logical people in a company, many companies (most?) wind up not being run in a logical manner due to a wide variety of internal politics and societal issues.
What you hope (and pray for) is that the logical people in a company are not also sociopaths, in which case you are really well and truly screwed.
What actually happens is that regular people who you would not assume are "programmers" start picking up computer skills and employ them in a piecemeal fashion a little bit at a time until eventually their day-to-day work becomes something quite different from when they started out.
This has been going on for at least as long as there has been a computer on every desk. I think "software engineers" should not be so smug to think that everything worth doing is something that they're going to get a chance bid on and then get a project managers or scrum teams to implement.
As for whether the person that does this gets fired or promoted depends on their skills at managing their peers and superiors, and what kind of environment they work in.
Obviously there is a balance - a company shouldn't get ALL that savings (although in the long run, that savings would need to be passed on to customers, since competitors will also be able to automate the same tasks).
At the same time, I don't think it is fair (or sustainable as a society), to expect to live forever off of work you did over a few weeks (no matter how valuable that work might be).
If we allow people who automate things to live off the work of that automation FOREVER, then we are creating that sort of distopia that anti-technology people claim; that WOULD be taking jobs, because ALL of the benefit for the automation would be going to the automater and none to society. Society would still be paying the same amount for the resource, it would just all be going to the person who made it.
Obviously, it shouldn't all go to a company either, but if ALL (or many) companies in the same field also automate, they will HAVE to pass on the savings to customers to compete. This will provide a net gain to society, since the resource is now cheaper for everyone (at the cost of the people who used to do the job).
The cost decreasing with automation is REQUIRED to make it a net positive for society, and the automater taking all the rewards for the automation in perpetuity ruins that.
In perhaps the simplest possible example, they live on land that belongs to a country that defends and otherwise manages it. In that case, paying a basic land tax should be enough. If there are other interactions between the family unit and its society, then other arrangements might need to come into play to allow them to maintain the entitlement for that lifestyle.
In return, he is giving the output of something he worked a few weeks on.
In your example, it would be like the son invented a machine to do HIS chores for him, but then sat around while the rest of the family still did their work
I think where this analogy breaks down and becomes gray area in modern society is when the group unit that benefits gets too large to ascertain where the gains are accruing.
We're biologically wired to optimally deal with groups of ~150 or fewer people.
Yeah, but that person still has to feed and house their family. And in some areas there are "plenty of companies", but not in all.
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'
Because the consequences of him doing that are unclear. And since one potential (if not likely) consequence is management would simply retain 1/4 of staff doing this work and fire the rest, why would he share that?
Was there a huge sign at his workplace outlining the consequences of automating anything? An explicit policy that would alleviate such (reasonable - read the article!) fears? I don't think so either.
What was clear, presumably, is that as long as he processed X catalogs a day, he was getting his salary paid. That was what he was hired to do. And so that was exactly what he was doing.
>Why did he think it was OK to slack off for 6 hours a day instead of doing 4 times as many catalogs?
Because this is how work works. You pay someone to do something, and the expectations on the amount and kind of work - and the amount and kind of compensation - are discussed in advance.
>If this employee worked for me, I'd be putting him to work finding other things to automate!
Yes, and that's exactly the problem.
What if there aren't any? What if there are, but he doesn't find them? What if he finds them, but doesn't know how to automate the task? He was hired to go trough books and compare specs, automating his employer's business was literally not his job.
You see, your "reward" is not paying the employee 4X salary for being 4X efficient (you left that little part out!). Your reward is making the employee perform a more difficult job that they didn't sign up to do, presumably for the same salary (since you didn't mention paying them more).
Do you still wonder why they kept their silence?
Our company culture is the complete opposite of that. We want people to help each other. We want people to challenge how things are done. We want to change things all the time, experiment, see what works.
I have NEVER hired someone and said 'heres exactly what you need to do for 8 hours, have at it'. Not even close. All businesses must move forward, lest they die in the dust. The old cushy 9-5 job where you just do the same thing over and over your whole career is dying out quickly.
OK, so you are explicitly making this a part of the job description. Which, arguably, was not the case for that particular employee at that particular job.
>If someone with this attitude worked for me, I'd get rid of them ASAP.
When people are "got rid of ASAP" for their attitude and not due to their performance, that's more than reason enough to keep silent about, well, everything.
Because who knows what kind of attitude the boss might have on that day, or seek from their employees.
---------------------------------- Everything below is skippable ----------------------------------
Now on the me-note: in my current job, I do my best to automate and document processes to save my and my co-workers' time. But, unlike in the case above, that's my job as a software engineer. And I know that when I make things better, I am rewarded - either with a thank-you, a bonus, or joy from improving my own work flow. I don't have to fear being reprimanded or fired for that.
In my previous job, which was a Teaching Assistantship, I went over and beyond trying to improve things (I rewrote the lab assignments that everyone hated, and turned them into something useful and enjoyable) - and got hit with a plain, literal, "it's not your job" from the administration when trying to push these changes. Initiative was unwelcome there.
The moral? I've seen both sides. If you are the manager, it's on you. You create the environment where people will be either eager to be improving things, or will be scared to try (and will keep mum if they do).
>All businesses must move forward, lest they die in the dust.
And so do the employees.
>The old cushy 9-5 job where you just do the same thing over and over your whole career is dying out quickly.
Indeed, and that's why people move on to other jobs. I think the puzzle will solve itself once you put yourself in the shoes of the person your story was about.
>We don't want people sitting around saying ... 'I wasnt hired for that'
But surely you hire people for something? I hope you don't expect your software engineers to, say, clean toilets - and vice versa. And if you do, I hope you pay your cleaning staff as much as you pay your engineers.
Which, again, was not the case in the story you posted (the person doing the automation was neither expected to do it, nor was paid at the level that people whose job it is are).
You won't last the probation period working with us, thank god for that. I'd hate to be in an office full of people who only does what's in their job descriptions and never anything else. We hire people who care about each other and help each other in difficult periods. That's one of the reasons our employee retention is so high.
EDIT: If I thought that cleaning a toilet was for some reason the most valuable thing I could do for the company right now, I would do it.
Every company says they want people like you describe but few actually put the incentives in place.
So your employees (assuming you have any and this is not some hypothetical scenario) won't straight out say those things, they will just quietly do them :)
But we do try really hard to hire people that fit in our culture, and we make sure new employees understand how we work. If someone's just sitting there doing their assigned job as they were trained, they'd be fine but they would probably not get promoted or earn a pay raise every year.
And of course if someone DID need to go because we lost some clients or whatever, those are the ones we'd want to let go first.
The only real exception is employees who are really committed to the vision of the company. Ultimately though that's usually only the executive team and early hires since they're the only ones who (usually) materially share in the actual success of the vision beyond just keeping their job. Most of your frontline employees are not going to get any benefit from sacrificing their energy (and there is a real cost to this) and time to fulfill a vision they don't even really contribute to forming, besides just keeping their job. The incentives just aren't usually there. Furthermore, It's common for founders to be very deluded about how "laudable" the vision for their company is. There are very few companies that act as clearly morally good agents in the world. It's not a given that profit-seeking entities inherently behave in a way that's ethical. I just don't see how anyone could possibly expect employees to be 100% committed to executing on the vision of most b2b or even consumer facing businesses. Especially when they don't really reap the benefits of company success.
And yeah, you can argue that you're buying someone's time and you're entitled to expect 100% of their mental capacity etc... during that time. But like anything else in capitalism, you get what you pay for. There are plenty of other employers that don't expect that or don't have the time/resources/collective IQ to determine that you've automated, and I don't see why your employees wouldn't just go work somewhere where they can get away with doing 1/4 of the work for the same salary vis a vis automation unless you provide some extraordinary benefit just for being a "member" of your company. And if being challenged is important to the employee in question (I'm one of these) I'd just go find a job that pays 4x (or make my own) where I could be challenged. In general, you can't eat a corporate vision and it's just not that valuable for most workers (there really are exceptions, companies that are clearly "morally good", but that's the exception and not the rule.)
Which isn't to say it's fun to work at a place where people are just jumping through their daily assigned hoops. But speaking as an employee, I'm certainly not willing to put in extra effort at a company paying at or below market rate with bland corporate vision/culture and/or uninteresting problems. Which seems to be the expectation of most employers. I'm lucky to work at a company where even though I'm ambivalent about moral character of the product (it's b2b stuff, so morally neutral,) I'm well compensated and enjoy a flexible corporate culture and have interesting technical problems to solve. Ultimately though, most companies are bland (in terms of vision) somewhere on the scale of utterly toxic to tolerable (in terms of culture) and totally boring (in terms of the nature of the w...
These stories seem to me like management failures — leaders haven’t built the necessary trust.
Progress enables productivity which is a net win for everyone, your work has contributed to productivity a LOT more than the work of the people who needed to move on. Without technology we’d almost all be in poverty.
In the end you're probably right for a population of people. I'm not talking about that, though - I'm talking about very specific people with families to feed.
https://en.wikipedia.org/wiki/Creative_destruction
This is completely bewildering for me. All managers I've had were always eager to pile on more work on my desk when I was starting to look like I was finishing something, sometimes to a fault.
Is it a US thing? Have you guys experienced something like that? What is it, something like having to keep people around to justify budgets?
In other words, I am automating away the job I don't want to do, to focus on the job that I want to to, and that will bring more value for the company. I don't expect the workload to ever decrease, just that our team will be able to tackle bigger issues.
It's fairly addictive automation, I'm finding all sort of functions and jobs that could / should be automated to the growing frustration of my colleagues :-)