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.
This is absolutely the right way to do things. My time, and my developer's time is far too important to handle mundane tasks, and if we're manually doing those tasks, that just another thing I need to double check to make sure I did correctly, and that seriously wears on me.
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.
Agreed! There's always more work to do, no matter how much you automate.
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.
> This all presupposes the employees aren't inherently lazy. But, that's been my experience - "lazy" developers aren't generally lazy, just bored.
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. ;-)
I hadn't thought of the evolutionary benefits before but this makes a lot of sense. Related to this, I have noticed that I really like efficiency for sake of efficiency, which is probably a trait many other tech people share.
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.
Oh dear rurp, you don't want to get me started on that! ;-)
Your hiking example is a textbook page of my life, I do things like that all the time. Partner openly jokes that I'm crazy / weird / funny — all in good spirits, I concur that it's not exactly statistically average (i.e. 'normal') behavior. — "but why do you do this like that?", eyes usually roll before I even finish my elevator pitch; but every once in a while I catch her imitating. Good times, haha. Small victories, you know.
That being said,
I have a gazillion justifications for this. From ancient Zen and Stoicism (you guessed it) to modern scientific organization of work / tasks / labor, passing by cognitive science and physics and what-have-you.
It's. Just. More. Efficient. To. Be. Efficient!..
¯\_(ツ)_/¯
But it's also a delusion, to some degree (when you mistake the means for the ends I suppose, when it becomes a zero-sum rat race from a 3rd person perspective). Hence a healthy distance with the concept, I treat it as one parameter/rule of our universe — nature favors the efficient ones — but I've learned to just shrug at the general inefficiency of my civilization. Sometimes, I admit I'll even take pleasure and find beauty in a wildly inefficient thing that nonetheless passes the threshold of "it works", however barely. Politics, states, institutions feel like that to me: it should all collapse under its own weight and complexity, and yet it goes on... fascinating feat. It's like e.g. Windows (the biggest codebase in existence, at least as reported a few years ago, 50 million lines iirc?), you have to revel at the wonder that it even works.
My wife does pretty much everything in a way that simply blows my mind. Probably once a day, I start to mutter "But, why....?" Most of the time she just looks at me like I'm the broken one, meanwhile I swear it's her!
Packing for a trip is the worst. For me, it's hours of over-analysis and optimization. Packing everything into a minimal volume. Ensuring nothing unneeded makes it way into a bag. For her, it's grab an armful of {whatever}, toss it in a suitcase, and assume it'll all work out. And yet, we both love traveling and we're equally as likely to forget something.
Making more money is what ultimately allows me to be lazy, so I just need to find a way to make enough money so I would have no more obligation to work.
> "lazy" developers aren't generally lazy, just bored
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.
The premise of this essay is that workers should benefit from automation, not owners/stockholders. In your case, workers do benefit in some way, like less boredom, but do they work 15 hours a week instead of 50?
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.
Unless they of course keep it to themselves. If employer hired you for data entry and nothing else. And there is no other work for that employer, is it fair that you automate the job and not get rewarded for it somehow? The only way to make things just might be keeping it from your employer. If the employer was intelligent they would have realized they could automate it in the first place and this type of employer likely will not reward the employee, but instead just get rid of him/her.
That's a solid approach. I may try it with my teams too.
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.
I've found it's far easier to build this into sprints/backlogs/whatever than rely on the team to automate on their own. Benefits include: better understanding of the problem, testing (is the automation robust, etc), and making time for formal sharing with other teams. Also, some developers want to automate, but might not feel enabled - they want to stick to the rules (sprint plan, etc).
I applaud your willingness to manage up as well as down. I can't tell you how rare it is for a middle manager to trust the engineers in their charge to make these types of decision. At most places, where bastardized "Agile" has taken root, if any change can't be directly tied to a feature then it's not happening.
I've been really fortunate to work with reasonable product managers. At worst, I've sold automation as an IOU - let me do this 1 thing now, and you get 2 things next release. But, even that's the exception.
> This all presupposes the employees aren't inherently lazy. But, that's been my experience - "lazy" developers aren't generally lazy, just bored.
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.
If you're in a startup with shares, I guess it indirectly does.
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.
Not directly. It's a large, PE owned company, so no profit-sharing or stock grants. But, over time, via access to more interesting projects, quicker promotions, and more visibility with senior management, in theory, yes.
In my personal experience this generally isn't an issue. If you have the necessary skills to automate your own job, chances are your employer has other work they want you to do.
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.
Great story of how automating one's own job led to more meaningful productivity, rather than being made redundant.
> 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.
Glad to hear things are working well for you as well. Any halfway intelligent manager wouldn't be stupid enough to just toss you or anyone like you. They see value/skills that can be put to use elsewhere. Anyone with a growth mindset would use that human capital productively. I think only in a very stagnant, established business with no growth opportunities would they let someone go after automating a lot of things. Because they wouldn't be able to put you to use so the only way to capitalize on your improvement would be to gain your compensation back.
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 worked a job productionizing models. It was a startup and the company wanted the work done quicker every time. I didn't really know how to say no, so I automated the task of converting from one programming language to another. It had a side effect of reducing the amount of bugs I'd put into code.
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.
I didn't think my comment would blow up as much as it did or I would have given more information:
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.
I agree with this and think it touches on a more fundamental issue with our industry; in general, developers are not viewed as professionals by their employers or eve themselves. I think many of the negative aspects of the profession can be mitigated if developers would just take a different perspective on their work like viewing themselves more as plumbers, electricians, doctors or lawyers and less as clerks.
But it's related to your job, and if your contract specifies that anything you write that is related to your job belongs to your employer, they own the automation script.
Sorry I did not make it clear. What I meant the automation tool is something like Autohotkey. Let's say I made a private software XAuto (like Autohotkey) many many years ago with tons of efforts, and then I wrote a XAuto script (like an Autohotkey script) to automate my work. Do I have to give both of the XAuto script and the XAuto software to my employer?
That would depend on contract, but, assuming you have a decently sane contract, you'd have to hand over the script, but not the software itself. However, it now sounds like you've landed your first paying customer for a license for your software.
How automated though? I have an automated script that is really easy for me to run, but I'm not sure others would easily pick up the pieces if I was fired out of the blue...its automated but not simple.
I was in a similar position in my first job. We got an extremely detailed functional description of what the software was supposed to do. It was so detailed, I had a couple of scripts and macros that created most of the code for me. I was always the first to be done with my work. I wouldn't have minded sharing those macros, in fact. Those macros were specific to that particular project, though.
I was eventually fired from that job (I suspect my boss didn't like seeing me lean back and watch my scripts and macros run), and this never came up. I think the real value here is the skill and desire to automate these things, not the automation scripts themselves.
I worked at a ski resort and used an automation script to reduce my night audit role down to an hour of work per night. I used the remaining 7+ hours to learn how to code.
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.
Fair point. But let’s think again. When you automated the audit role you took advantage of the remaining time so you could learn programming. You had an opportunity and seized it. Now a new guy like you won’t have the oportunity because you did it first. You inadvertently kicked the ladder. Before long all the low hanging fruits will be collected and newcomers will have a hard time getting an opportunity because things are already automated, no need for a new guy.
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...
> You inadvertently kicked the ladder....no need for a new guy.
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.
While the answer is difficult to ascertain, anthropological comparisons between farmers and hunter-gatherers suggests that the answer is rather close to 0.
Fun fact: hunter-gatherer lifestyles require far less work to maintain self-sufficiency than agricultural lifestyles. In fact, it wasn't until around 1900 or so that agricultural societies caught up to hunter-gatherer societies in metrics such as life expectancy and general health welfare.
What happens when hunter-gatherers and farmers come into conflict over land, which the latter utilize far more efficiently (in a calories / sq km sense)?
Note that as population densities rise, land becomes a bottleneck for a population more than number of available hours.
The farmer replaced the hunter gatherer but not with a robot, the work was still done by humans, and in fact they continued to hunt.
The industrial revolution too, automated parts of labor but didn’t take the human out of the equation.
This is a different situation though, it’s not equatable in the same sense. The problem with this type of automation is that the early bird will inadvertently kick the ladder; hopefully won’t turn into a feudal like society where the lower class entertains because this, as it may sound decent, is in fact a power imbalance that could easily turn into abuse. History shows us time and time again power patterns. And we should not be only hopeful it will not turn into that, we should actively make sure it won’t. In my honest opinion.
> The farmer replaced the hunter gatherer but not with a robot, the work was still done by humans,
Critically, the work was done by fewer humans (per unit of caloric energy). This allowed other people to specialize in other ways that provided value to the farmers.
Would it hurt the really good craftsmen who prefer to do it manually for higher quality? I wish I could get a pair of shoes that are custom made for my feet by a shoemaker. I’d pay more since they are better quality, last longer and are serviceable, the soles and the heels are still replaceable and there are still, luckily, shoe repair shops around. The thing is that it’s almost unheard of, at least here in NYC of a shoemaker like that nowadays. Automation killed them long time ago. Along with that we did lose some quality with it.
Whoever specializes to automate doesn’t care about the craft or quality as much as quantity. We’re in a better place now, luckily nobody goes barefoot these days, but I wish there was a solution where craftsmen could continue doing their art and craft the way they are used to without being pushed out by automation. I wonder if a compromise could be reached to meet that halfway such that automation becomes merely a tool in the hands of craftsmen, a solution where man is still at the center of his game and uses tools to enhance their game.
But the general consensus is that everything will be eventually automated away and the only things left for people to do is entertain eachother or something to this tendency.
It does grow bigger, assuming that the education level of workers is increasing. This is one of the founding tenets of Scandinavian social democracy. Eventually society will expect every citizen to go to at least college. This becomes more or less tenable with tuition-free higher education.
> Eventually society will expect every citizen to go to at least college
This is not a personal dig, but you clearly did not brush with the real world. There are a lot of smart people out there that through no fault of their own couldn't go to collage, but there are others that would not get far anywhere...
That's just how the cruel distribution mistress works.
I'm not sure this is entirely true. While I agree that we might be automating our work away, it's not zero-sum. New technologies and industries will develop creating new spaces to automate. There are tons of things that computer scientists in the 70s couldn't even dream of. I'm sure there will be things we couldn't even imagine in 50 years. I'm not saying the rates of growth and decay are the same, but it's definitely not just all decay.
We're already seeing the consequences and have been for decades. Crappy service jobs have sprung up to fill the avoid. Even those are being automated. McDonald's has claimed a $15[1] minimum wage will force them to roll out robots to replace the expensive cashiers. These robots are already being rolled out, the $15 minimum wage would only move their timeline. There's not much time before a lot of mundane service jobs get priced out of existence by crud terminals with a cash slot and chip reader. Grocery stores, gas stations, liquor stores, hotel front desks, and fast food will be the first. My guess is substantial disruption (>50% decrease in hours worked) within the next ten year's for these fields. Then I see bars and restaurants in major metros following. A table clearing, dish washing, order taking and delivering robot could be today with off the shelf parts and some talented computer vision engineers backed by a fleet of underpaid contracted out data labelers. Up front probably cost in the low tens of billion and 3-10 years to get a production ready prototype. Roll out over 3-10 years before mass adoption. Conveyor belt style restaurants and bars could pop up far sooner and completely undercut the incumbents with an Amazon model of burning cash until the competition is gone.
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.
The backlash from all that unemployment is going to crash the system at some point. The gilded, automated future is DOA. Even now, $15/hr is starvation wages, even outside of HCOL areas.
> 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.
I think this really highlights one of downsides of being an employee. If you were the founder of company and you found a way to automate a job, all that economic benefit would go directly to you. If you are an employee, your employer gets all of it.
There is this clear split in companies between people who benefit from more efficiency and people who are viewed as pure cost factor to ideally being eliminated. That’s why I am telling young people to look for jobs in companies where top management understands and values your job.
> look for jobs in companies where top management understands and values your job.
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.
Or if you somehow manage to keep some of the benefits. Could be higher compensation associated with a shift in role, equity and / or reduced working hours / days, depending on what you're looking for.
> , all that economic benefit would go directly to you.
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").
They don't discuss the flip side of this, which is the hell of an organisation groaning under the weight of thousands of unsupportable Excel VBA scripts and Access databases (oh, and now UIPath jobs!) whose authors have left the business, and which could fail at any moment when an upstream dependency just goes away...
I agree, but at the same time, people who cry out against flimsy VBA scripts and Power-BI disasters pretend to ignore how f-ing hard it is to get a properly executed business automation project off the ground.
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.
> These domain experts would very much like to "do things right" but they lack the leverage to make it happen.
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.
They may not know how to do it right, nor have the means to get a software development team started on the project. To some extent, "if it works, don't fix it" applies here... until it doesn't work.
I don't blame domain experts for scratching their itch and solving problems in whatever way they see fit using their own knowledge and tools. It's the way that many software projects get started, and where new opportunities get discovered. These are good things.
I had one job which could at best be described as 'Excel VBA DevOps' it was in a bank. Someone had cost the company millions when yahoo finance changed the end point for currency conversion and no one noticed it was using stale data for a few months.
The buisness model is often to buy a good or service and then sell it for a higher price. Customers might pay for human hours, or explicitly want the work to be manual. Then it would be wrong to charge 10 hours for something that only took 1 hour. And the market/demand might not be big enough for 10x output.
Mondragón id also not free from problems pinned on the neoliberal school of management, such as bankruptcies that shut down whole factories leaving workers out to dry.
While OP's comment points out the fact that in a liberal economy you are free to start any business as you see fit, your comment simply is intentionally absurd and pointless. You are in fact free to launch your own company or cooperative. That's an undisputable fact. If your labor is so critical and all managers are useless tyrants then why are you choosing to give away your means of production to useless tyrants? By your logic wouldn't it be obvious that starting your own company is the solution to all of your problems?
Companies usually require a lot of capital to get off the ground, I think that's the subtext there but I could be wrong. Being able to operate at a loss for an indeterminate amount of time and equipment being two costs that come to mind.
The "lot of capital" is a function of the sector and the business model chosen by the enterpreneur, not mandatory or unavoidable. In ventures where labour cost is the dominant expenditure then cooperatives enjoy a competitive advantage as losses can be shared by all members in the form of pay cuts.
Well that's what one of the previous comments that led us here stated no?
That it's not always a matter of 'just start your own company if you don't like the way it's going'
I started my first business when I was 8. It cost nothing to start it. There are tons of companies you can start for nothing or next to nothing. There are books filled with ideas on such you can get from Amazon.
`There are tons of companies you can start for nothing or next to nothing.`
And there are tons you can't start like that and it depends on where you live as well. Who's to say said employees are in a sector where it is that easy?
And if it is one of those one could start without much but i would want to start a business that can't ruin my life if it goes bankrupt due to something weird or unforseen happening. Well I legally have to put up a large amount of cash at the start.
And then there's bs like noncompete agreements in employment contracts which i've faced a few times and which I notably looked at in depth once because yeah... I could totally do what that employer was doing way better. But hey I still can't go to it's customers today.
How much of your upbringing was atypical? How much of it was due to familial influence? Or a unique environment? It's interesting how people tend to be blind to their own privilege.
There's this pervasive idea that those who are entrepreneurs are better than the rest and therefore justifies their wealth and status. There's this other equally pervasive idea that we're all exactly equal and therefore "if I did it, you could have as well".
I did it on the sly because my parents didn't want me doing it. They were pretty angry with me when they inevitably found out.
What I did was order greeting cards through the mail and sell them door to door.
A couple years later, my family moved to Germany, and lived on a US base. I discovered that German candy wasn't available in the US, and vice versa. So I contacted my best friend in the US, and we'd ship each other the missing candy and sell it to the other kids at school. If I'd been less of a dimwit, I could have made quite a bit more money at this than I did.
> There's this pervasive idea that those who are entrepreneurs are better than the rest and therefore justifies their wealth and status.
It has nothing to about being better. It is about entrepreneurs are willing to take the risk and make the effort, and that justifies their returns.
If you're not willing to take the risk and make the effort, that's your choice, not your lot (at least in America).
It may have cost you nothing but someone was feeding, clothing and sheltering you. I'd like to start a business but I don't have the capital to cover feeding, clothing and sheltering costs in the meantime. Instead I work 4 - 6 hours in the evening trying to build something.
Want to run that past HMRC or try working for any public body, Oh apart form "self employed" barristers, funny they seem excluded unlike us greasy engineers and boffins
With IR35 its much more favourable tax treatment on 2x to 3x FTE pay
>You are in fact free to launch your own company or cooperative. That's an undisputable fact.
It is a fact, but it's not the only relevant fact; a capability theory of rights, or a positive (rather than negative) conception of freedom invalidates your point. A freedom is practically useless (to the individual) unless you can actually take advantage of it.
I think that's just half of it. Founders and CEOs get a lot of shit, but they're paid well for a good reason: they manage to sell and profit.
Take a successful factory, remove the officers and management, leave it to the assembly line workers - it's a good bet they will fail even if they have some cash to keep it going for a year.
And look at all the startups with insane $$ invested that failed.
The combined wealth of workers is usually more than enough to start a company. The only reason it doesn't happen is that the workers don't want to risk their hard earned cash.
The risk most fear is losing the ability to provide for yourself and family, for most people that is only one or two significant financial mistakes away.
I know of, and buy from, multiple employee owned (flour) companies. Don't know how it is to work for one, though. It's an interesting question why they aren't more common.
One business you can start that will cost you nothing is write a book about how people cannot start businesses in America, and sell it on Amazon. There are a lot of books for sale on Amazon complaining about America; somebody is making bank off of them.
Or any number of other companies, like writing a book and selling it on Amazon. Or starting a lawnmowing service. Or a maid service. Or a realtor. Etc.
The garage door spring on my house broke one day. I googled for garage spring repair, called the local company that did it. Turned out it was just a guy with a bunch of springs in his trunk. He had it fixed quickly, charged me, and drove off. Evidently that was a nice business he had. A car, some springs, and an advertisement.
This only works for a subset of workers, not all of them, which I think is what GP was getting at. It's a matter of justice in society, not a subset of society (mind you, a subset that can afford to do this in the first place) just trying to better things for themselves.
all of us employees with startup equity know that it's a far cry from employee ownership, and it's disingenuous to suggest that we have any quantum of control when push comes to shove.
In democratic society, on principle, how much your say is worth is not determined by how much money you are able to invest in it. Your analogy would only make sense if you can "buy" votes, and arguably the political sphere is in a pretty sad state too with how much control voters actually have. At best, you're saying that a company can be just as undemocratic as the modern state. That's not a high bar to cross.
I’ve been in IT since the early nineties, and I see this as symptomatic of a more basic issue; putting non-IT managers in charge of IT. This used to be chronic. I’d be in board meetings trying to explain to the entire company brain trust the difference between a hit, and a page view. When they realized - after about nine months - that there were over 30 hits per page view, their entire business model went out the window. There are other fun, and unaware stories out of that job, but I’ll leave it there.
On the flip side, the problem might not be with the non-IT manager.
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.
You are making some good points but from my experience there is also a reluctance for non tech people to learn anything tech related. It gets brushed off the same way learning a language or math gets brushed off by people. They claim from the start that it’s too hard and not even worth trying. And that behavior is socially acceptable. You can come up with a lot of easy to understand analogies but often you will regret that because often then the analogies get stretched to a point where they don’t make sense.
Some non-tech people are reluctant to learn anything tech-related. They wear it as a badge: "I'm non-technical." That's only socially acceptable in some circles. In others, maybe you're expected to lack the education or skill to implement or debug, but at least learn the lingo well enough to faithfully communicate between one technical person and the next.
That is a good point. In a perfect world, managers managing technology would make an effort learning it. But it is always better to assume that they did not (assume they focus on potentially harder skills needed to manage humans and teams). Instead of lamenting this imperfection, it is better for an engineer to learn how to talk effectively to non-specialists who are friendly, smart, but clueless in the topic you want to explain. This effort will pay off in spades.
I know it pays off but you can’t put all responsibility on engineers. Management should also accept that they have a responsibility to learn what they are dealing with. Even worse, it’s perfectly acceptable to brush off technical information as “nerdy”.
In my company a lot of big projects are set up for failure from the start because the big guys often listen to slick salesmen (preferably from the outside because they don’t trust their own people) and not to the people who raise concerns that are valid but hard to understand. Some things can’t be dumbed down but they are just complex.
In my view a lot of dysfunction in tech projects comes from the fact the higher ups don’t want to understand what’s going on and also don’t want to listen.
At my place of work "engineer yourself out of a job" is a mantra. The end goal isn't to actually lose our jobs. The goal is to raise our individual productivity by changing the nature of our job until, over time, its a new job.
Agreed! Once we automate one task, we move onto the next. Some of the automation requires tending over time, but order of magnitude less than the manual intervention than before.
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.
except human cognitive ability eventually declines. If you cannot extract surplus value out of your job to pay for your eventual retirement, then there's no end to this cycle.
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.
Not everyone is good at being self employed. I've done it, and I'm putting more money away now that I'm part of a corporation. Someone else may be capturing some of the value of my labor, but the part I capture is bigger in absolute terms than I am likely to accomplish on my own.
i think you mis-interpret 'surplus value' when you refer to 'more money' from the corporate employer. When I say surplus value, i really mean equity. Equity in the asset you create when doing work. With the exception of equity payments like shares (which, a lot of tech companies do), most workers do not receive any equity for the work that generates equity value.
By making sure equity is generating returns for you, that is how one prevents oneself from being automated out of a job - a job's value is an equity that is fully captured by the employer, esp. if it's a long term asset like code. You only capture this equity if you work for yourself. It is risky - failure means certain death (or realistically, just go back to being a worker, and you lose your chance to get out of the rat race).
May be a paradigm shift in society can occur to change this situation, but as i can see it, the only way one can be sure of having a retirement is to ensure one has equity that can generate the funds needed. And the only way to do that is to either work for an employer who will give that equity to you (which a lot of tech companies do), or work for yourself.
The average return is zero though. Risk free interest rates are about 2% and inflation is 2%, and very importantly, your actual return can be below zero as well as above it.
Saying owners have it better off than workers seems essentially the same as saying it's easy to beat the market (capital markets in general) consistently. A lot of people scoff at that regularly, including on HN.
I'm not misinterpreting. I am able to buy more equity in other companies using the cash from my salary than I ever earned directly through equity sharing.
That's because the business that is giving you some equity as compensation is underpaying you, and instead choose to pay with a cheaper alternative (cash).
The fact that the business is able to pay you such high cash rates means that the business is very profitable. I'd argue that the business is extracting some 90-95% of all the value you create, and leaving you a tiny bit (which is still high, and therefore, you get a good salary). But look at the people who owns the assets you create as part of your job - their networth is growing tremendously - much more than yours is through enumeration. This is only true because you are underpaid relative to the value derived from your work.
I don't think the programmer is in the wrong for not disclosing the automation. I also don't think the company is in the wrong for firing them over that.
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.
When company fires such an employee who is innovating and cutting costs, it's like killing golden goose. I am not sure why any employer would think of loosing such valuable asset when in fact they can get more automation done from him.
True, if they can convince him or her of that then that could be a third option. On the other hand, the employee did display a willingness to be deceptive. Again, it's all up to the parties involved.
When companies find out their employees have automated their jobs but are at the end of their useful output they don't even blink before kicking them out on their ass but saving their sweet-ass automation. Honestly why is it the employees duty to give their employer information which would have been to wholly the employer's benefit and none of his own when the employee is the less powerful party here? Employer basically had no choice but to fire him even if he was worth keeping in isolation just because they can't normalize getting gamed by their employees.
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.
Which online courses and books would you recommend to build competence in automation within the MS Office ecosystem?
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.
I haven't read it in detail, and I don't know how difficult it is, but there's a free book on how to (among other things) automate Office applications with Python:
I have read it, and it has become my most recommended book for someone trying to get into programming or technology in general. It won't tell you how to do every single thign in the universe, but it can give a great starting point for automation and programming in general.
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 would highly recommend learning PowerShell. It can handle all of those usage cases, and if you're using Windows, is almost certainly already installed on your system.
I've been using PowerShell to automate various tasks with differing levels of complexity, and I've had a lot of success so far.
I think that a good python library with some UI elements would be the best choice. The issue is that with any other UI tool (MS Access, Power BI, Alteryx, etc.) you eventually end up with edge cases or business requests that you can't fulfill. Me and my team are writing our own python library for automation, etl, scheduling and such and so far we have been successful in converting 1 alteryx user to our approach. It's not much but I think it's the right way to go about automation and data analytics.
I do most of my of work in this realm, using Python. I pull data from multiple databases each day with selenium and bs4, clean and transform using Pandas then generate pretty nice reports with ReportLab.
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.
If you're not a coder, I highly recommend Flow (https://flow.microsoft.com/en-us/) Which is an automation platform designed to be used with MS office products.
There are also a lot of options in Azure , but they require a little bit more of coding (They are incredible powerful nonetheless).
It's a shame there's no room for people who want to work less. Some people see that they can do a job faster and think of the higher productivity they now have space for. They expect higher compensation for their new ability to do more work in the same hours. Other people see that they can do a job faster and think of the extra free time they now have space for. They expect the same compensation and the same amount of tasks, but fewer butt in chair hours.
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 you need to become more independent from the 'system' you describe; i.e. go freelance / contractor / consultant / remote etc., some variation of these.
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.
On some occasions I've found ways to significantly automate large parts of my coding job - usually with DSLs plus code generation, an interpreter, or eval() ( evil() ? )
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 am surprised by the amount of people smart enough and capable enough to understand how to automate chunks of their work but not understand this right here. dl automation is sometimes worth more.
Lots of programmers don't want to automate their jobs because they have to be present at work, and their work pays too damn well to quit. There 's also the possibility of building an automatic SaaS or other kind of service and be financially independent, which they might be missing out (or opting out of, considering that it doesn't pay as well, especially in the current year).
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.
First, as humans, we should not really be doing many jobs that the machines do well (cleanly, cheaply and reliably). That is not always how the world works. Technology adoption lags and there is a big gray area in the definition of "well" or "well enough" that means humans get to do a lot of machine-ready jobs for a while. But "knowledge workers" especially should not expect to be doing "machine ready" jobs forever and be paid a lot of money for it.
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.
Amazing amount of cognitive dissonance in these comments. Simultaneously happy to pat oneself on the back for automating some task yet thinking same can’t happen to you because ... ?
Don’t spear & shield yourself.
When most engineers automate repetitive work flow, they seek praise and then find other useful things to do. I think automating, then being lazy, is an exception rather than rule for most.
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?
> With that said, I do believe AI will replace most developers in our lifetime.
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).
I just find it interesting that the audience of this site, can't fathom engineers being replaced by AI. Not even in the next 50 years? That would put me in my 80s.
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.
I think you vastly under estimate the process. We cannot even get a state of the art AI to recognize large stationary objects on a highway, so how are they supposed understand customer requests? If, and that is a big if, we ever get to a Strong AI scenario I'd be worried, but not until then.
It is, IMO, far more likely that we'll see someone come up with a general purpose SMB system like WordPress.
>With that said, I do believe AI will replace most developers in our lifetime
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
It boils down to the fact that if we create a Strong AI that can improve itself, the first AI is as intelligent as it can get. Only thing holding it back is available processing power. We will know if we've created a Strong AI, even if it's dumb.
> I do believe AI will replace most developers in our lifetime
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.
It was roughly 70 years from the demonstration of the first working transistor until a sufficiently large collection of transistors could pilot a commercially-reasonable car on public streets.
I can't begin to imagine what the next 100 years will bring.
The "feeling of doing something wrong" - as mentioned in the article - when automating your tasks is somehow relevant but not in current context of alienated work. For natural working context (e.g. a team) it's normal to look for something else to do once you finished your tasks or got rid of them completely by automation. It is because the natural flow of profits considers you as as beneficient. Dooing good for your team, company, etc. = doing good for yourself.
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).
Created a system that took report requests from a mainframe and ran then on a PC version of the system (saving the company more than double my salary every year). When the IT application support was outsourced (big 3 letter mainframe and PC computer company). The contracted cost per year to support the system that I wrote and up till then was still maintaining was 5 times my annual salary - companies have their own weird logic.
I wish it was even 10% true. There's still so many mundane tasks in software engineering that I need to waste time on doing manually... I regularly waste significant amount of time on setting up deployments, configuring logging, monitoring and alerting, organizing data for tests, and a myriad of other mundane non-creative tasks that take time from real fun job - like designing and implementing new algorithms, functionality, features, etc. Most of these not only not automated to a significant degree - they are small and varied enough that automating them wouldn't probably even be possible without spending inordinate amount of time. Those rare happy circumstances where it is scriptable, it gets scripted and it's a huge help, but never in my multi-decade career as software developer I ever wondered if what I do can be done by a script. I'd be happy if even 1% of it could be - I'd have 1% more time for the fun stuff - but we not even there yet.
This seems to be mostly non-tech jobs being automated. The expected result of hiring these people is whatever menial work they were doing (not trying to be insulting, menial work is where automation thrives). Tech jobs, are already about automation (to a degree) and that is the expected result of hiring a dev.
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).
Over a decade-plus consulting career I always tried to either discourage spurious new projects or work myself out of current engagements. While this was locally sub-optimal it led to long-term relationships that meant meaningful work, strategic initiatives and more money.
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.
I've been attempting to automate making api's at work. Now I'm pretty close to deploying an entire aws backed api/storage using a graphql schema. Unfortunately, my boss constantly changes his mind concerning what the architecture should look like. Lol It's okay though, a lot of functionality can be reutilized across architectures.
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 hate meetings with a passion, and I work in HR data for a very large (40k+ employee) government employer in Western Europe.
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.
so far what seems to capture people's imagination is news about automation taking work of IT workers/developers as well as jobs belonging to service industry and manual/labor intensive jobs.
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.
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.