Do I care whether Dunkin makes a nickel or $0.75 on the donut they sell me? No. Is it "unfair" for them to have 4x margins on donuts? No.
Relatively few services are sold by the hour. Most spreadsheet mining is done for the value derived, not for the human labor input.
https://www.marketplace.org/shows/marketplace/there-are-6000...
It’s not that simple at all and your comment is disingenuous.
So nothing has changed and nothing is fixed.
"the company is owned by tyrants"
Citation needed.
This typically happens at big companies, though.
As a manager, I actively encourage my employees to automate their jobs. Almost every sprint, there is at least one task on the board to automate some mundane detail of their jobs.
I'm happy to have them do it. It frees them to do more valuable work. "Pushing buttons" isn't valuable (we can't sell it). And like most good developers, they hate sitting around pushing buttons - they'd rather work on more stimulating problems.
It's win-win. My boss sees us doing more with less. The sales team gets more new features to sell. The employees have more rewarding days.
This all presupposes the employees aren't inherently lazy. But, that's been my experience - "lazy" developers aren't generally lazy, just bored.
I'm paid a lot of money to solve problems, not write code. Is code involved? Yes, of course, I'm a programmer, but my job is to solve issues. I have never been at a place where I've though, "you know if I automate this button, I don't have a job anymore." There is always WAY too much work to do that actually requires my attention.
I run my company's admittedly very small IT. If I could automate everything on my list, that list would immediately fill up with even more stuff that needs to get done.
In fact, afaik, it's kinda 'proven' loosely in psychology studies that "laziness" isn't a bad trait per se. In fact, from our ancestral laziness comes our drive to build things (systems, organizations, machines, civilization!) to do our job for us, anywhere from 'streamlining' to 'automating'.
Many great developers are self-reportedly very ambivalent between laziness and the drive to make things — alchemy notably happens when what you make today will let you be lazier tomorrow (you probably need to be at least 25 to 'feel' it though).
Of course, being a nerdy creature, you'll rinse and repeat indefinitely — there probably never will be a shortage of things to automate in your lifetime — but that's the spirit. As you said, we gotta keep ourselves busy to balance the lazy. ;-)
As a silly example, I was hiking at night recently and my headlamp had gotten a little dull because the batteries were starting to get low. Even though I had a spare set, I didn't swap them out because the old ones still had hours of power left, albeit at reduced output. The cost of a few batteries is trivial, but the thought of throwing them away while still useful bugged me more than the reduced light output. My partner thought I was crazy for this, and I don't disagree, but for whatever reason little efficiencies matter a lot to me.
Well said, this has been my experience as well and so I also encourage automation as much as possible. I guess it depends on the business and tasks to do but there's generally no shortage of work in the backlog and if work can be automated, more resources can be spent on adding tests and new features.
If the tasks are straightforward, I often find it helpful for new starters to take on some of the automation projects. It allows them to get to grips with the pipeline a bit more and gets them to ask questions to other developers to clarify things, all whilst providing immediate value.
no. If they automated a part of their job, and yet is unable to contribute new value (in the form of other tasks completed), then they will either be made redundant or their pay is lowered correspondingly. Workers are unable to reap benefits from value derived through their automation if they don't own the equity of the business they are working in.
I always try to be very conscious of anything that will create / remove future interruptions in the decisions that we make around our work but haven't yet made a point to get "automate something" in regularly.
Laziness is lack of motivation, for whatever reason. Am I working on a project that's ever going to be used? If not, do I at least feel like I'm getting something out of it?
I can enjoy working on a project I personally don't intend to use if I know someone will get value out of it, and I can enjoy working on a project that only I will ever use if I foresee getting sufficient use out of it or if I'm learning interesting stuff along the way, but if none of those things are true, it all just becomes a chore, my mind goes blank, and my productivity begins to dry up. I can power through, but I dread the work.
Empirically, for me, creating "boring" report-generation software is plenty fun if I know someone's going to read and use the reports, and that those reports will make a difference to them. I'm not "making a report" as much as I'm spending minutes of programming time to save them hours of hunt-and-peck work getting the same information manually. I like doing that, even if there's nothing to it, from a programming perspective.
Contrariwise, the worst project I was ever on was an "interesting" one which involved automating web browsers, essentially writing something like Protractor for automating website testing. It had plenty of little technical rabbit-holes to go into, plenty of stuff I could do to learn more about the technology, and I hated it because it devolved into a make-work project I knew nobody was ever going to use. The fact it was a school project, which meant there was no work-life balance and I felt obligated to work on it every spare moment, certainly didn't help.
Most software development is internal software which will never be sold. That shouldn't discourage anyone, because it means most software developers will know who's using their software by name, and possibly have friendly relationships with them.
Either way, having engineers focus on more stimulating projects has its own intrisic value for the engineers themselves. Additionally, it reduces the likelihood of burnout because whether the business needs to know how much is automated is up the manager, as long as the team is delivering the agreed tasks by the deadline, the business doesn't necessarily need to know that the team had some slack. It's these slack moments testing, refactoring, and experimenting can happen - things often downplayed by business until stuff hits the fan.
With that said, I do believe AI will replace most developers in our lifetime. Particular ones like me, that create run of the mill relational systems for SMBs. I didn't need to go to school or get a fancy CS degree to do what I do. Nothing cutting edge. AI will cut deep into development like everything else eventually.
A lot of what we do is converting business rules into code, storing that data, returning it, and performing some useful operation with it. The remainder is making the systems easy for humans to develop on (be it DevOps or clean design). That whole last part doesn't matter to AI, in fact it's really a waste of time when you remove human engineers. Even still, AI can figure out SOLID principals, cyclomatic complexity, style guidelines, and general human readability if it needed to, but why?
I don't see this happening. I don't believe AI is anywhere near sophisticated enough to tackle the majority of problems that developers are solving on a day to day basis. Even if we somehow manage to have a major breakthrough with AI, it's not going to be commercially available/viable enough for average-joe dev shop to implement it.
I'm far more worried about AI replacing lower income jobs and widening the pay gap even more than I am about tech workers losing their jobs.
>A lot of what we do is converting business rules into code, storing that data, returning it, and performing some useful operation with it.
Sure, but you still need someone to make those business rules. I don't see AI being able to interpret the direction of MBA filled meeting rooms without some sort of translation later (i.e., developers).
AI is hype right now. I have not yet been convinced of its practical application, or anyone's real desire to invest in it (other than the handful of companies who would benefit off of its implementation).
My Dad will be in his 80s in 15 years. If we look at the landscape of computers when he was my age, 30s, the big thing was still mainframe computers. The internet barely existed. Smartphones? Nope. What was the big programming language in 1990? Was it Pascal, BASIC or C++? Java wouldn't even come out for another 5 years. 15 years before that he was still loading punch cards into machines.
I guess we will just see. I won't be the surprised one though.
It is, IMO, far more likely that we'll see someone come up with a general purpose SMB system like WordPress.
I'm skeptical about the idea of coders programming themselves out of a job, and I can make that skepticism rigorous. The following slides explore structures intended to capture the core essence of computer programs writing computer programs, and these slides culminate in a theorem suggesting doubt. https://semitrivial.github.io/MeasuringIntelligence2019.pdf
AI can't replace a developer, it can only perform the tasks that developer currently does. The developer can go do something else. The possibility that AI can make humans obsolete in the next 100 years is extremely unlikely IMO. By doing the low-level tasks, AI opens the doors for humans to spend their time on more important things.
I can't begin to imagine what the next 100 years will bring.
These things start when a domain expert finds a way to get something done in their cube using macros or scripts. This tends to grow and grow the more successful it becomes. And yes, it becomes a mess at some point from a software-engineering perspective.
These domain experts would very much like to "do things right" but they lack the leverage to make it happen. They are not in a software development department, they're surrounded by bean-counters, administrative battle-axes and people who would be perfectly happy to continue doing their work "the stupid way" until retirement. It's really, really difficult to propose something new in an environment like that. It involves change, which is intrinsically opposed in many business departments. Moreover, if it does get to the point of hiring a consultant, they [the consultants] are not going to lift a finger for anything less than 10K for even the simplest of projects. There's a threshold that needs to be crossed before the right executive takes action and by that time, the project is huge, complex, risky and most importantly a completely unplanned-for and unbudgeted surprise.
The reality could be worse though. My experience is that many domain experts refuse to "do things right" from a software development perspective. Many domain experts think their code is good enough as long as the code get correct results. Unfortunately, domain experts in general are terrible coders.
I'm not a coder but I would like to automate some of the more mechanical/repetitive aspects of my work, e.g. generating reports from csv files, pulling comments from Word files into a separate document, dashboard creation of live data in Power BI etc.
https://automatetheboringstuff.com/
Chapter 12-14 look relevant to you (Excel, Word, and CSV).
The documentation may look daunting, but VBA isn't that difficult to do useful things with. You'll be mostly copying/pasting from google like most professional coders :)
You can start with a macro and turn it into VBA, which is sometimes useful.
I've been using PowerShell to automate various tasks with differing levels of complexity, and I've had a lot of success so far.
It's given me a lot of opportunities to flex my creativity on what was previously a fairly mundane Excel-centric role.
Having a supportive manager is really valuable for this stuff, though.
There are also a lot of options in Azure , but they require a little bit more of coding (They are incredible powerful nonetheless).
or values your intelligence and trust in you to create value. This usually only happens if the boss is intelligent enough to see the value in trusting an employee like that in the first place.
One of the Marxist theories of work/value is that most probably that automatization of work will also be done by your direct competitors, at pretty much the same costs, at which point both you and said direct competitors will have the same lower and lower margins for that work that has just been automated.
At which point extracting higher margins that will allow you to differentiate your company from your competitors goes back to extracting "value" from manual work (or "exploiting workers", as the marxists would put it) not yet automated.
You could say that much of today's so-called "stagflation" is caused by the powers that be (or the "capitalists") not being able to find enough manual work to extract value from (some of the economists are a little euphemistic in their language and call this phenomenon "under-employment").
and thus society is enriched because a goods/service has just been made cheaper, so more people can afford them.
The problem comes when the workers made redundant has no opportunity to retrain/reskill into something else.
There is always more to do, even if it might not be in your immediate job description. If you work at a company that rewards productivity, then you will do well. If you don't work at a company, or for a boss, who rewards productivity, regardless of automation, why would you stay?
The only thing I can think that is worse than doing an automate-able task over and over is lying fallow while a program does it for me.
This is why i am a big fan of having a large segment of the population be self-employed - they can extract the full benefits of their labour.
Then I got a job in tech.
I have been automating my roles since I started working and have never had a problem telling people about my tools.
Never seemed wrong to me to become more productive through automation. I estimate my tools replace 15 hours of work per week.
I still end up working well above 40 hours per week so these tools just keep me barely above water.
The only thing automation seems to give me is more productivity, which eventually lands something else on my plate that I need to automate and the cycle begins again.
Hold off you say, there are many things to automate, and thats true to some extent. Eventually they will exhaust too at some point.
Im not bashing you for automating anything, in fact I did the same thing as you. Most of us automated something at some point. My point is, we are automating our jobs away. It will take a while though...
and so would you argue the same for the farmer who planted fields? Did that farmer kick the ladder for the hunter-gatherer?
The new guy _should_ have a different education, and provide value in a different way. May be instead of doing automate-able jobs, he/she now works as an entertainer, paid for by the guy who did the automation (as they are richer now, and can afford to do so).
The thinking that 'automation' destroys jobs is too narrow. The pie grows bigger when work is automated.
In 50-100 years there won't be much to automate. Drone delivery will happen soon unless the drones kill a ton of people. Same with driverless trucks. Uber might go under first but someone will figure it out. Between service jobs, warehouse jobs, unskilled manufacturing jobs, and driving jobs there's going to be tens of millions of jobs lost with virtually nothing to replace them. As jobs are made simpler by machines the value added by the machine goes entirely to the machines owner. This is a net loss for society and a net loss for the economy.
100 years ago, just sending this message to everyone of you who reads this would have taken countless man hours. Think of the paper that needs to be made, the trees fell for the paper, writing each letter and delivering them to the post office. Where someone sorts them and they get distributed to the various routes they go along. Hundreds of man hours, for a message to go around the world. Thanks to technology this message is virtually free. But the technology replaced countless jobs to get us here. We, as a society, have robbed our countrymen of opportunity by allowing technologies fruits to be captured by a select few people who are no more special than any other human on earth.
1. https://arstechnica.com/information-technology/2016/05/mcdon...
My boss once confessed I was the fastest dev he had ever had bumped into. I hadn't really thought about it as "automation". It was a work from home gig, where the quicker the work was done the happier my boss was, yet at the same time I only had one task, so it was socially acceptable to not have work for weeks at a time and still get paid.
It was an MLE / SE role, so writing code was not some taboo thing. The job was taking models and putting them onto in-house hardware with limited processing power. The code had to be fast, very fast.
So I wasn't just transpiling but putting optimizations in to the output code as well. The output format was C++, and it would output a handful of classes, which I would stitch together into the design pattern of my choosing, so the job wasn't fully automated. Nor had I wrote parts that take in the whole range of the input language, but a fraction of it, because the models only used a fraction of the language. This was far from an industry standard program, but more a quick hack in Perl, because I was in a hurry and it's the fastest prototyping language I know of. It wasn't meant to be used by anyone but me, and sometimes I would have to go in and reconfigure it if new models had anything unexpected.
To me it was just speeding up my job. I thought of it as meta programming. Something that would have taken 60 hours of crunch time, became 2 hours of writing code and testing, at a leisurely pace.
Here's the thing: for the foreseeable future there will always be new work to do with this skillset. As one blogger put it, "we are in the business of eliminating jobs". And it will be a long time before we eliminate all automatable work, if we ever do. Even if you automate one job for yourself you could find something else with which to continue growing and challenging yourself. You could also kick back and continue to (truthfully) fulfill a transaction you've made with your employer: X compensation for doing Y work. Nothing wrong with that; you don't owe them more than that. You may be taking a risk, but that's your decision to make.
Tired: compensation = pay_per_job * jobs_completed
Wired: compensation = pay_per_job * log(jobs_completed)
There's often political downsides for the employee as well for automating their job. You become an existential threat to incompetent employees and/or employees doing automatable jobs. If you're TOO productive people may go hardball and attempt to crush you with their social connections. So you have political incentives to herd your productivity to something in proportion with other employees by reducing your actual hours working.
I worked at a fintech company for a few years a while back. I started in an entry level role doing daily operations stuff within their proprietary system. It was boring but I could see that most of it could be automated if enough effort was put into it. We were 4 people at that time. No way our dev team had the time to do it as they were always slaughtered with an endless list of demands from other teams and higher-ups. And no budget would ever be assigned to this. So I took it upon myself to learn how to do it through code. Six months later I had a solution up and running which automated about 80% of the daily work for the four of us. Did they fire the other three people and just leave me to do that remaining 20%? No, they took me and another one of the technically savvy people from the team and took us off the boring daily stuff entirely and put us on a DevOps style team where we managed ourselves and were told to just attach ourselves to whatever projects we want and just add value somehow. They promoted me. They also promoted the person who had been there the longest to make them the manager of a new Dallas team that was being created for us to pass off the remainder of the boring stuff do, as well as new initiatives that they weren't able to capitalize on because lack of headcount to handle the work. The fourth member of the team also migrated into different projects around the division. Basically, it freed everyone to do a bunch of stuff the business wanted to do but didn't have the budget for or did have the budget for but standard corporate bullshit got in the way of. This was like a godsend to them because they viewed it as getting 3 people just thrown in their laps for free.
Win-win for everyone.
> a DevOps style team where we managed ourselves and were told to just attach ourselves to whatever projects we want and just add value somehow
Sounds wonderful - and surprising too, since businesses typically seem afraid to trust their own teams this way.
What's striking is the autonomy given to the team, after the boring stuff got automated. This kind of higher-level decision making is exactly what cannot be automated (at least for now) - to diagnose areas that need improvement, and to plan and self-organize to implement it.
---
In my work, I've also been putting much effort into automating parts of my job, i.e., build/deployment and remote management of applications.
Far from making myself redundant, I'm trusted by the company with more (and higher) responsibilities, and more autonomy to manage my own work and its direction.
Also, with the increase in efficiency and productivity, we're able to hire more people.
Yeah, the level of autonomy I was given is pretty rare. I think it was because of two main factors. First, I had several bosses over a short period of time (lots of "structural changes" at that company during that time and it was a bit hectic) and the current boss then was in London and had other issues to deal with. Second, I don't think they knew precisely what to do with me in general but since I had built up a substantial amount of good faith/reputation in such a short amount of time and surprised everyone, I think they just decided to just let me figure out what I wanted to do since I wasn't shy about telling them what I was interested in.
It was a good situation but at a company that was very messy and all over the place. A lot of things were constant fires and battles (both internally and externally). Thankfully, I had good managers when I was there who had a lot of good sense. Otherwise, someone else probably would have just clamped down on me and dictated everything they wanted me to do with this new found time.
I know nothing about your specific cases, but many managers are smart enough to understand the statement that there are 30+ hits per page view, especially when it is demonstrated with a simple webpage example with two counters (or even a clean chart). Why did it take 9 months to explain?
A requirement for almost any management role is to be able to explain things clearly to non-specialists. I have seen many engineers writing good code but hitting a wall trying to explain a simple concept to someone who does not share their exact terminology. It is a painful, toe curling sight. Let's keep those engineers writing code, they should not be managing other humans. My 2c.
Some jobs are better not doing yet egos are allowed to dominate
The system we live in only has room for the former, and often people don't even get the higher comp for being extra productive. They have to take the new skills and leave for a different job. Nobody gets to (openly) work less.
I think I really don't trust the author of Rich dad poor dad but the one thing he got right is the ESBI system ("cashflow quadrants"). — I'll let you google but the gist of it is simple: there are only two limited resources, money and time, and any work is a trade of one for the other. You want to be in a position wherein you generate 'enough' money to 'buy back time' essentially. That means being either a business owner (B quadrant) and/or an investor (I quadrant).
Freelancing is the "S" (specialist) quadrant, you don't want to be there forever — because revenue only comes from putting in hours, it's a neverending grinding wheel, however profitable it seems. What you want is to setup your 'freelancing' as a 'specialist' to grow into hiring people and thus become a business.
Never forget that more than 80% of GDP in rich countries is made by small businesses. Groups of 2, 5, 10, 20 people make up the effective wealth of our economies.
Deep down that's what The Millionaire Fastlane or The 4-Hour Week expose to the general public, this idea of relative independence combined with a business model that cumulatively earns you ever more time — and hiring is key to unlocking that, multiplying manhours around your activity, sharing the load, not being "required" yourself for the business to run. A group of well-organized devs could probably wrap 30-hours weeks and still make a ton of money.
In most of these cases, rest of team was none too happy. Upstream teams would need to speed up to keep me busy, and downstream teams need to speed up to stop new work from queueing up. Best policy was to just keep speed up on the down-low and selectively deliver faster only when politically advantageous - e.g. under the gun by management.
I got myself in a bit of trouble by attempting to produce an automatically generated "meeting cost" report to dissuade people from having meetings.
The script pulled salary data for attendees of each meeting (pulled from Outlook calendar), length of meeting and even used the Bing maps API to capture travel costs for each attendee.
When I mentioned it to my manager, he promptly killed it. Although he is very much anti-meeting, he pointed out that it could easily be targeted by a Freedom of Information request and used as a political weapon.
I agree with the article that automating your job is completely ethical. What's unethical is wasting people's time keeping them at work after they have delivered the value they 're hired for.
But done right, "programming yourself out of a job" is a significant job advantage, not a disaster that the article paints it to be. Many managers highly appreciate smart engineers who can do a good job on heir assignments (if yours does not, find another one even if your job is not machine-ready). And delivering a reliable, automated solution for your own task is one of the strongest indicators that you are one of those engineers.
One way to do it is, once your solution is ready, to have a one-on-one with your manager and tell him that you can build a fully automated solution in, say, two months while keeping your current load. Would he be interested? If so, what would be his plan for you after you complete your task? You are interested in X / career path to Y / etc. Use free time to start ramping up on new role. One benefit of this "soft transition" is to have a fallback if you feel the new project is not the right fit / not welcoming you. You can always go back and say that automation is not ready yet and ask for a new project / another couple of months. My 2c.
On the other hand in current working context that feeling arises as an error (like non-adaptive-anymore feature of organism, not yet cancelled by evolutionary processes).
Therein lies the fundamental difference. If a dev automates, they are doing what they are being paid to do, if a non-dev automates, they are no longer doing what they are being paid to do (in the eyes of the company of course, we can have a whole different argument about whether they are being paid for effort-input or value-output).
You could also try hoarding knowledge in an effort to maintain your value but this strategy also has a limited shelf-life.
I'd politely suggest you don't focus on solely optimizing the status quo until you're near the end of your career and ready to ride it out. Otherwise you will be in trouble down the road.
Oh well. Some day I'll be tasked with making an api, write out a gql schema from a requirements doc, then deploy the thing in some rogue amount of time, only known to me, and anyone else who reads my confluence docs.
"I'm writing Cobol Printer Drivers. Its the last programming job in the world, because they've got machines to write everything else".
A person walked in the door with a box, and set it on my desk.
"What's that?"
"Its a device to write Cobol Printer Drivers."
I got up, walked to the door and opened it. Outside was nothing -just a grey fog.
Then I woke up sweating.
However, the game changer will be when automation starts to replace legions of lawyers, insurance Professionals, underwriters, traders, Capital Partners, Accountants, etc. To the point the judges and doctors would be relying completely on automation to simply operate/serve as human checkpoint.