You know how sometimes you love an article so much that you are annoyed you didn't write it? This does a better job than I could have of tieing together a dozen threads of conversation that I've had with various friends for years.
I actually believe that there's a culture war implied in this debate; the question of who deserves to reap the gains of automation is more than just philosophy or ethics. The question "is there inherent nobility in work itself?" seems to be just as much a political divide as any of the current popular hot-button issues. Your gut reaction says a lot about the regional values of where you grew up, whether you'd ever support a basic income, and whether you believe that someone's refusal to work should condemn them to destitution.
The closest comparison is the attitude people have if they find a wallet. In Japan, you will get your wallet back with cash intact. Yet in the west, there exists a large contingent of people who believe with all of their heart that God wanted them to find it, that the person who lost it should have been more careful, that they are just having a lucky day. Unless God shows up and declares one side to be ethically correct, it will remain a toss-up.
One thing I find fascinating about the article is that it's assumed the cleverness was the code written to automate. This is incorrect; the cleverness is in noticing when a task can be automated. Typically, the code itself is trivial.
Anyhow: automation is surely one of the best reasons every person should learn a little bit of programming. And even with that task accomplished, I suspect that the rate of people seeing the opportunity to automate will stay roughly flat.
One thing I find fascinating about the article is that it's assumed the cleverness was the code written to automate. This is incorrect; the cleverness is in noticing when a task can be automated. Typically, the code itself is trivial.
I have told my work more than once that if they wanted to get the most out of me they should put me on the "front line" for a month or two, and let me decide what needs to be automated. It has always been laughed off as me being cute.
Try something like "In order to write better tools and automation, I need to empathize with the people using the tools and experiencing day-to-day pain. Can we find somebody who is willing to let me watch over their shoulder for a few minutes on one day?" Note the implicit bargaining for small amounts of time and only small intrusion, as well as the understanding that you are not a decider, but an observer; not an automator, but a pain-reliever.
Good advice, but the first line is completely unneeded. I don't think that assuming someone's manner of speaking to be off-putting based on a short, evidently intended as a summary, comment on a forum is a polite thing to do. Using this kind of thinking suggests that you're no less of a prick than the GP, which is obviously wrong... right?
There is a strange desire on this site to assume good faith. I have no idea where that comes from; nearly everybody is clearly posting with a heavy, thick personal bias. I suspect that folks only feel that they are arguing in good faith, and that their feelings blind them to their biases.
Even if being civil and assuming good faith wasn't baked into the ethos of HN (and YC in general), I'm genuinely curious as to why you'd personally default to assuming the worst in people. As far as strategies go, is it working for you? I am not being glib or sarcastic.
I ask because I directly attribute almost every bit of "luck" I've experienced to people acting in good faith. It's literally been the most important decision I've ever made and stuck with.
Personally, I have no energy for discussions where people assume the worst by default. That falls way too close to "someone is wrong on the internet" for me. It's easy to find people to disagree with, and difficult to find smart people that can illuminate why you might be holding onto incorrect assumptions.
The first line is very right. The op thinks his colleagues think he is cute but actually it is arrogant because what he is trying to do is take their jobs away. It's a Powerful feeling to think of automating as a programmer but also need to keep in mind the human emotions on the other side.
Our most recent stocktake I took the day off from programming, grabbed a handheld and went around doing the same job as anyone else doing stocktake, I have about half a dozen small-medium sized changes I can make that will vastly reduce time for next stock take.
I've also spent time in our sandblast units and our loading docks and sales team.
How can I architect and build good software if I don't have a good understanding of the domain and you can only get that by immersing yourself in it head first.
I'm lucky in that my boss cottoned onto the fact we get better software when I see the problem in the raw and not just his interpretation of the problem.
Wouldn't work for everyone, we are a small production/import company so it's possible for me to get the basics of each users role (and I can physically go ask them if need be) but it's a huge win imo if it's possible.
The proudest bug I've ever fixed came from working with the team using our software. They had a task that should take 5 minutes that the have to do several times a day but it was taking 30 minutes, 25 of those minutes was spent finding the right item in a massive list in a combo box (think medical codes). The only fix required was to an an order by clause so they could find what they were looking for, but they couldn't get approval for it. I took up the cause for them but couldn't get approval either, I couldn't get this two second task to be deemed a business priority and had to sneak the change in, risking my own ass.
The woman who had been wasting this time for years came up and hugged me in tears. No one was getting fired but I'd just freed up enough time that she didn't have to work overtime everyday. It was such a simple change and lifted such a weight off the users shoulders that went undone for years because nobody actually watched them using our software.
Unfortunately someones authority was undermined and I was let go a few weeks later.
Trying to get access to the people who actually do the jobs that can be automated is almost always a struggle. It seems weird and counter-intuitive to me so I have never figured out what to say to get this critical resource. Typically you have to gather user data through a telephone game-like chain of middle managers. And that doesn't really work,
In my case it's because my boss is smart and because I have a tendency of operating on a 'better to seek forgiveness than ask permission' model.
I have a huge amount of latitude in how I spend my time so if boss sees me in the loading dock scanning deliveries he assumes that I'm doing it for a good reason.
One of many reasons you'd need a crowbar and a tub of grease to get me to leave, I've had offers with 20% better compensation or more including some developer management roles but never even considered them, I'm well paid for a developer relative to the local market, I work a 37.5hr week, week in/week out and my work is both appreciated and has a measurable impact, it's close to programmer heaven (except for the mess I inherited but that's slowly getting sorted).
There is more to life than money including actually having time for a life.
I've found when trying this there's obvious resistance to inviting me in and showing me the ropes; they know I'll try to make it easier for them (still a manual job, in some aspects) but some are afraid I may eliminate their need.
That's because you're asking "Put me in charge and I'll tell you what needs fixing", instead of telling them what needs fixing first. I'd see if you can start with a thing or two, making sure to organize a presentation or something to present your work and the direct benefits from it - making sure to invite the managers' manager if possible. Alternatively, send an email to important people about the success.
I don't think that's what is being suggested. They aren't asking to be in charge, they are asking to experience the (potentially automatable) problems first. The leaders do not tend to be associated with the front lines.
And yet that‘s exactly how to create the most value. I believe deeply in the concept of „transferring pain“, as it‘s usually an order of magnitude easier to teach a good developer some domain knowledge than teaching a domain worker thinking in automation.
If I want something looking repetitive working smooth, I‘ll let my best devs do the work themselves for a week and dig their way out of it.
Heck, that‘s exactly how I got serious about coding in the first place. The guy in the post automated his job, decided not to tell anyone and played games all day. I told my employer about my automation back then and they were like - „so you wanna quit now or join Engineering?“
It is perceived as "let me show everyone what you have been missing." They are not going to allow that, just as a smart person is not going to tell everyone that they automated thier job if they don't think the environment is going to promote them for it.
Managers always think that they are smarter than coders. Lets face it if they admitted that we could make business decision well there wouldn't be much need for them.
Works just as well the other way around. Every time managers are mentioned at HN, some programmer is sure they can do a better job than their/most/all managers.
That's because programmers can do management. It's not unusual to see engineers get tracked into management. I have certainly never seen it go the other way (partially because managers usually make more than engineers I'm sure.)
Yeah, and most of the time (at least at places I've worked) the managers are former coders. So arguing that all managers are stupid just seems silly to me.
Also, yes - anybody can do management, and anybody can do coding. Learning to do either effectively is a skill.
> Lets face it if they admitted that we could make business decision well there wouldn't be much need for them.
Are you just making these decisions off the top of your head? Or are you talking to people, having research done, soliciting feedback, etc? In the latter case, congrats, now you're a manager! :p (If you're at a small company, you've probably still got enough time to do some hands-on work too...)
IME bad technical managers don't occur at any higher frequency than bad engineers; I haven't worked in other industries to know what it looks like there.
But you get a lot more immediate pain working for a bad manager than next to a bad engineer...
The first programming job I had I was actually promoted from being a "front-line" worker answering calls and processing forms all day, and I was pretty much able to write the software with no requirements explanation at all. So there is some value there.
I work in logistics and our company runs regular tours of our service centers that anybody in engineering can go on and get any questions they want answered. It's pretty great. it takes the tasks off the screen so to speak and puts them in real context.
No. By the time you get hired and you are appointed a set of things to automate, it's usually followed by a long line of deliberation and resource management and prioritizing that's determined on the higher up.
There is a thing called "process debt", in the same way as technical debt, that some things are done manually. This can be mundane routine work, that might be up to 80% easy to automate, but allows for oversight and flexibility and often works with systems that are not trivial to work with. Other times the manual process is just cheaper to maintain than it is to invest in a "good enough" automation. You can also follow this by looking at the practice of offshoring and the amount of automation invested into offshored service centers (who benefit most from these solutions via specialization and scaling).
So even if the company hires a goddamn genius, if you want to automate stuff without breaking existing flows, you need quite a few months of understanding of the environment and the real needs of the process (business wise as well), etc.
And that's why managers think it's a joke idea.
(And it also comes off as extremely arrogant, because it's essentially calling your coworkers stupid by saying "I'll see something that you haven't noticed in years!")
> saying "I'll see something that you haven't noticed in years!"
It's also arrogant to assume that a fresh perspective will never yield fresh results.
I'm starting to think that the only way to work around the problem (if you actually are good at seeing things that the rest of the organization has blind spots for) is to become a consultant who is expected to suggest changes. Otherwise you will be stuck fighting against primate hierarchy instincts.
> "I'll see something that you haven't noticed in years!"
There's this saying in my country, roughly translated to "Guest for a second, sees a mile far" (sorry... it even rhymes and everything in Polish...)
Being immersed in something for a long time has a good chance of limiting your perspective to that thing only. While it's true that perhaps 90% of newcomers and their ideas simply miss the intricacies of the current process and would be disastrous if implemented, the remaining 10% is a genuine innovation which would never come from the inside.
Same here. Instead we have all these meetings where a ton of managers talk about their workers instead of letting the workers talk directly.
Using your software for the intended work can be very eye opening. I have had many occasions where I had to use stuff I had written and quickly saw a lot of inconveniences that could easily be fixed. When I asked users about this they agreed but they never asked because they thought it would be a difficult change.
Recently I had to use our SAP system and there would be a ton of opportunities for small changes with huge time savings but somehow it seems they never trickle up to the devs.
It wouldn't surprise me if you found out that some work is useless in the first place. Many people lack the bigger picture of what the purpose of operations really are.
That's what easy to miss when thinking in terms of "automation". Automating existing work doesn't move us forward very much. Making the work unnecessary is.
> there exists a large contingent of people who believe with all of their heart that God wanted them to find it, that the person who lost it should have been more careful, that they are just having a lucky day.
A large part of how America sees work, poverty and wealth was historically influenced by the Protestant Work Ethic, and I think that lingers quite a bit today. I think it's why a lot of people view the poor as lazy (because obviously if they weren't lazy, they wouldn't be poor, right?).
If you fervently believe hard work will lead to success, how else do you explain the unsuccessful?
Looking at the history of religious thought in the US, it's not the Protestant work ethic per se, but in large part the "prosperity gospel" or prosperity theology [1] -- this belief that God will reward the right kind of Christians with material wealth. There are strong currents in Protestantism that posit that rewards are for the afterlife and that one may have to endure poverty in this earthly life and that's ok.
Which is funny because when I examine the writings of some Christian saints (e.g. St Teresa, Catholic in this case) they say things like (paraphrase) “try not to laugh at Christians who want you to pray for them to get money for being completely insane, they’re buying our food so you have to even if they are ridiculous” and then talk about how desire for immense suffering is a sign of spiritus progress
Those who work hard, a positive outlook, maintain themselves and their families, are resourceful ... will likely be healthy and abundant.
The farmer who idles away doing not much will have a bad crop. The farmer who is responsible and diligent, mends his fences, ploughs well, keeps his equipment clean and proper and minds the livestock ... will likely do well.
Except in case of disaster of course, and then maybe some kind of metaphysical excuses might come into play!
> Looking at the history of religious thought in the US, it's not the Protestant work ethic per se, but in large part the "prosperity gospel" or prosperity theology [1] -- this belief that God will reward the right kind of Christians with material wealth.
> Except in case of disaster of course, and then maybe some kind of metaphysical excuses might come into play!
there's a particularly distressing variation of this kind of belief that, upon hearing news that a terrible disaster has stricken a distant country, killing tens of thousands, concludes that those victims must necessarily have deserved such a fate -- by not living life according to the well-understood principles, or not worshipping the correct god.
that conclusion is perhaps a reasonable and logical one given belief in enough axioms like "there is an omnipotent god", "if we live a certain way god will reward us", "the universe is generally fair".
" upon hearing news that a terrible disaster has stricken a distant country, killing tens of thousands, concludes that those victims must necessarily have deserved such a fate "
This happens, but it's barely a thing.
I've never seen or heard of such a thing in real life, it's something you only hear about on CNN.
Services in mainline Churches don't really ever go into this kind of thing, the congregation would find it as wacky as you or I would.
> that conclusion is perhaps a reasonable and logical one given belief in enough axioms like "there is an omnipotent god", "if we live a certain way god will reward us", "the universe is generally fair".
I think this doesn't quite get it. Will "hard work" lead to success? No, not exactly. I don't think anyone believes that. A prisoner in a work camp works hard.
Hard work combined with personal agency leads to success. Are you responsible for yourself? That is, are you taking responsibility for yourself? If so, you will find a way to make yourself successful. If you are looking for someone else to take responsibility for you, for your healthcare, for your retirement, for your general environment and well-being, then naturally you will be at the mercy of whoever happens to assume that responsibility.
> I think this is a case where people confuse correlation and causation. Hard work correlates with success, but it doesn't cause success.
Not true, hard work is a cause of success, just not the only cause. Luck (opportunity) is a factor, but a much more unreliable one at that. Genetics is also a factor (intelligence, passion, curiosity, playfulness).
I like to see this problem from the point of view of Reinforcement Learning - an agent playing a game in an environment, having to maximise rewards - which is the definition of success. The degree of success depends on many things, including:
- the environment (how complex it is, how many potential rewards it has for the agent)
- the internal structure of the agent (its ability to learn and perceive)
- bodily affordances (what the body can do)
- the exploration/exploitation strategy (will it try something new when it already has a strategy that is sort of ok)
- the amount of time it has to learn (life experience)
- if the agent exists as part of a multi-agent environment, then the strategies of the other agents count (cooperation/betrayal, tit for tat, forgiveness).
In the effort of simple counter proof: you can dig a hole with a spoon.
That requires a substantial amount of hard work but unlikely results in a measurable amount of success. Certainly one less than would be if the proper tools were used.
And I do agree with you that it is not the only factor. But this is why I differentiate cause and correlation. And the disagreement is likely to how we are using those terms. I am using "cause" in the colloquial sense (because context from above) of how most people do not see multivariate equations, but single factor (which is an unfortunate thing) ie. "cause and effect" (but we both know better). I am using "correlation" in the more rigorous manner meaning "related to; a statistical variable; or to be in association with".
And going back to your RL example, I think you mention one part which proves my point as well.
> the exploration/exploitation strategy
You may notice that many learning algorithms have a substantial amount of failure. After all, it is the failure that leads to success. BUT a key point is that it is not the effort put into the attempt that led to success, it is the adaptation of a new strategy after recognizing the failure. You could just as easily never visited that attempt method and thus your efforts would lead to a higher success/work factor. You could also never change strategies and your efforts would result in a substantially lower success/work factor. More explicitly "hard work" is a variable that is coupled with "strategy", and the value of "hard work" can be astronomically high but the value for success can be zero. And for this reason we say it is not "the cause" but rather "a factor" or "correlates with".
Also, as mentioned in a grandchild to my post, this is a saying which I gladly will admit does not cover the entire scope of what factors lead to success. Even the unpacking of implicit information cannot do that, as a full description of the path to success is rather cumbersome.
"Hard work" makes no sense as a cause of success. "Hard work" doesn't cause anything, rather, it is a means to an end.
We could contrive an example whereby "working hard" allowed you to "create more widgets in less time than anyone else" and so you receive a promotion (success). But even then we know that your success isn't from just "working hard", but is instead from the result of doing so. Given the context of this thread, I think we can agree that "creating the most widgets in the least time" can be done without "working hard".
I would argue pointing to "hard work" as a cause of success is confusing how a causal factor was reached with the factor itself.
It depends on what you work hard on, as you say in your other comment. You can work very hard on things that never advance you in life (many people do!) or you can work less hard on things that lead to opportunities and advancement.
> Hard work correlates with success, but it doesn't cause success.
There is hard work and smart work, if you simply work hard you may or may not advance the way you want, based on luck. If you work smart you will advance the way you want, but not as fast as someone who works smart and a tad harder ;)
What if "luck" was actually just an individual's ability to perceive an opportunity... intersected with their own feeling that they have permission to act upon it?
> What if "luck" was actually just an individual's ability to perceive an opportunity.
>>Hard work results in being able to take advantage of more opportunities. But you still have to have those opportunities.
That's what is meant by "being able to take advantage of more opportunities. You are better able to see that they exist. You are also primed to look for them. You also believe that you can succeed at that opportunity. BUT a key thing is that they actually have to exist. There are situations where you can work really hard and there be no opportunities to be successful (financially. Because we can redefine what successful means but that doesn't consider context). As illustrated above you can work really hard in jail and that can result in no gained success.
But we're talking about sayings. Sayings are never exact but rather hold a generalization in a nice and easy to remember package. Sayings always include a lot of implicit information. We could quibble about finer details but whether you should or shouldn't depends on the context of the conversation and whether the context the saying is provided in contextualizes that implicit information.
What this saying packages is:
Though work highly correlated with success it does not necessitate it. There are opportunities for success frequently around us and frequently unseen. Hard work will not result in seeing or being able to take advantage of said opportunities, but rather it correlates with the ability to. Furthermore, hard work often correlates with improvements in skill, which grant access to new opportunities that previously were not obtainable. While there are a lot of things that lead to success that correlate with hard work and while success itself in turn correlates with hard work, success itself is not granted to all those that work hard.
I bought a lottery ticket, and I have permission to win, yet I didn't.
I suspect luck is, in fact, simply the event of uncertainities crystallising favourably (or unfavourably if the luck is "bad"). Like it says in the dictionary.
Yes, to me luck is exactly that: the impact/outcome of uncertain or unpredictable circumstances. If they work out positively, then we say it was good luck, if negatively, then we say its bad luck. So luck is just a name for something that happens to us that we feel we didn't have any control over.
Which is also why many people believe we make our own luck: because in many situations that people attribute to luck, we can influence the outcome, consciously or otherwise.
Okay, I’ll bite. I don’t think this large contingency of people exists. I’m sure a lot of people would keep lost money rather than turn it in, but I’m very skeptical that there is a widespread view that this is an acceptable or justifiable action.
I'm not sure I disagree with you in this specific case, but I think it's fairly easy to tweak some of the details (is there identification in the wallet? Is it obvious it's been missing for an extended period? What if it's not money, but some possession?) and vastly change the percentage of people that would respond one way or another, even when there might not really be much ethical difference.
That said, I was mostly pointing towards what I see as an explanation for the difference in attitudes regarding wealth and poverty and how it intersects with peoples opinions of personal responsibility, which I think does have a place in that scenario, even if it's not always the primary driver.
>who believe with all of their heart that God wanted them to find it
Yeah OP is way off on his God scapegoat. People in the West are far more likely to not return a lost wallet due to the wide variance in cultural identity. Japanese people have such a shared identity which promotes a level of empathy that only Americans in small towns could hope to replicate. Call it hospitality. Religion has nothing to do with it.
I'm not sure about that. I've seen multiple threads on reddit about cases where someone was overtipped or accidentally transferred money and there's usually a lot of comments arguing why they shouldn't have to return the money.
It cuts both ways at least, those with inherited wealth are just as unworthy as those who never accumulated any.
> The so-called Protestant Ethic
then prevalent held that man was a sturdy and responsible individual, responsible to himself, his society, and his God. Anybody who could not measure up to that standard could not qualify for public office or even popular respect. One who was born "with a silver spoon in his mouth" might be envied, but he could not aspire to public acclaim; he had to live out his life in the seclusion of his own class.
> It cuts both ways at least, those with inherited wealth are just as unworthy as those who never accumulated any.
In theory, but in practice that just means that those with inherited wealth expend some of it on building a personal myth of being self-made independent of their family legacy. It's often paper thin, but as long as they make the gesture to ritually acknowledge the norm, it seems to suffice in practice.
Obviously, no parallel equivalent exists in the other end of the economic scale.
> In practice that just means that those with inherited wealth expend some of it on building a personal myth of being self-made independent of their family legacy.
This happens a fair bit in the UK. Due to the media's obsession with entrepreneurs, we see the wealthy gambling a bit of family wealth on a series of startup ideas that are clearly not made for the reality we inhabit but sound snappy and fin-techy (blockchain for banks, with no understanding of banks).
> Obviously, no parallel equivalent exists in the other end of the economic scale.
If you take away the spending of money bit, there is an equivalent at the other end of the economic scale.
There exists some person with inherited wealth that builds a personal myth of their inherited wealth not being responsible for their current wealth.
There exists some person in inherited poverty that builds a personal myth of their inherited poverty not being responsible for their current poverty.
By no parallel equivalent I mean that there is in practice no equivalent method for someone in overt poverty to fake virtue under the particular model of virtue being discussed as there is a wealthy person whose wealth is inherited rather than earned. (It is sometimes possible for a person who is not wealthy to fake wealth to fake virtue under the system, though it's more common for a person who is wealthy to fake greater wealth for that purpose—Donald Trump is, interestingly enough, an example of both this and the pretending inherited wealth is earned methods of faking the virtue of earned wealth.)
> It cuts both ways at least, those with inherited wealth are just as unworthy as those who never accumulated any.
Not really. Because the idea is "To become successful you must be hard working". And if we take that as "iff hardworking -> successful" then the reverse is true "if successful -> hardworking". That's why so many people think the rich are hardworking, even if they inherited their wealth (or a sizable portion).
Originally, sure, but I think it's been perverted over time (in the USA at least) to the point that it's really only applied to the destitute. Also, I think it's become enough of a cultural norm that the non-religious (or those subscribing to a different religion) still feel some pull towards the concept since they were raised where it was prevalent.
It also comes down to it being easier to spot someone in poverty than to spot someone that's rich but hasn't worked for it themselves. That might explain most of it.
> I think it's why a lot of people view the poor as lazy (because obviously if they weren't lazy, they wouldn't be poor, right?).
There's a sleeps-on-the-street homeless guy living in my neighborhood. I talk to him on occasion. A couple days ago he said he was bored off his ass, and that he was thinking of getting a part time job. I did not verbally respond to his potential quest for employment, but I did find myself wondering how he'd pull that off. He's perpetually drunk & unshowered. I doubt he could get a job if he wanted one. Are there any attainable jobs for an alcoholic who doesn't have a shower to use?
Lots of outside work, depending on locale. Lawn mowing (depending on the type of alcoholic. Best not to contribute to lost fingers or toes), ditch digging, etc.
Dumpster diving (if it's still worth while, which it might not be).[1] If you're serious about it, it's not really any less of a job than those American Pickers guys.[2]
There's lots of jobs out there, especially if you widen your criteria for "job".
1: I had an interesting run-in with a homeless man at a taco truck almost two decades ago. He was in clean clothes, had a bike with a trailer, and was trying to sell a 49ers jacket. My friends and I started talking to him and he explained that he found a few of the jackets in a dumpster behind one of the big sports stores around, and had a few other things to sell too. He explained that he and a few friends actually had a fairly nice camp (carpeted areas, make-shift shower with water in the day through solar of some sort, DVD player with TV hooked up to solar trickle cell). He camped a little outside the stalled development of a local apartment complex, where they had an agreement with the developers that they could stay there and they would keep people from squatting in the partially completed complex so it didn't sustain damage. He said he was on disability from the military, and liked living outdoors, but would probably rent an apartment for the winter with his girlfriend and friend. Honestly, I left the interaction feeling a little envious of his freedom.
Not many that I can think of. Look out for local drug dealers?
Possible he could find a job that includes access to a shower. I know of once case where that has occurred. It was a job in a warehouse and there were showers and change rooms he could use. I believe he was actually provided with an unused room tucked away somewhere where could stay overnight before someone higher up in the company found out about it and put an end to that arrangement.
"Perpetually drunk" is more difficult and likely a deal breaker.
Finding a shower no, but depending on how long he's been an alcoholic getting sober could be a different story, and alcohol withdrawal is one of the few withdrawals that can be fatal and frequently requires medical supervision
One thing that I find maddening about this topic is the assumption that people who automate their jobs won't take the new time they get back and put it to better use. For some, that could be learning skills or working on a startup, and others might just want to spend time with their kids.
That said, it seems incredibly wrong to judge someone for being clever enough to relax and get paid for it. And if someone enjoys relaxing as much as I enjoy coding, who am I to say that I'm righteous and they are a loser?
I wonder if it's possible to turn things around for some people: Sitting around relaxing, and then doing their work in bursts of cleverness, may be a coping mechanism for someone who has a hard time staying continuously busy all day long. Or maybe there's a sliding scale between those extremes.
I fall somewhere towards the side that you might guess, since I'm defending it here. ;-)
I don't necessarily automate my job, but I depend on things like math and theory, to solve problems that the other engineers tend to solve laboriously through brute force and trial-and-error. I suppose a math equation is a sort of automation. And of course programming is how one does math these days.
Maybe I avoid resentment, because I'm doing work in a way that most people hate even more than doing hard work. It's also hard for them to pin down how much I work because they don't know how to estimate it.
Hypothetically, if someone wanted to debate with me about the value of work, I'd ask them how work is measured: What are the units of measure? Joules? Hours? Indulgences? How about... dollars?
The only time that we don't measure work in dollars is in a social setting, including within the workplace. For instance, we don't give motivational speeches and other kinds of attention such as meetings in proportion to your wages, but tend to treat all workers relatively equally in those things.
While not everyone on HN is a developer, it does tend to skew that way so I don't feel guilty pointing out how frustrating it is to measure the output of a top programmer.
Often, a mature codebase shrinks as code quality improves. This drives the efficiency wonks absolutely bonkers.
I think they're referring to the problem of measuring programmer output (and thus, measuring programmer efficiency). And how the output of that work (lines of code) can actually be reduced, but still considered productive.
In most areas of business, there are important signals which can be observed that are often based on counting values over time. There are people for whom it is their primary job function to identify what should be counted, and how.
When a codebase shrinks AND increases in quality, you've now demonstrated that the most obvious way to quantify the utility of a resource - units of productive output - is not useful. So now people who are used to tallying widgets and graphs that are "good" if they move up and to the right, now have to understand things like refactoring, technical debt and design patterns.
> I don't necessarily automate my job, but I depend on things like math and theory, to solve problems that the other engineers tend to solve laboriously through brute force and trial-and-error.
> One thing that I find maddening about this topic is the assumption that people who automate their jobs won't take the new time they get back and put it to better use.
I think it's fair to say they will, but will they do so for their company's benefit? Possibly, but why? This is effectively gifted time.
With the way things are going, I’m not sure learning a little bit of programming will help. Digitization has really begun rolling with RPA, because we now automate system processes for systems with no apis and no direct data manipulation.
But even though RPA is mostly screengrapping and macros, we’ve found it impossible to teach to people who aren’t developers.
Similar with better BI tools it’s become possible for sql savvy business process people to do BI, but without s fundamental understanding of data efficiency, which we can’t seem to instill in these highly educated people, what they make is often useless because it slows the systems.
Programming is completely trivial, but understanding what you’re doing, and why. Is much harder to teach than programming. Especially when you’re working toward productiveness where you can’t just write best practices for everything because best practices are often unnecessary for some systems and necessary for others.
I know this wasn’t really that related to the article, it’s just a general observation, and believe me, we tried to decentralize our RPA processes because maintaining them is hell.
I had to Google RPA. Never heard of any of those tools.
What I have heard of - and directly witnessed - is MS Access and MS Excel being used by non-developers to build surprisingly powerful tools to solve their most acute problems.
They often don't even realize that they are programming.
Yes, that's true, but there are also plenty of cases of them making mistakes (the amount of money lost per year to mistakes in Excel spreadsheets is something obscene) and getting in way over their heads.
It’s a macro you program to use it systems through the UI. People already mentioned blueprism, uipath and automationanywhere, there’s a few others.
It’s an immensely valuable digitization too in enterprise setups where you operate s lot of closed and/or legacy systems. Like we operate around 600 it systems, and very few of them talk to each other.
So if you want to transfer data from one system to another, you’d need to have someone manually do it. Or you could automate it by using RPA software.
Basically it’s what will do to the office space what the assembly lines did to factories.
It’s also really terrible, because it breaks when the UI changes. But when companies refuse to sell open apis, it’s what you have to work with. The most ironic part is the IT companies that now sell RPA solutions for their own shitty software, but that’s the world we live in.
Mostly screen scraping / macros. A lot of what I see is over marketed woo (“cognitive RPA”), but it’s basically a watered down version of selenium that (in theory) a programming novice could use to automate tasks.
The tricky part is that there is a finesse involved to make it reliable and the exercise becomes more process improvement than programming. Most people struggle with this and you end up with a 2000 line-of-code Rube Goldberg machine that always breaks.
Following up on this is how heavy these things are marketed. We’ve spent around $1MM in the last two years on Automation Anywhere and around $2MM hiring consultants to implement it.
Part of it is because our IT department is underfund and dysfunctional and RPA is the only “controllable” way to improve processes (in execution it’s not) and part of it is because our management have drank the cool aide that automation anywhere puts out about the impending singularity.
I’m all for automation, more for process improvement; but at 2.5MM for a bunch of brittle macros running critical functions; it’s way oversold and too immature
As a disclaimer, my name is George (https://george.nychis.com) and I helped found a software automation company based out of Boston, MA that is "related" to this space called Soroco (https://www.soroco.com). Our focus is around solving the kinds of problems you talk about. Building automation to replace repetitive and deterministic work across software systems in the enterprise.
As you have learned, RPA is mostly screen scraping, macros, and as another person referred to it below "Rube Goldberg machines" that break when UIs change. For all of these reasons above (the need for automation and the limitations of RPA), we started Soroco. Like you said (and we agree) you can't build serious automation without real development.
We take a fundamentally different approach which is to build a platform/SDK for automation that provides a significant amount of reliability on top of a number of unreliable automation layers. There is no other way to automate Windows applications or Java applications than through either A) Screen scraping, or B) Their accessibility layers (e.g., Windows UIA). The problem is that BOTH are extremely unreliable. For web, that equivalent is Selenium (at least as the primary layer).
As another commenter mentioned below, a "watered down version of Selenium" is exactly what is NOT needed -- nor are Windows UIA or other accessibility layers great. They are all extremely unreliable. When something like Selenium fails to find an element, what do you do? Halt your business critical process?
All of these frameworks were never built to handle business critical processes, they were mainly built for application testing. The RPA industry has basically tried to leverage them and pretend they are enterprise ready by hiding them behind flow chart builders. They are NOT enterprise ready.
To draw an analogy, it's like having the Internet and IP, which do NOT provide or guarantee reliability. You need the equivalent of TCP and reliability layers.
At Soroco, we have dealt with all of this and have put a tremendous amount of effort into building reliability layers on these unreliable systems, along with security, scalability, and machine learning. We construct automation systems using a full programming language (Python) and have built flow control layers and reliability on top of it. Sort of like an automation SDK for Python with a full IDE. We have lots of supporting microservices for storing credentials securely, storing information scalably, and deploying. We've even open sourced how we encrypt Python (https://blog.soroco.com/)
What does "cognitive" mean in this field? At Soroco, we don't pretend automation systems can "self heal" or "self construct" -- that's just silly. For Soroco, cognitive means that if you had your automation system do the same thing over and over (e.g., during User Acceptance Testing)... what can it learn about the distribution of inputs or outputs to flag anomalous behavior? We also apply Machine Learning and Computer Vision to specific use cases to make them achieve what is not possible through a laundry list of conditionals. For example, ML/NLP to classify intents of text and to do things like binary or multi-class classification.
There's a lot of noise in the RPA space. I'd be happy to share more with you if you want to reach out directly to me: george@soroco.com or gnychis@gmail.com
Are you familiar with Automa? I tried to get my organization to purchase it for automated testing, but approval for that ran aground on the fact that Automa doesn't have a US distributor. (As you may infer, I'm a gov't contractor.)
I was hoping that your company offerred a product similar to Automa, but it looks like your business model is different to that.
Anyway I ended up having to re-implement my Automa-using Python scripts using a different technology (TestStack.White and C#) and I 100% concur with your analogy about TCP over IP and building on unreliable foundation. It's also analogous to the sensor fusion problem of AI: picking out what to do when different methods of interacting with the automation layer report conflicting results. (And you have multiple ways because you need the redundancy to detect and deal with problem #1 - automation interfaces are incredibly unreliable.)
For example between IT-mandated invasive antivirus software injecting shims in the OS and/or screwy win32 code in the program-under-test, or bugs in TestStack.White, (I've found indications of all three causes) there is some kind of randomness or ambiguity in the Window handles you get when you ask for certain controls on a dialog. You might ask for the OK button and get the button 50% of the time and 50% of the time get a handle which turns out to be the textbox above it.
So I've taken a belt-and-suspenders approach and built a database of all of the controls I expect to find and their screen positions, a folder full of screenshot snippets which I intend to make my test automation program compare, and use that to augment what Windows UIA is telling me is on-screen. Due to the problem of receiving the wrong window handle (on this app) when I ask TestStack.White to find a control at a certain position or by name, I resort to just cross-collating the entire list of controls on the window with the best match from the database. However even this is 4x harder than it should be, because for some reason the positions and sizes in the database (obtained by a previous attempt with a different automation tool) differ by small pixel amounts from what TestStack.White reports. So I had to implement a fuzzy match.
And then the entire object-oriented architecture of my automation utility program collapsed on itself like a house of cards, because now I have 2 or 3 different derived classes to represent "the same" conceptual object: if you code "button.Click()" should it click the button with the handle found by TestStack.White? Or click the coordinate from the database? Or click where the screenshot matched? Or do nothing because this is a mock object? Worse, I now have a constellation of 1..N OOP instances associated with each conceptual object: maybe the database says I should have a button, but I can't find a handle for it thus I cannot create a ButtonFromHandle but no matter I can still click on the center coord of ButtonFromData. But if I have both I really want to default to one (which?) that is most reliable. Object-oriented programming design methodologies are completely inadequate to deal with the case of "some number between 1 and N instances actually represent one conceptual object and should be treated like a sheaf of overlaid transparencies". Yes, it can be done, but the design turns into something that makes sense from that aspect but makes no sense from the API-user's point of view: you just want to click "the" button you don't want to do "button.Implementations.First().Click()" or some such. Then add in multiple layers of mocks for unit testing the automation tool and you get N*M combinations...
Not sure where I was going with this, I guess I'm just excited to find someone who's worked on the same (or similar) problem.
> You know how sometimes you love an article so much that you are annoyed you didn't write it?
I love this article because it changed my mind. I was one of the redditors who urged FiletOFish1066 to fess up to his employers on the basis of some moral high ground I felt I occupied. I see now that I made the mistaken assumption that work == goodness and went on from there.
I've read a quote somewhere and can't remember the source: "if work would be so great, the rich would keep it all for themselves".
Most of us work because we have to.
I'd like to reach the point where I work 100% because I want to, not because I want to avoid the issues created by lack of money.
Depends on what you mean by "traditional". Even in the New Testament, you'll find passages like 2 Thessalonians 3:10: 'For even when we were with you, we gave you this rule: "The one who is unwilling to work shall not eat.' There are probably examples from the Old Testament as well.
Perhaps Nietzsche, with his critique of traditional Christian values, can be seen as a reaction against Christianity.
In general the New Testament preaches the idea of being a servant to others (Acts has the apostles living in what's basically a commune). This is a little different than the more unidirectional model of most workplaces.
But work has for a long time been considered noble, also, if you consider the kind of work we do not as not so much 'labour' i.e. creative endeavor, then it's even closer to both 'nobole' and 'Noble'.
I'm not sure what you're getting at with the capitalisation. If it's that "Noble" to mean "of high birth" may only be used as a noun, then that's untrue: https://www.merriam-webster.com/dictionary/noble
When most people or organisations are purchasing a service, they're usually mainly concerned about the value that service will bring them.
The amount of effort required to produce that value, helps to dictate market conditions and the amount of competition; aside from this, ultimately I don't think effort matters so much when you consider it in terms of B2B transactions.
Eventually, if a service is easy to supply—competition will drive down the price—and the economic system will readjust accordingly.
--
Strangely, it's only when you consider an individual in permanent employment that automation seems to present itself as a dilemma.
There's definitely a lot being said about automation. We're regularly told via news outlets that a large percentage of the populations' jobs will be replaced by robots.
But aside from the idea of universal basic income; I believe there's a more general trend towards working independently, i.e. in a freelance capacity.
Maybe automation becomes far less of a dilemma when this is this case?
Maybe it is only paranoia, but over the course of my career I have seen an increased treatment of the employee like chattel. The rights of employees have eroded, almost by choice, through social media, smart phones, monitoring technology.
I, personally, had had enough. I decided to remove myself from that environment. I believed that it was dehumanizing and degrading. I started working remotely on contracts. That worked pretty well for a while. But I started working for one company where slowly they wanted me to become more and more like one of their employees and less of an independent contractor. In addition to the work covered by the contract, I was asked to help on other projects or with interviewing. Initially I didn't mind because I wanted to help. After a while I realized what was happening and that is what prompted me to create my own company to work through and to be paid for the end result rather than the time spent on the result.
With respect to the article, there are some things that I think you have to accept as an employee. You probably have signed away the rights to the IP you create at your place of employment. After all, you probably did it on company time with company equipment. But ultimately that is the agreement you entered into so you cannot turn around after the fact and complain.
However, my sympathy lies with the person that automates their work rather than the employer. I think that the ethical problem is interesting. Recently I watched the Crash Course on "meta ethics" and the problem they considered was a burglar who intended to steal from a little, old lady but inadvertently saved her life instead. And the question is, 'was the burglar good or bad?' I think there is a parallel to the issue of automating your job. I am no philosopher, but I think this is an interesting question.
It's because there's a conflict of interest in who reaps the benefits. If the company makes the decision to automate, it's clear that it's the company that reaps the benefits. If a worker chooses to automate, it's ambiguous.
The problem is automation is never truly automated in most jobs. There's always things that go wrong, always changes being proposed, always explaining needing to be done. Sure, you may find it easy to automate a report or data entry, but what if that data changes or the format changes? Then you have to fix the code.
The code is almost never trivial either. It often involves integrating complex systems and making sure that they work which, if done right, involves writing several unit tests.
Using God is a poor excuse to determine ethics because there's no evidence one exists. It's especially a problem when you don't share the code because then, instead of creating improvement to the job for the company as a whole, you've written a pass to be lazy. The real job comes from supporting whatever you write to the masses. If you don't have any interest in that, you're simply selfish.
The problem is people react in different ways, but it seems like the most common way is to not tell anyone which in my mind is foolish because even if you do get fired, you've improved your skills enough to find a better job anyway. Not only that, I can just as easily come up with an example of someone getting promoted for automating job tasks.
> the cleverness is in noticing when a task can be automated. Typically, the code itself is trivial.
> Anyhow: automation is surely one of the best reasons every person should learn a little bit of programming. And even with that task accomplished, I suspect that the rate of people seeing the opportunity to automate will stay roughly flat.
Absolutely. A minor observation I have, living in Operations/Finance. Don't merge cells in Excel. Observing a spreadsheet is a fantastic indicator of an individual's knowledge of automation vs manual process. Someone that uses lists without merged cells is someone that not only can save days of of the year with pivottables, various forms of looking up, but probably has the idea of 'tables' 'if' and 'for' in their head.
This is a great kicking-off point for coaching through ugly VBA. I like VBA. It's also often the only choice in corporate environments. But it is an option, and the chance to coach someone that's on the edge of...
> I suspect that the rate of people seeing the opportunity to automate will stay roughly flat.
It all depends on who is rewarded for the automation. Salaried employees who automate are generally recognized for the productivity that automation provides. Low level data entry people are not rewarded.
Your story reminds me of my son who graduated with a liberal arts degree right after the financial crash. He completely automated his first job (using excel and VBA) and was not rewarded. Long story short, he went back and got a masters in EECS and works where productivity is recognized.
Good for your son. Sadly check-box HR ticks are too often required for being recognised, that's something I have to fight against where operations staff are 3x underpaid compered to developers yet arguably far more agile.
> I actually believe that there's a culture war implied in this debate; the question of who deserves to reap the gains of automation is more than just philosophy or ethics. The question "is there inherent nobility in work itself?" seems to be just as much a political divide as any of the current popular hot-button issues.
Agreed, there's a lot of meaty ethics and philosophy tied up in this issue.
For most of my life I've tended to believe in the nobility of work, that it gives my life meaning and purpose.
But as rates of automation increase my children (or more likely their children) may well seek different ways of defining themselves.
Before that can happen though there'll have to be some fraught and difficult changes to our societies.
the cleverness is in noticing when a task can be automated. Typically, the code itself is trivial.
I’d actually argue the reverse. It’s trivial, especially with a little programming background to say “we could automate X”.
The devil is in the details. Robustly automating anything of reasonable complexity involves a lot of implementation hickups, dealing with corner cases, gracefully failing, and adding structure and regularity to otherwise disparate, adhoc and unstructured components.
It takes skill, experience and a lot of effort to do this without it immediately falling over.
I'd never presume to critique your lived experience, but in my life and career away from core developer circles, the instincts required to recognize the potential for automation were just... not part of the conversation.
It's similar to how most people will complain about the traffic while a very small number of people will start companies to dig tunnels for maglev vehicles to travel on.
Now, I choose to believe (I'm a realistic optimist) that some of these instincts - to recognize patterns, to ask orthogonal questions, to pay attention to what others take for granted - can be acquired. It's less about training and more about practice. You can decide that you're going to learn how to ask good questions.
It's a conscious act, and that is key.
Anyhow, there's certainly skill and experience required to automate well. However, it's SHOCKING how many people learn to build simple systems in MS Access or Excel to solve their own problems.
They often don't even realize that they are programming.
> It's similar to how most people will complain about the traffic while a very small number of people will start companies to dig tunnels for maglev vehicles to travel on.
Well to be honest there's only a small number of people with the means and connections to even start such a venture.
Hah that's funny... I'm literally sitting here waiting for a call to go meet a guy and return his wallet that I found in the middle of the street. Hope it goes well, not looking for a reward or anything.
I've had a variety of lost and found experiences over the years though. Returned a wallet with over $700 to a guy at my gym; he barely even took a second to thank me and just went on with his conversation with someone else. Returned a smartphone to a lady who was mostly shocked (and maybe a little embarrassed about some of the pictures she had on her unlocked phone...). Only regretful experience I've had so far is another time where I turned in a new (at the time) iPhone to a store's customer service counter instead of tracking down the owner myself; I left with a bad feeling that the person behind the counter wasn't going to put as much effort into finding the owner as I would.
Your feeling is one I would share. They probably won't.
My experiences are similar. People really vary in their response to a good deed directly favoring them, and I suspect the nature and quantity of deeds they do can be correlated to those responses.
I once found a lost cellphone, and after its owner called it, we arranged to meet and I returned the phone. The owner's reaction was very similar to what you describe. I refused any reward - it seems natural to me to just return it - but later that night (it was a Friday night and I was out for drinks with friends), we bumped into him in a winery, and he ended up buying me and my friends a huge jug of very good wine, out of gratitude. :)
> One thing I find fascinating about the article is that it's assumed the cleverness was the code written to automate. This is incorrect; the cleverness is in noticing when a task can be automated. Typically, the code itself is trivial.
I thought about this too. Pretty much everything I've automated turned out to be way easier than I assumed and I ended up feeling dumb for not realizing I could have saved myself time by doing it sooner.
> ...whether you believe that someone's refusal to work should condemn them to destitution.
I don't understand what you're getting at there. If someone refuses to work, that would seem to mean that they are able to work but choose not to.
We're not talking about someone who is actually unable to work because of some physical or mental limitation and may need assistance of some sort. We're taking about someone who could work but doesn't want to.
What possible obligation do I have toward that person? I don't see any. Of course I don't think they should be, as you put it, condemned to destitution. But what on earth makes it my responsibility to give them anything at all? Do I owe them a living, simply because they refuse to work?
Sure, but that's because developers are expensive, and poorly quantized - In a professional capacity, you can't really hire a developer for a weekend. That requires a direct connection, usually a personal one. There's probably a hundred thousand tasks that could be automated but have never been within ten feet of a developer because it never comes up. Something that you and I would do in ten minutes of perl would likely be someone's full time job.
This absolutely increases in complexity as the benefit increases, mostly due to the low-hanging, prime fruit already being picked... but there's still tons of stuff being handled by humans still. Moreover, as techniques and computing power become cheaper and cheaper, stuff that used to be hard (OCR!) becomes easier all the time.
Having a good worth ethic is respectable. However, working smart can be as effective as working hard. Still, lying about doing work is unethical in my opinion, even if it's clever. Depending on the situation though, I think that letting your employer know that a job can be automated may lead to better opportunities in the future... maybe?
"is there inherent nobility in work itself?"
there certainly is benefit called experience, who cares about nobility. in certain parts of the world nobility is last concern
I think you'll find that most people who 'keep the wallet' are probably not religious and don't think about it the morality of it all that much, whereas those who are regular temple/church/mosque attenders would be among the least likely to 'keep it'.
That's a nice thought, but do you have any evidence to back this up?
The notion that religious people are less likely to do bad things is highly problematic, objectively and logically - and it carries the unfortunate assumption that non-religious people are more likely to do bad things.
People should not need to subscribe to a paranormal belief system to understand that theft, rape and murder are bad.
There is overwhelming evidence that religious people, particularly those who attend services are less likely to be involved in criminal activity.
Your assertion that the religious or church attenders are mostly about 'belief in paranormal activity' is really quite missing the ball, to the point that it's almost offensive - though it's a common misunderstanding.
Most classical Churches, Synagogues etc. are basically old-school community centers, where morality, behavior, contentiousness is passed on from generation to generation.
Devotion to 'a higher purpose' and 'the community' is basically paramount and instituted into all ideals.
FYI - it's actually not that much about 'belief', funny enough it's mostly about 'behaviour' which is highlighted in the research that hints that 'attendance' is the strongest predictor, less so 'faith'. (Sorry, I tried to find that specific article and could not).
I'm not some kind of 'holy roller' or whatever, I'm just constantly shocked at the odd misunderstanding many super secular types have about religion. The original posters bit about 'God wanted me to keep the wallet' triggered me because that's basically the opposite of what most religious people would instinctively think: to most service attenders, that the 'wallet belongs to someone' is a most obvious observation. Most mainline religious groups are like 'boy scouts' and 'girl guides'. A little conservative, generally very conscientious.
I actually am the OP, and I just wanted to say that while I suspect we disagree on some fundamentals... I am extremely impressed by the quality, tone and effort to link to research evidenced in your two replies.
As you deduced, I missed your initial reply because we both posted at the same time.
For what it's worth, I'm also in Canada and my best friend is a Christian. She was not born into it and has always been really great about being willing to admit when she doesn't know the answers to something. This has, in turn, inspired me to be less of a judgemental asshole.
Don't get me wrong: I still have a really hard time with the idea that intelligent people can justify worshipping malevolent invisible sky wizards. And a lot of my bias against religious influence in modern society comes from the organizations themselves, and not their members. Evil priests, etc are over-staying their welcome.
However, I am heartened to know that research suggests religious people are less likely to be criminals. Happy to acknowledge that I learned something. I do wonder if causation/correlation are skewed, here... as in, would those people still be good if they'd grown up in secular families?
Anyhow... great chat. Feel free to update if you think of anything else.
What constitutes a 'Criminal Act' in generally accepted terms? We can probably agree that there are some cases which generally considered 'bad': Stealing, Killing and others. But even some instances of these 'bad' acts are also up to debate (stealing to feed your kids, killing in war or self defense...).
But it's also worth noting that what constitutes a criminal act is largely dependent on the laws that are enacted by a majority (this is also a broad generalization). Taking into account that a majority votes these laws, these laws will also reflect that same majoritie's Religious (or lack thereof) beliefs.
This 'hypothetical' religious majority will probably never vote for laws which 'criminalizes' their beliefs and actions! Thus it's quite easy to see that Religious folks from this majority will never be deemed criminal.
As a thought experiment: imagine that attempting to obstruct or make it more difficult for someone to have an abortion was illegal. How many more religious people would become 'criminals'?
In conclusion, one person's definition of criminal is another's person definition of a 'hero'. Claiming that religious people are less likely to be criminals is based on shaky assumptions in my opinion.
Evidence, no. I haven't done that particular research.
However, I do spend a lot of time in conversation with my best friend - who is a late-convert Christian - about the distressingly common phenomena of people who call themselves Christians because it flatters them, but don't actually participate or behave in the way they are supposed to.
You know, like the POTUS.
I do happen to believe that religious people shouldn't assume that they act better than non-religious people. We all have to draw personal lines somewhere.
Someone who is a 'huge believer' is utterly something different from someone who was born and raised Jewish, or Anglican and was raised that way.
Growing up Jewish/Catholic is mostly a matter of culture, tradition, community, it actually has less to do with faith. That's why I focused on 'attendance'.
They tend to be small-c conservative: normal jobs, kids attend school regularly, don't do drugs, eat reasonably well, vote, take out the garbage, stable family etc. etc..
'Converts' are a whole other issue because ironically people who grow up in a regular faith aren't likely to convert to much at all. Seekers, people who are emotional about stuff, people who have had major tragedies, drug problems, who had major family problems, maybe lived on the street ... those 'new beginning' people are often the most outwardly 'believing' but they represent a totally different cohort of behaviours.
The guy who was abused by his parents, lived on the street and smocked crack and then 'saw the light' and is a 'true believer' - this guy is going to bring most of his broken habits with him. This guy is not Ned Flanders.
The other issues is type of religion: Evangelicalism is kind of like a 'Church of Converts' - they are 'living in faith' type thing. The type who mostly watch 'Church on TV'. This is not the camp of people I mean. Again this is not about how someone outwardly talks about / believes in Jesus or whatever.
Old-school, traditional, mainline Churches are full of boring, very conscientious, small-c conservative people. This is my point. I'm not saying so much it's about faith per say, although that's probably related.
I mean, he said it outright: “I think you'll find that most people who 'keep the wallet' are probably not religious...”
I don’t think it’s so much a carried or implied assumption as his central thesis, and his justification down the thread is a page of more claims and anecdotes. Call me cynical, but I don’t think there is any “there” there.
" Call me cynical, but I don’t think there is any “there” there. "
I provided links to three articles of data to support my primary thesis, moreover, if you do a Google search you will find overwhelming research in support of the fact that 'those who attend regular service are less criminal'.
My 'anecdotes' are there to help contextualize it for you.
So the 'there' is so obviously 'there' ... the question is, why, even when faced with actual data to people keep doubting? That's the interesting bit.
And to be clear I'm not religious nor do I attend services.
So we have a HuffPo article, an article from MarriPedia (a religious site) and an abstract from the Sociology and Religion department of The Association of Sociolgy and Religion. Three famously unbiased, data-driven outlets (/s) which even then, only tangentially support part of your point, and then only through the loosest of correlations.
I base that on 40 years of life experience and travel and living in a variety of communities.
But there's overwhelming evidence of it, an BTW I'm not saying 'religious' per say, but 'church attendance' which is a much stronger overlap with conscientious behaviours.
[1] [2] [3]
People who doubt that regular church attenders are more likely to 'return wallets' I think have little exposure to classical religious communities. I don't mean to offend anyone, but I've found so many people who have no exposure to it have weird and cynical ideas about mainline religions. I'm constantly surprised.
In the very example given: Japan, where 'nobody keeps found wallets' - this is a culture of 'strong cultural ('small c') conservatism and communitarianism. Obviously with shades of ethnocentrism. They're not religious in the same way Westerners are, but they have a whole set of super concientious behaviours perfectly consistent with those here who are 'religous service attenders'
The best analogues in the West are basically agrarian communities, who by the way happen to be religious, or at least 'church attenders'. About 2 generations ago, in the West, most people lived in agrarian communities, even if they weren't farmers, they were tied to that lifestyle, attended service, yada, yada. You lose your wallet there, and nobody will steal it.
In my home town, my grandparents generally did not lock the door to their house. My father still generally does not lock his door.
Now - 99% of my grandparents and their peers attended Church, but they were mainline religions (I'm in Canada, we don't have a lot of this Evangelical, Baptist or Mormon kind of stuff) - but they were not what we would not refer to as specifically 'religious'. I mean everyone did it, it's just what people did. Nobody ran around talking about 'Jesus' etc. - rather, it's more or less part of cultural tradition. Watch UK television series that are set in smaller towns to get an idea.
In my cultural background the thought of keeping someone's wallet is unthinkable. It's obviously and clearly immoral. You probably 'know the person' who lost it anyhow.
The oddest thing about making the transition from more agrarian/communitarian cultures to the more urban one's is how self-oriented everyone seems in the city (i.e. how people could possibly consider 'keeping wallets'), but doubly odd is how they are so cynical they can't fathom that there are groups of people for whom 'returning wallets' is normative and moral action, not something of note. And I'm not harping on 'city folk' (I am born and mostly raised urban), and there are many great things here, rather pointing out the agrarian/communitarian's perspective.
Tons of data to support the relationship between religion and low crime, but FYI I think they overstate it a little bit, if you look carefully you find again 'attendance' more of a predictor of low crime than even 'faith' for example. I think it's just as much about conscientious behavior.
My experience also. Every mainstream religion, afaik, defends honesty, sense of community, solidarity between people. More real faith - normally - means more attendance and the reason why attendance is such a good predictor of low crime.
That's a bit of a romantic view, those kind of communities ain't all roses either in my experience.
They breed a lot of narrow minded small thinking bigots, even if they do return wallets.
The idea we should as a society somehow return to a romantic past that never actually existed isn't a good one in my opinion. And we can't do that anyway because our understanding has changed.
Not that there aren't a lot of good things from the past that somehow got dropped by the wayside, there are.
It should be noted that programmers are not automating themselves out of programming jobs. They're automating themselves out of data entry, or testing, or any number of other mindless tasks easily done by computers.
We may not (yet) be able to automate ourselves out of programming jobs, but we can certainly leverage smart development practices into making the job a lot less labor-intensive.
I'm experiencing a shift in that thinking right now. I write reusable, modular, tested code. My co-workers don't. I use a project management system (Phabricator, on my own personal server, which I maintain); the company doesn't. For most of the last year, I've used these to produce more and better code than others have, but my responsibilities have only expanded while my pay hasn't.
I've vocally evangelized these practices and I'd love nothing more than to see them get adopted by the other developers, but so far it's not getting any traction.
So I'm shifting towards logging the value of the work I produce -- regardless of whether I'm just copying in a file from my extensive library -- rather than the time it took me to accomplish the task.
I hate to burst GP's bubble, but the attitude and environment at his next job probably won't be any better in regard to "best practices." It's extremely difficult to gauge how your attitude toward development compares with a prospective team's after an hour of chatting. I became a manager last year and quickly discovered that changing others' behavior and habits is next to impossible. And if he does happen to find a new team that matches his work ethic he can be certain that 1 or 2 years down the line it won't any longer.
I think the only two ways to avoid this is to become a contractor and switch gigs every 2 years, or start your own company and hope the people you hire share your attitude.
I've had very good luck changing the behavior of junior developers and moderate luck changing the behavior of mid level developers that are hungry for a promotion. I can count on my fingers (couldn't say if that's one hand or two) how many senior devs I've gotten to come around.
If you're interested in progress and growth, I can say with a high degree of certainty that what you don't want to do is apply to work on a very stable team. These people are always confident that they know what they're doing - even when they agree that the outcomes aren't great. They've had lots of time to practice their rationalizations and that kind of cognitive dissonance can be pretty jarring/aggravating.
By definition, starting your own company or contracting will avoid that situation, but you don't need to take your ball and go home just to get the right kind of environment.
I had senior people change habits and practices but at the expense of huge failures or years of leading by example. The patience and the effort are humongous and almost ridiculous when you compare them to how quarterly or even bi-quarterly planing cycles look.
Early in my career, the concept that someone might know of a showstopping problem and chose to do nothing left me appalled and feeling rather betrayed.
Fifteen years later I sit in meetings telling people (some of them still older than me) not to touch the stove because it will hurt, and I have to patiently wait until someone gets hurt before we can discuss the proverbial oven mitts.
The problem with doing something right the first time is nobody appreciates how hard it was.
> The problem with doing something right the first time is nobody appreciates how hard it was.
Sometimes if you do put in quality and do it right in development it costs you in time and then by perception.
When you hit the ship date over finishing the iteration/version/product you have problems after ship from external customers, when you do it right and handle the problem in development before ship, you take a hit in perception internally.
The problems after ship can harm a product/company more than a slight delay in shipping, but today it seems people don't care as much as there is more specialization and larger teams where it is 'not my problem'. Some clients/project managers see a bad product shipped on time as good, and a good product shipped late as always bad. The external perception should play more into that perception not just hitting their part of the project goals/milestones.
Hitting dates is hugely important, but messing up a product with the customer can be deeply problematic. Noone truly remembers a late product after it ships and is quality, creative and functional, they remember a bad product.
I prefer the Valve Time [1] philosophy, get the product right over the date, and don't set dates until you have the product actually ready.
As a non-developer, how can I hire someone (or a team) like OP that focuses on automating menial stuff and focuses on the most important?
Does a development agency that focuses on this model exist? Of course they should be paid more per hour (or other unit) than your average, less optimized agency, but the sum total should be less than hiring inefficient agencies.
(P.S. I understand the best developers probably don't want to start or work at development agencies, but assuming there are some.)
Body shops don't work like this. Their purpose is to put butts in seats, regardless of whether or not that butt is attached to anything else that is functional. Functioning in this manner would actually be counter-productive for them, because it would reduce the number of butts that they have to put into seats, and would reduce the number of seats into which they could put butts.
If you know of a development agency, odds are that it is probably a body shop.
The places that do work like this are more like Unicorns. And Unicorns are damned hard to find and hire -- or get hired by them.
Part of the problem is that to effectively automate a task or series of tasks you need to fully understand what is being done. The person currently doing this knows what they are doing (you would hope), and may understand why they are doing it (this is not guaranteed).
In many cases, what somebody does (and why) is not documented, or if it is the documentation is most likely out of date and inaccurate.
To effectively automate a task, you need to fully understand what needs to be done as well as have the skills to do the actual automation. Getting somebody in who is unfamiliar with the job, can work, but in most cases you will end up with an off the shelf system that has been customised to perform the original task but come with a large overhead of maintenance that may take more work than the original task.
My suggestion would be that rather than get an outsider to create the automation tools, up-skill and authorise the staff doing the work now to allow them to gradually automate the process. Make sure you make it worth their whiles to automate.
1) As person with business knowledge, vision, plan, etc, I should fully document the business goal and why we're doing it and what we're trying to achieve at the highest level, then work with the developer to figure out what should be developed to achieve that and where to automate.
2) Don't hire outside person or agency, but bring someone in full-time or as a part-time partner for the long term and incentivize them to get better and better?
I’d hope they all do. If you get an experienced developer they should want to automate all of this. My former boss took the model of improving processes and revenue, then taking a cut of the difference ongoing. He had financial freedom already, so this was the best use of his time. With some companies you aren’t given all of the information to make the right decision for efficiencies sake, or they write such a rigid spec there’s no room for improvement. Personally I love spending the time where I can see it saving so much time for the end. You might not need an agency, you might just need a developer to help write what you want to create and work a spec that you can give to an uncreative team/agency to create. Agencies make a decent amount on the discovery phase, so you’d be cutting that out. At that point you could go directly to someone that could implement it.
That's a great idea, will definitely try this out.
Seems to be a good idea to separate out the architecting from the actual implementation. Makes sense, because if someone knows they'll have to be implementing, it could cloud their plan for the ideal solution. Similar to separating out design, UX, and development roles.
Why would one need to become a contractor to switch gigs every 2 years? Seems like that’s the new normal with employers not wanting to invest in employees anymore.
Re: Modern web dev is fantastically more productive and efficient than it was 10 or 15 years ago.
I have to disagree. The esthetical expectations of the user/customer are higher now. If it's not "in style" they think you are sticking them with old tech. And you have the desktop/mobile split that frameworks only get half right and require days of black-box fiddling to get working right on all devices. And JavaScript gizmos often "break" as new browser versions or related components come out. It's almost as bad as the "DLL hell" that desktop applications used to face.
From a purely utility standpoint, I was much more productive back then because I only had to make it work and be easy to use, not "pretty" and animated with toys or the latest style fad.
Hmmm, I just tried to install emacs on windows. With all dependencies is 210meg! Tried installing vnc on Ubuntu following commonly found instructions. Required installing 119 packages (each of which is likely built from several libraries). I also tried building smb from source. It required tons of dependencies to be installed. Is npm actually any worse than any other environment?
> If it's not "in style" they think you are sticking them with old tech
Is that even true? Is there any survey showing that users consider those bad or old tech? Because with things like the reddit, ebay, paypal, gmail redesign, the common thing i ve noticed is that nobody asked for those.
That's just my experience. If a customer pays for a new gizmo, they want the "latest and greatest". If it doesn't look latest and greatest to them, they feel slighted. I'm not saying it's necessarily rational, only that it's the way customers on average react. They don't always say it directly, but word gets around. I've seen it many times. Humans judge books by covers.
As far as old-looking sites like Ebay, if an Ebay competitor appeared with equivalent services and product choices, yet LOOKED fancier/stylish, Ebay would start to lose customers. Lucky for Ebay, no such site exists. (If they appeared, Ebay would probably spend on a visual revamp.)
True, but it's hard to get new customers unless your "art" keeps up with the Joneses. A revised product is still usually more similar to the last version than another vendor's product such that existing users will usually stick around because a same-vendor overhaul is the least of two evils to them.
A lot of work that many programmers/coders do is not maintained and no one will use it after they leave the company. Not always but often enough for me to notice it. Every company has derelict projects that once had use or are still used but in a non maintained way. Like a Jenkins installation that everyone uses but no one has any clue how to modify.
Re: programmers are not automating themselves out of programming jobs. They're automating themselves out of data entry...
That's not always true. In at least 2 different organizations I worked at they were creating a combinatorial mess of search screens and/or reports.
Using a little bit of meta programming, query-by-example forms, data dictionaries, click-able drill-downs, and modular design; such "reporting stacks" could often be simplified into either a fewer number of screens and/or designed in such a way that a non-programming power user could configure most reports on their own. Allowing CSV exports of query results also reduces the number of "paper" report requests because Excel users can then format their own.
The result is something that needs roughly 1/3 as many programming hours to update and maintain.
One caveat is that you have to know the domain fairly well for it to be practical. You have to learn the domain patterns and habits in order to factor those patterns into meta-patterns. When I tried it as a newbie to the org, I usually did it wrong.
They do that to and have always done so. It's barely remarkable because it is expected and part of the job. The problem is you can't benefit from that, as soon as you automate one part, you are given other tasks.
I don't hand-create machine code. I don't write assembly.
I write in the highest-level language that still lets me fully specify everything I care about, and then all of the lower levels of code generation are completely automated. Programmers have always automated programming jobs as much as possible.
If you think about it, the existence of programming languages and compilers is due to programmers automating their jobs away. They no longer had to tediously translate higher level algorithms to machine code.
And really, the existence of computers is the result of automating the job of human computers away. The entire history of computer science is this.
The difference is that these guys hit a local maxima, and just ... stop. Instead of moving up to the next level and making more money.
> Instead of moving up to the next level and making more money.
That's assuming your employer will "move you up" and you'll make more money. Or that a future employer will see value in you automating your job. Then there's this story from TFA:
> a user posting as AcceptableLosses wrote, “They took what I had developed, replaced me with an idiot that they showed how to work it, and promptly fired me for ‘insubordination.’ I had taken a business asset that was making them $30 grand a year profit and turned it into a million dollar a year program for the company, and they fired me for it to save ~30 grand a year on my salary. Job creators my ass.”
Which sounds so entirely stupid as to be almost incredible. Why not just take this guy and move him, even sideways, to another role he can automate? But I believe him, because I've seen a lot of stupidity in Big Companies, especially the old school ones.
CS encompasses way more than automation. Graph theory, ADTs, complexity analysis (just by way of example) are all very relevant, even if the computation is done manually, by hand.
A lot of computer science presumes a very abstract computer; a human and a modern machine apply equally well.
That's been happening ever since the first computers. The first programmers hand-entered machine code, then someone automated that with an assembler. Then the first compiler automated much of the work in writing assembly code. Since then we've gotten ever more powerful languages, libraries, and all sorts of tools. None of this has reduced the demand for programmers.
Couldn't agree more, that doesn't mean it's always going to be the same. A lot of programming jobs these days are putting information from a database on a screen, then updating it in the database after it's been edited. Doesn't feel like that should be an impossible thing to automate in a fairly sophisticated way. Though that's been true for a long time and we don't seem to have made much progress.
I spent a lot of my career doing that. There was usually a fairly large gap between what made sense in relational database design, and what was convenient and sensible for users.
More importantly, "what is convenient for users" will frequently change and be expressed only vaguely by those users in natural language bug reports or feature requests. Converting that natural language into something machine-readable is programming, whether it involves typing cryptic strings into emacs or hooking together components graphically a la LabVIEW.
I remember that someone was considering making a program to automate a co-workers job, since it was just simple data entry. They never actually did it though.
I think the story of the Indian IT crisis is that good programmers have been automating them out of jobs. Good programmers in India are doing fine at modern tech companies there, but the code-monkeys at Infosys et. al. are struggling.
Exactly. Automate away the mundane tasks, so you can spend more time on the interesting tasks. In some regards, programmers are fortunate to have this ability; many careers do not have the skills to automate away the boring parts of their own jobs.
What about programmers automating other programmers out of jobs? My employer's core product line is designed in such a way that it can be configured for specific customers via an API. Much of that work is done by "operations developers." The complexity of their work varies based on the customer's needs. We are currently developing a designer tool that will allow the configuration to be developed via a graphical interface that will allow much of the work to be done by non-programmers (and eventually the customers themselves). As the tool matures, it will generate the code necessary to handle more complex requirements.
Those "operations" engineers can be moved to making sure Ops are running well at home (you apparently have an API) or into Technical Sales if they'd rather stay in the field. Informing the customer of all the configuration that is available to them, for example. Just because there's a nice graphical configuration tool, doesn't mean any clients are actually going to look at it when they have an issue. They'd much rather call you up and bitch about it. Operations guy's job is safe, but he might be able to address more customers than he could before.
Operations is a pure cost center. Cost centers only exist for the express purpose of being compressed twice as much this month as they were last month, so that you can make them half as expensive.
Developers are valuable. They create value.
When all the good Operations staff has left because they're tired of being treated like mushrooms, all the Operations stuff gets thrown over the wall and then the Developers get told that they are now DevOps.
That’s a really good point as it relates to costs between security and ops. My hunch would be downtime is your own business, but data and financial loss is everyone’s (either through liability, legislation, or insurance costs).
Think about the cottage industry of programmers who produce and maintain Wordpress websites for their clients. I think just like any other industry, there is need for products on many points of the [mass produced <--> bespoke] spectrum.
GeneXus™ streamlines application development by automatically generating everything from databases to code, frontend to backend, and server-side to client-side services. It’s not magic — just a smarter way to create smart technology.
Yes. In programming, laziness is a virtue. To some degree, so is the desire to work on interesting problems instead of boring problems. Those generally intersect to provide an enormous benefit to everyone.
As a sysadmin who started out replacing power supplies as a datacenter tech, and nowadays wrangles AWS auto-scaling groups, the idea of _not_ automating away the tedious parts of my job is pretty hilarious. I had one operations/support job where this was the case, and thankfully, I quit after one month.
If anyone out there has the gumption to cobble together a dev environment and automate away their BS job, yet can't get recognition from your employer; it is time to seek out a new job, you've certainly got the skills for something better!
That may be true in some cases like testing, build automation etc however when CS engineers are developing AI services and Bots, in the long run they will be automating programmers who used to do those things by hand. So Technology will eventually disrupt Coders as well and they will have to skill up or find a new job.
This article really highlights how odd our methods of valuing output are. Ultimately if someone is idling for 6 years because they've written a program to do their job for them, who cares? They are delivering the same output which hopefully the company deemed was valued at X amount BECAUSE it delivers Y amount of profit/returns. This article is actually touching on a deeper level of dysfunction in how we do things like calculating salaries for people. Instead of making things about how much value is created, we tend to tie things to "seniority" or "experience" in isolation. Just because the two are sometimes correlated with value produced it does not justify making that the measure on its own.
I remember going up to one of the senior management people in the company I worked at a long time ago and pointing out how I'd saved the company from having to spend salaries and other overheads on 12-20 more people by automation. If the salary for each person was X, I asked for a salary bump of 3X. They gave me a bump of only 0.5X . I eventually pushed it to 1X but that experience taught me that most of the time, extra value you deliver rarely flows back to you in a reasonable way.
And from that point on, I stopped treating my job as an extension of my identity or fulfillment of purpose. It became a place where I primarily had a cold hard contract to deliver X value in exchange for Y returns. And if I was ever to work again in a company with similar opaque practices on salaries, any increase in Y returns would be best negotiated before showing my entire hand on how much I could increase the delivery on value X.
> If the salary for each person was X, I asked for a salary bump of 3X [and they didn't]. ... And from that point on, I stopped treating my job as an extension of my identity or fulfillment of purpose.
Indeed, the best work is done when you do it for yourself. People basically sign their brains away when they go to work for Facebook and Google. Those companies will be likely to get B players no matter how many seemingly great people they hire. The 4.0 MIT grad who can recite chapters from his CS401 class isn't necessarily an A player. Most of the A players I know are either ex-Facebook/ex-Google or turned down working at those places because they have more important things to do with their time.
The real A players are much harder to find and are much harder to value. Without ownership in what you do, there is a high probability that you will not be at your best. If you need to be paid to do something, it is unlikely to be what fulfills you.
> They are delivering the same output which hopefully the company deemed was valued at X amount BECAUSE it delivers Y amount of profit/returns.
The output is actually even better in my experience. I know in the tasks that we've automated the output is always 100% consistent, which is more than can be said for the previous human output.
Also there's a lot of value in having someone on hand who actually understands the process rather than blindly trusting in a script. They'll more than pay for themselves when it comes to future enhancements or debugging.
And I say all of this as an employer - my employees are positively encouraged to automate as much as possible.
An important thing to realize is that you are not paid based on the value you added during the year. You are paid to make sure you do not leave (for a competitor).
I think in the long run, acting in the best interest of the business when you are employed for that business would result in superior income/career than doing otherwise.
Another option is finding possibilities for automation that could apply to other companies with similar problems, and starting a separate company selling such automation services. A consultancy could work, too.
> This article really highlights how odd our methods of valuing output are. Ultimately if someone is idling for 6 years because they've written a program to do their job for them, who cares? They are delivering the same output which hopefully the company deemed was valued at X amount BECAUSE it delivers Y amount of profit/returns.
Their boss cares. This is capitalism, and capitalist ethics say you should be fired if you're idling and not continuing to actively labor for the boss anymore. She's not getting anything in return for your salary. You more than likely signed away all rights to the fruits of your labor when you took the job. That means "your" automation is really your boss's capital, and you have no rights to be perpetually compensated for it.
So, if you ever automate your own job, don't tell anyone. Also make sure to make your automation so arcane and impenetrable that no one else can hope to use it.
> This is capitalism, and capitalist ethics say...
Wrong. Capitalism has no ethics. The only 'ethic' it may have is "Make money and resources". Humans are secondary. Ethics are secondary. The environment/public commons is secondary. Even the laws are secondary, given the fine is less than the gain.
I think it means that your job should then become automating aspects of the business, then maintaining these automations. Your labour becomes automating.
> I think it means that your job should then become automating aspects of the business, then maintaining these automations. Your labour becomes automating.
More realistically: as a laborer, you shouldn't put in extra effort to automate your job away, because the benefits will likely be kept from you, for the most part. They might throw you a bone as a reward, but a bones are leftovers. They'll keep the meat for themselves. This kind of automation is properly understood as a kind of charity for the people who need it least.
The appeal of automating away your job is the freedom it seems to bring to the automator, but that's an illusion. You'll remain a laborer until you're put in a position to go live under a bridge, which is a freedom you've always had.
If you want to openly automate away your job, you want to be a software engineer. At a minimum, negotiate a software engineer's salary from you employer before you start that work. However, if you can manage it, it's better for you to start a company to license the automation back in perpetuity.
> This article really highlights how odd our methods of valuing output are. Ultimately if someone is idling for 6 years because they've written a program to do their job for them, who cares? They are delivering the same output which hopefully the company deemed was valued at X amount BECAUSE it delivers Y amount of profit/returns.
This is why, in 19th century, they've used to call wage labor, as opposed to self-employment, "wage slavery".
You are selling your time, not the goods you produce.
At some level of understanding, all workers know they don't get the full value of their labor. You just got to see it happen right in front of you in real time.
This is related to Taleb's observation that employment is a kind of "slavery". What he means by this is that you effectively have sold your option to own those to outsized returns in exchange for a regular paycheck.
That's... not what slavery is. That analogy is extremely poor compared to using securities derivatives, which is a field Taleb is familiar with.
Edit: also, is this feature of salaried employment so misunderstood as to require an analogy? You get paid a fixed amount, or with specified bonus structure. It's literally the number one fact people know about their employment contracts.
> also, is this feature of salaried employment so misunderstood as to require an analogy?
I would argue yes. Many professionals like engineers and programmers can point to contributions they made to the corporation that have been sold for many times their annual salary. How many of those professionals consider the fact that they could have sold their design for themselves and pocketed the revenue?
This is related to Coase's question: why have a firm in the first place? In modern times it seems that ongoing disaggregation of businesses and reduced transaction costs in software would cause more professionals to consider working for themselves, rather than selling their (potential, uncertain, unlimited) profits for a (certain, fixed) income.
That sounds more like an option pair for an equity. Both your upside and downside are limited and you get a steady income stream. Slavery is very different.
Except, is your downside really limited? It's true the company must make payroll while you are still employed. However, the employer has the option of firing you. While this might not put in you in debt to the employer's creditors, it does reduce the value of your employment contract to zero AND reduces your attractiveness to future employers.
If you only have had one employer for a long period, this is a large blow. Taleb makes the point that the taxi driver is in an enviable position compared to the salaryman for this reason.
Your downside is limited to being laid off, so it is limited. They can't go after your personal assets if the company goes bankrupt, or claw back past wages.
And a couple of tangential points: 1) Being laid off because your company went under is not a bad black mark on your resume. 2) You have the freedom to terminate your employment at any time just like the company can. That's very different from slavery.
There are similarities. They are certainly both critical of business. Taleb has a strong allergy toward anyone who appears to be abusing their position of public trust to swing economic rents towards themselves or allies.
Why did you ask just for a 3X increase instead of 12-20X?
If you don't value what you did, why should your employer?
Also, why should an employer raise your salary based on the fact you are automating stuff? It's part of your job, after all. That's what programming is about.
The essence of this question is worth talking about.
To clarify something first, this was not a programming job. I was managing a team of content uploaders for an e-commerce company. I used software in multiple ways to keep the team at the same size when my original brief was to simplify the process so much that they could hire more people at cheap rates to do the work. So I went above and beyond the brief. The job was so simple they didn't need to hire anyone anyway.
The question of why 3X is to do with alignment of interests. I can't offer savings of 20X and ask for that to be added to my salary. Yes I'm creating that value, but we also want to increase profits. If I ask for all the savings, then what makes my solution worth it? Calculating our business margins at the time I came to the conclusion of 15% of the savings to come to me to be worth it given the extra business our team was able to handle due to the automation.
Lesson here is how to calculate your ask. My team unit with 20 extra people meant the new work being brought in would be coming in with no profit. The team (without extras) was just breaking even at the time by my calculations. The profits made by automating to accept new business at an accelerated rate was above our usual margins (I think it was about 45%). My ask lowered it but it was still above the company's expected margins on business.
My mistake though was that the automation was nearly infinitely scalable. I showed my entire hand and me leaving wouldn't necessarily burn anyone. 6 years since I left, at least two of the tools are still running. Twas a great lesson on negotiation and leverage. Live and learn :)
If you're coding for a non-technical business, i.e. one in which they're not directly selling your productive output, then it's not hard at all to get to a point where your daily tasks don't take more than a few minutes a day. After all, it's other people that are actually driving the revenue. You can ask for more duties, but their capacity to define tasks for you is never going to outpace your ability to deliver.
My advice is to not fight this state of affairs. Figure out your own way to stay productive. Divide up your spare time between coming up with ideas for your employer and doing side projects. Take long lunches with your coworkers and leave at 4.
You can find happy professional nirvana but you have to believe in it first.
The key for this type of setup is to make sure that they understand your job is like that of a security guard. You're there for when all your carefully coded alarms start going off. You're not there to help shovel the sidewalk because then you might miss your alarms.
As long as that is properly understood you can get a contract that is permissive enough to allow you to work on something else at work when nothing is burning. Even if you have to offer a reduced salary, it's worth it.
Another option is to go the work on OSS route, especially on tools you use for work. After a couple years of doing semi-fulltime OS work you'll be commanding double the salary.
The key to this, and I meant to edit this into my comment, is to be super-responsive to any requests. Always be willing to drop whatever you're doing at a second's notice and help whoever it is that thinks you might be able to help them out. The word gets out and everyone in the company just loves you.
imho a great sweet spot is turning most of that free time into learning new skills. It's fun, productive, and not frowned upon, even if the class has nothing to do with the current job.
As a former trader/developer/quant I often felt that "automating myself out of a job" was my goal. If we could build properly architected systems that were self-healing when things went wrong, turned themselves on before the market opened, traded all day, made money and shut down for the night... then eventually my role would devolve into monitoring and ultimately into nothing...
In practise, achieving some sort of "steady state" or status-quo doesn't work for a few reasons:
1. Inherent system complexity ensures something always breaks. Human attention is always needed.
2. Markets evolve rapidly due to technology changes, regulatory changes and the very nature of markets: Strategies and ideas that worked in the past cease to work in the future.
A system that requires no outside intervention to perform its job optimally is equivalent to a solved problem. So quants will be out of a job once we understand how to perfectly trade on the stock market.
I disagree, the solution to remove stock market traders is to figure out a way to examine financial data and projections to such a fine degree that stock trading is no longer a sensible thing. Imagine a currency trader focused on USD & CAD, what would happen to their job if Canada decided to permanently pin their currency on the USD with a guaranteed exchange of .5 USD for 1 CAD, the markets surrounding arbitraging the currency would dissolve as .5 USD would always be 1 CAD (now in the real world there might be stability speculators, if Canada was viewed as politically unstable there might be a purpose to purchase .4 USD for 1 CAD, but ignore that for the purpose of the scenario).
Well, you are making quite a lot of assumptions here:
- currency is very different from equities - while one could argue that a central bank deciding to peg it's currency to $ is a realistic scenario, it simply doesn't make sense for equities (an equity is basically a right for present and future earnings of a company - good luck 'perfectly' predicting that !)
- as you note, there would still be speculators, since there is always uncertainty. There are numerous examples of countries pegging their currencies and then when unexpected happens...
- traders / sales would still compete for order flow of the clients (and get the cut), so there would still be a game to be played albeit for smaller margins
To name just a tiny fraction of things that'd be required for a perfect stalemate between automated stock trading platforms (due to them all being able to predict the market with perfect accuracy):
* actions of any given platform doesn't meaningfully influence the market
* all have ability to forecast weather with 100% accuracy
* all have ability to perfectly predict human behavior
* all acquire the exact same news at the exact same rate
* all connect to the same exchanges with the same latency
* all have the same amount of capital to leverage trades
Simply put, there are incalculable ways for a trading platform to gain advantage over another, so I don't think this will be an issue in many lifetimes.
>> * actions of any given platform doesn't meaningfully influence the market
Yes - this... Buying or selling even 1 share in the markets adds information to this giant calculating engine. Anything you do will alter the course of the future.
I've never seen a backtested strategy that didn't look great on paper. The moment you drop it into the market - you can take a steep discount to your expectations.
I have the same feeling that "automating myself out of a job" is the goal. Personally, I can't imagine anything else because it always feels incomplete (sometimes even dishonest).
And the beauty of being a trader/quant is that once you come up with such an automation, you will capture a lot of the upside as the company will not want to have you leave for a competitor and implement a similar strategy there.
Hi! I am a co-founder @ KloudTrader. The get started buttons don't work because we haven't launched yet. And the list under "What does Narwhal offer" are not links, they are just a list of features. Anyway we are launching this week, we would love if you could signup for our early access list(https://www.kloudtrader.com/#getnotified). We will notify you as we launch. Cheers!
> Wary self-automators, he speculates, “don’t trust our workplaces. The boss is going to say thank you, good work, now do it again.”
Well, no shit. That is what the job of a programmer is - to keep automating things.
There are an INFINITE number of useful things we need to do as a society, so we shouldn't be upset if we automate one of them away. Move on to the next.
Of course, programmers should make sure they negotiate strongly to get compensated fairly for the work. I think it is a bit short sighted, however, to worry that you will end up like the guy who automated his job and was then fired and replaced by a lower skilled guy - who cares, you SHOULD move on at that point if the company doesn't want you to automate something else. There are plenty of companies that will hire you, and you can use the example of the previous company to show you can do it. This time, negotiate better compensation.
> Well, no shit. That is what the job of a programmer is - to keep automating things.
I think that many of these scenarios are occurring when NON-programmers realize that their jobs are automate-able and they set out to automate them. It means picking up new skills, practicing them and putting them to use without the consent nor permission of management.
It is not necessarily an easy path, it takes time, and there's going to be trial and error involved and although the discussion is about automating 100% of a job away, there's many other possible outcomes such as effort-multiplication, getting rid of the grunt work and gaining more time to focus on deeper problems.
This is effectively "out-of-band" work that is a great experience for the individual but which _many_ organizations do not condone. A LOT of workplaces don't tolerate workers doing stuff that they're not being "told" to do.
> Or they fire you because they don't need you anymore.
This is the kind of ridiculous thinking I'm talking about in my other comment. You just made your job into a cheap, automated process. That's the most valuable thing you could do in a company! If you did that in my company, you'd get a promotion and you'd be put to work finding other things to automate. You're the kind of person every company wants! Why would we fire you? If we're dumb enough to fire someone like you, you're better off at another company anyway.
If companies were run in a logical manner, then your thought process would be reasonable.
Sadly, while there may be some logical people in a company, many companies (most?) wind up not being run in a logical manner due to a wide variety of internal politics and societal issues.
What you hope (and pray for) is that the logical people in a company are not also sociopaths, in which case you are really well and truly screwed.
That's crazy, I don't understand how people are so negative about this. Sociopaths will NOT fire that person, they'd put that person to work automating other jobs. This is just how you run a business.
> Or they fire you because they don't need you anymore.
I think people are just assuming that the typical case here is someone automating their job to a degree where they literally don't have to do anything. I suppose that happens sometimes if we are to believe anonymous reddit and stackexchange postings.
What actually happens is that regular people who you would not assume are "programmers" start picking up computer skills and employ them in a piecemeal fashion a little bit at a time until eventually their day-to-day work becomes something quite different from when they started out.
This has been going on for at least as long as there has been a computer on every desk. I think "software engineers" should not be so smug to think that everything worth doing is something that they're going to get a chance bid on and then get a project managers or scrum teams to implement.
As for whether the person that does this gets fired or promoted depends on their skills at managing their peers and superiors, and what kind of environment they work in.
I've told this story a few times and I always get surprisingly diverse reactions to it, especially on Reddit.
Back in the late 90s I worked at a place that sold all kinds of automotive parts. Everything from nuts and spark plugs to turbochargers and large assemblies. The secret sauce of this company was a small team of people who worked through thick supplier (paper) catalogs and figured out which parts from different suppliers are in fact interchangable by comparing their specifications. This all went into the database for the sales team's use.
Well one younger guy in this team worked out a way to largely automate his job using OCR and spreadsheets. Instead of taking 8 hours to work through his day's load, he would do it all in an hour or two. Then he'd slack off for the rest of the day.
Soon the manager found out but the manager was not upset, instead the manager was disappointed. Why didn't this employee share this system with the others? Why did he think it was OK to slack off for 6 hours a day instead of doing 4 times as many catalogs? If this employee worked for me, I'd be putting him to work finding other things to automate!
In the past I've had many comments from people saying 'oh he should have kept it a secret' or 'he is getting paid to do X and if he is more efficient then why cant he slack off' or even 'oh no this is a disaster now most of that team will be laid off'
>Why didn't this employee share this system with the others?
Because the consequences of him doing that are unclear. And since one potential (if not likely) consequence is management would simply retain 1/4 of staff doing this work and fire the rest, why would he share that?
Was there a huge sign at his workplace outlining the consequences of automating anything? An explicit policy that would alleviate such (reasonable - read the article!) fears? I don't think so either.
What was clear, presumably, is that as long as he processed X catalogs a day, he was getting his salary paid. That was what he was hired to do. And so that was exactly what he was doing.
>Why did he think it was OK to slack off for 6 hours a day instead of doing 4 times as many catalogs?
Because this is how work works. You pay someone to do something, and the expectations on the amount and kind of work - and the amount and kind of compensation - are discussed in advance.
>If this employee worked for me, I'd be putting him to work finding other things to automate!
Yes, and that's exactly the problem.
What if there aren't any? What if there are, but he doesn't find them? What if he finds them, but doesn't know how to automate the task? He was hired to go trough books and compare specs, automating his employer's business was literally not his job.
You see, your "reward" is not paying the employee 4X salary for being 4X efficient (you left that little part out!). Your reward is making the employee perform a more difficult job that they didn't sign up to do, presumably for the same salary (since you didn't mention paying them more).
If someone with this attitude worked for me, I'd get rid of them ASAP. We don't want people sitting around saying 'thats not my job' or 'I'm not going to look for ways to do things in a better way' or 'I wasnt hired for that'
Our company culture is the complete opposite of that. We want people to help each other. We want people to challenge how things are done. We want to change things all the time, experiment, see what works.
I have NEVER hired someone and said 'heres exactly what you need to do for 8 hours, have at it'. Not even close. All businesses must move forward, lest they die in the dust. The old cushy 9-5 job where you just do the same thing over and over your whole career is dying out quickly.
Any potential employee of your company will be asking "what's in it for me"? Do you pay well above market wage to make this extra effort worthwhile? If I automate or eliminate a lot of work how am I compensated for that extra effort?
Every company says they want people like you describe but few actually put the incentives in place.
Well people don't usually like or want to work for little dictators which fire people on a whim for minor things.
So your employees (assuming you have any and this is not some hypothetical scenario) won't straight out say those things, they will just quietly do them :)
Just to be clear, I've certainly never fired someone on a whim and in fact I can't even remember the last time I actually had to fire someone. Probably at least 5 years.
But we do try really hard to hire people that fit in our culture, and we make sure new employees understand how we work. If someone's just sitting there doing their assigned job as they were trained, they'd be fine but they would probably not get promoted or earn a pay raise every year.
And of course if someone DID need to go because we lost some clients or whatever, those are the ones we'd want to let go first.
This is race to the bottom behavior which we largely got away from him post industrial revolution. It's well and good to want employees who are passionate about their jobs, but no one is passionate 100% of the time. The rest of the time, they're going through the motions of pretending to be so they don't get fired. We know this leads to bad results for society in the long run. Mass burnout isn't good for anyone. Which is why we have (mostly cultural) enforced limits on what employers are "allowed" to expect from their employees (like a 9 to 5.) No one has the energy to go above and beyond 100% of the time, and honestly expecting them to do so is delusional. Of course it's beneficial for individual companies to find ways to compel their employees to work more (whether it's "culture" or otherwise,) but it's very bad for the "system" if everyone is doing it. People need to have time to spend money and engage in meaningful leisure to keep the economy spinning.
The only real exception is employees who are really committed to the vision of the company. Ultimately though that's usually only the executive team and early hires since they're the only ones who (usually) materially share in the actual success of the vision beyond just keeping their job. Most of your frontline employees are not going to get any benefit from sacrificing their energy (and there is a real cost to this) and time to fulfill a vision they don't even really contribute to forming, besides just keeping their job. The incentives just aren't usually there. Furthermore, It's common for founders to be very deluded about how "laudable" the vision for their company is. There are very few companies that act as clearly morally good agents in the world. It's not a given that profit-seeking entities inherently behave in a way that's ethical. I just don't see how anyone could possibly expect employees to be 100% committed to executing on the vision of most b2b or even consumer facing businesses. Especially when they don't really reap the benefits of company success.
And yeah, you can argue that you're buying someone's time and you're entitled to expect 100% of their mental capacity etc... during that time. But like anything else in capitalism, you get what you pay for. There are plenty of other employers that don't expect that or don't have the time/resources/collective IQ to determine that you've automated, and I don't see why your employees wouldn't just go work somewhere where they can get away with doing 1/4 of the work for the same salary vis a vis automation unless you provide some extraordinary benefit just for being a "member" of your company. And if being challenged is important to the employee in question (I'm one of these) I'd just go find a job that pays 4x (or make my own) where I could be challenged. In general, you can't eat a corporate vision and it's just not that valuable for most workers (there really are exceptions, companies that are clearly "morally good", but that's the exception and not the rule.)
Which isn't to say it's fun to work at a place where people are just jumping through their daily assigned hoops. But speaking as an employee, I'm certainly not willing to put in extra effort at a company paying at or below market rate with bland corporate vision/culture and/or uninteresting problems. Which seems to be the expectation of most employers. I'm lucky to work at a company where even though I'm ambivalent about moral character of the product (it's b2b stuff, so morally neutral,) I'm well compensated and enjoy a flexible corporate culture and have interesting technical problems to solve. Ultimately though, most companies are bland (in terms of vision) somewhere on the scale of utterly toxic to tolerable (in terms of culture) and totally boring (in terms of the nature of the work.) If you're not paying above market rate in these situations, it's completely absurd to expect employees to give anything "extra." Speaking from experience, most founders/CEOs are completely deluding themselves about how many of the boxes on compensation/culture/vision/interest their company is checking.
>Our company culture is the complete opposite of that. We want people to help each other. We want people to challenge how things are done. We want to change things all the time, experiment, see what works.
OK, so you are explicitly making this a part of the job description. Which, arguably, was not the case for that particular employee at that particular job.
>If someone with this attitude worked for me, I'd get rid of them ASAP.
When people are "got rid of ASAP" for their attitude and not due to their performance, that's more than reason enough to keep silent about, well, everything.
Because who knows what kind of attitude the boss might have on that day, or seek from their employees.
----------------------------------
Everything below is skippable
----------------------------------
Now on the me-note: in my current job, I do my best to automate and document processes to save my and my co-workers' time. But, unlike in the case above, that's my job as a software engineer. And I know that when I make things better, I am rewarded - either with a thank-you, a bonus, or joy from improving my own work flow. I don't have to fear being reprimanded or fired for that.
In my previous job, which was a Teaching Assistantship, I went over and beyond trying to improve things (I rewrote the lab assignments that everyone hated, and turned them into something useful and enjoyable) - and got hit with a plain, literal, "it's not your job" from the administration when trying to push these changes. Initiative was unwelcome there.
The moral? I've seen both sides. If you are the manager, it's on you. You create the environment where people will be either eager to be improving things, or will be scared to try (and will keep mum if they do).
>All businesses must move forward, lest they die in the dust.
And so do the employees.
>The old cushy 9-5 job where you just do the same thing over and over your whole career is dying out quickly.
Indeed, and that's why people move on to other jobs. I think the puzzle will solve itself once you put yourself in the shoes of the person your story was about.
>We don't want people sitting around saying ... 'I wasnt hired for that'
But surely you hire people for something? I hope you don't expect your software engineers to, say, clean toilets - and vice versa. And if you do, I hope you pay your cleaning staff as much as you pay your engineers.
Which, again, was not the case in the story you posted (the person doing the automation was neither expected to do it, nor was paid at the level that people whose job it is are).
You're really hung up about this 'not in the job description' thing. If you see a small fire in the cubicle next door, I guess you'll just ignore it cause putting out fires wasn't in the job description. Neither is looking out for fires and reporting it, so just let it burn.
You won't last the probation period working with us, thank god for that. I'd hate to be in an office full of people who only does what's in their job descriptions and never anything else. We hire people who care about each other and help each other in difficult periods. That's one of the reasons our employee retention is so high.
EDIT: If I thought that cleaning a toilet was for some reason the most valuable thing I could do for the company right now, I would do it.
I'd bet many employees would be happy to work an hour or two per week. I'd be few employers would be happy to have employees work that little. It's not just a fear of being fired. It's a fear of the managerial mindset of "if they can do more each week, they aren't being challenged enough."
That is a larger societal question, though - how long should you be able to live off work you do? Is it fair for a worker to work for a few weeks, automating a job that used to be paid year after year, and then earn that money forever?
Obviously there is a balance - a company shouldn't get ALL that savings (although in the long run, that savings would need to be passed on to customers, since competitors will also be able to automate the same tasks).
At the same time, I don't think it is fair (or sustainable as a society), to expect to live forever off of work you did over a few weeks (no matter how valuable that work might be).
If we allow people who automate things to live off the work of that automation FOREVER, then we are creating that sort of distopia that anti-technology people claim; that WOULD be taking jobs, because ALL of the benefit for the automation would be going to the automater and none to society. Society would still be paying the same amount for the resource, it would just all be going to the person who made it.
Obviously, it shouldn't all go to a company either, but if ALL (or many) companies in the same field also automate, they will HAVE to pass on the savings to customers to compete. This will provide a net gain to society, since the resource is now cheaper for everyone (at the cost of the people who used to do the job).
The cost decreasing with automation is REQUIRED to make it a net positive for society, and the automater taking all the rewards for the automation in perpetuity ruins that.
Society already accepts that though. Look at copyright or patent law, if you tried to do away with it you'll have protests in the streets, regardless of the societal benefits to tearing down those rent-seeking laws
Take the complexities of society out of the picture for a moment and reduce the scenario to a family unit living on subsistence farming with nobody else around: if the family is somehow able to automate their food, water, shelter and energy needs, are they entitled to live forever on that work?
It's a great question a but obviously the catch is in "nobody else around" - morality only really comes into play when humans interact with one another.
In perhaps the simplest possible example, they live on land that belongs to a country that defends and otherwise manages it. In that case, paying a basic land tax should be enough. If there are other interactions between the family unit and its society, then other arrangements might need to come into play to allow them to maintain the entitlement for that lifestyle.
Right, but that is not what is happening here. Other people are still working full time to provide the things he needs; food, energy, entertainment, etc.
In return, he is giving the output of something he worked a few weeks on.
In your example, it would be like the son invented a machine to do HIS chores for him, but then sat around while the rest of the family still did their work
That's a great example. At that point, it's up to the family and the son to negotiate what's acceptable. Ultimately, whatever arrangement they choose, the family unit benefits.
I think where this analogy breaks down and becomes gray area in modern society is when the group unit that benefits gets too large to ascertain where the gains are accruing.
We're biologically wired to optimally deal with groups of ~150 or fewer people.
" I think it is a bit short sighted, however, to worry that you will end up like the guy who automated his job and was then fired and replaced by a lower skilled guy - who cares, you SHOULD move on at that point if the company doesn't want you to automate something else"
Yeah, but that person still has to feed and house their family. And in some areas there are "plenty of companies", but not in all.
This reminds me of Toyota, which (allegedly) never let anyone off after process improvements, because that would undermine the trust which is necessary for employees to feel safe when suggesting improvements.
These stories seem to me like management failures — leaders haven’t built the necessary trust.
It's interesting how people expect workers to "earn" their salaries through suffering. It's almost religious. At the same time, lots of businesses charge their clients a percentage of their earnings and it's ok.
David Graeber in Bullshit Jobs, says people have been conditioned to insist that you can't be productive without suffering in the process, and he goes on to makes a case for Universal Income (because modern society is productive enough to feed and house everyone). I think it misses the point. People want a job where they grow as human beings, and you can't grow without suffering/trial. Pointless jobs are depressing. If you figure out how to get paid without doing anymore work, that's cool, but then what are you going to do? If you want to grow and make society a better place, it's better to find something else to do, either with the same company or somewhere better that isn't so dysfunctional.
I think your observation can coexist with Graeber's take. If you implemented a UBI, it seems reasonable to expect that most people would take the opportunity to take on some kind of "work" or self-development that is not tied to how they meet their basic needs.
Unless they got you on that non-compete for 2-3+ years on that 6 month contract, at that point you are their value and everything you brought was theirs, nevermind they might not have had the value if you hadn't brought/created it.
I read an interesting book (somewhere in my library if you're interested) that took a different view on work ; one of the preliminary discussions was about the famed ethymology of the word "travail". The author made it go back to the immobilization of a horse in a cage when changing its horseshoes, or the immobilization of a woman in her "travail" of giving birth. It's the fact that we are taken by a task, preventing us to do anything else on a whim. In that much more neutral sense, you can view work as anything you choose to be busy with.
The employer is paying you for the product, not the effort. I see no moral quandary here, nor any compulsion to notify the employer. They're getting what they want, that should be the end of it.
EDIT: And I would add, for anyone that has automated their job in this way...what you should really be doing is scaling it up, and finding other companies who are probably paying employees to do the same thing. Then start your own company that does whatever this task is as a service.
>and finding other companies who are probably paying employees to do the same thing. Then start your own company that does whatever this task is as a service.
Careful, if it gets out that you wrote the code to automate your job as a coder while actually at your job, your company most likely owns that IP.
True, though presumably if you have an automatable job, you're not actually employed as a programmer and as such may not have a clause like that in your employment agreement.
You probably do. IP assignment is boilerplate. I had it in my contracts at Ross (the discount clothing store), Radioshack, and a local cheesesteak joint between 2012 and 2015.
I am still in academics so I have a question about this. If your company owns this is, what shouldn't they be rewarding you generously for making it? They are making money out of your extra effort/work. I get that employees who want their own ip should have the right but if the company is paying you extra and giving other rewards and removing the headache of managing your own company, is that not good?
shouldn't they be rewarding you generously for making it?
Yes, in theory.
In practice, an employee's power to negotiate wages is limited. At some point, the employee just needs to work to eat/pay rent/etc.
Now, in most areas (of the US), software developers already are paid generously. Even in lower paying secondary markets, software dev are usually paid significantly above local averages.
And, anecdotally, that pay is often for a much "easier" job, where "easier" means less stress and fewer hours than professions that generate similar salaries (engineering, accounting come to mind).
Only if your employment agreement says so. Most people hired as programmers, yes, that's true. People who are hired as other things, and end up automating things, well, that's not so clear.
> for anyone that has automated their job in this way...what you should really be doing is scaling it up, and finding other companies who are probably paying employees to do the same thing. Then start your own company that does whatever this task is as a service.
These tasks might not be worth selling as a service, they could be relatively trivial yet very context specific... I suspect this is the case, and that the real issue is with the employers lacking the insight to realise the these tasks _should_ have been automated and have the initiative to do so as soon as possible.
More specifically they probably neglected to employ people between the grunt worker and executive positions that would _have_ the insight to automate these tasks as soon as possible. That's basically corner cutting in terms of employees, in which case perhaps they deserve to be exploited, the funds are correctly being appropriated to the people who realised they needed to be automated.
EDIT: to be clear I don't find it 100% morally acceptable, going behind the employer like this is underhanded of course, but it can be somewhat justified as I outlined above. I suppose the alternative is to explain to the employer how it should be done and do so and hope to gain some kind of promotion or compensation, but that entirely depends on the moral standards of that company.
Maybe we both have loose morals but I don't see it as cheating the employer anymore than one "cheats" an employer by driving to work instead of walking.
I'd say it's that driving is easier for you, but they get the same result - you attend as necessary. They shouldn't care how you get there as long as you do your job.
I completely disagree with your first point, and agree with your second with caveats. The employer is usually not paying the employee for "the product"; they're usually paying for the employee's time and general ability. You can see this simply by the fact that most employees are explicitly paid a rate per hour/day/year and not something closer to a piecework basis. Differences in productivity don't effect the pay rate nor does the estimated value of the product. Employees don't work on a "fixed fee basis" on their assignments and for maintenance like work their pay doesn't fluctuate downward when the value of their product diminishes nor upwards when it increases. The product is a consequence of how the employee is directed to spend their time. If the trade is something else, it should be clearly stated in the employment agreement/contract that they employee is paid on some other basis. Unilaterally recasting the terms of your employment into some other basis is merely rationalizing not providing the real thing for which you're being paid.
For those that might say that a job description sets product based terms for employment, it's rare that they are offered that way. Almost all the job descriptions that I've ever seen (and all that I've written) have some sort of phrase to the effect of, "...and other work as might be assigned." A job description isn't a Statement of Work, they're usually just general expectation setting devices.
The employer chooses what he wants to pay for, unfortunately. Some employers will feel like doing this is a breach of trust, and some will use it as a base for firing, and some might even call it theft and press charges.
I wonder if management would be happier if you said "I'm going to quit and be a consultant, our company will do my current role for 80% of what you're currently paying me."
?
Not only does that release you from the unnecessary expense of going to work, it frees the company some space and employment expenses too. They save money on getting the task completed, so that can be labelled as a management win "we outsourced and saved with no drop in quality".
In addition you are free to do the same for other businesses. Or indeed to sell extra seats of your solution and put your former colleagues out of work.
It is a smart decision, but still it's better to build something solid before you start consulting: an online presence, a blog, a podcast, network of people who know you, etc. So that your former employer is not your only source on consulting gigs.
But even then, most companies would refuse, because it means they have to contact their legal department to draft a contract, and change their workflow to accomodate for you, an external entity. I've seen people transition from employees to consultants for one company, it was very smooth though. It's just that some companies would have a kneejerk reaction of "errr, dude, listen, whatever, man, just if you're leaving, then you're leaving, if not, then not, this consulting stuff, I don't think anybody would approve of, so no, either you stay as you are, or leave, sorry." Because they don't think it's important, they don't value you, and don't really care, so by becoming a consultant you're presenting a problem and additional work for them, they would rather avoid it, especially if avoiding it is the easiest thing to do - nothing. HR will find somebody to replace you.
Or it may work out how you described, especially if you sell it to them with charisma and good vibes.
A few years ago I was working for a QA department and trying to apply my programming skills wherever I could. There was a weekly report that someone in upper management produced to send to their peers, which was basically two filtered and cross referenced CSV dumps. I briefly took over that task while the manager was away, and was able to automate it pretty easily. I even produced a small GUI that made it easy for the manager to use later. Ultimately the manager chose to keep doing it by hand for 40 hours per week. I left that organisation a few months later.
This can be good when companies and incentive structures are set up to reward it. The entire concept at the core of SRE is "if you have skilled engineers do your ops work, they'll automate as much as possible, freeing up their time to work on bigger and more interesting problems". At Google, automating a huge swath of your own job is one of the fastest ways for an SRE to get promoted.
These days I'm much more inclined to automate my own job than someone else's. It seems many of the times I've taken extra steps to more fully automate other people's tasks, it's had the adverse effect of alerting them that even further automation is possible and they inevitably ask, "why can't you just automate the whole thing?" I then proceed to spend about 7 minutes frustrated and determined to automate their entire job away before cooling down and simply adding them to my list of "non-client people who think I should work hard so they can be lazy."
This is a common situation that I've been in several times before, even up to the point of automating the automating.
I had one particularly nasty supervisor who gave me a project, then asked me how long it would take to program, then without fail tell me that was unacceptably slow, then tell me that my predecessor could have done it in half the time, and finally question my competence.
So one day he brings me a short programming project that previously took anywhere from say 2-3 hours, asks me how long it will take to program, and I respond with, "30 seconds". He then replies, "That's too long. So and so could have done it in 15... wait, what did you say?"
I've mostly or completely automated several of my own jobs, and when done with that, proceeded to reduce my co-workers' work load. Usually it does not end well. Either someone higher up in the organization will perceive the automation as wasting time (still can't wrap my head around that), think of you as now redundant, or see little reason to offer additional compensation while moving you into a new position that does nothing but automate. After all, if you were willing to automate in the previous position at the previous level of compensation, why should they have to pay you more now?
He wasn't able to successfully pull this stunt ever again. It actually completely changed our work dynamic and almost completely eliminated job stress. It was also the catalyst to deciding that I wanted to move on and I gave a 4 month notice shortly thereafter. Ultimate jerk move, he actually hid a bonus check intended for me in his desk for weeks because he didn't realize I was being so nice with the amount of notice. He thought he could prevent me from getting it entirely. That did not go over well with the president of the company.
I've automated large chunks of my job away, but I've never felt that I ended up not having things left to do as a result. There are always more tasks to automate and more problems to solve.
I get the impression from these stories that the dishonest part of what the self-automaters are doing is that they could do other tasks and use automation to increase their productivity, but instead chose to keep their productivity the same and relax with the extra downtime.
Does "increase their productivity" equate to increase their pay? In most cases that's a no unfortunately. It's up to the "automator" what they make of their time imho. If they're wasting time playing games it's their loss since these opportunities don't come by too often. If they use it to grow their knowledge and skills that's great and well earned since the company only expected them to do their workload, the hard way. And it's fair.
And it is only not fair to the peers whose work cannot be automated, and as someone here said, it's a temporary privilege to be working in programming, we're in a different world, higher pay, more learning opportunities, more leverage than other jobs. But, nothing lasts forever. We're going to be automated away eventually.
Straight out of PhD. The interviews went smoothly in part due to earlier experience in an ISP, but these days Google takes in SREs with 4 x coding and 1 NALSD interview. It's the stuff talked about in https://www.oreilly.com/library/view/the-site-reliability/97... and there's quite a few Google-organized workshops on this.
I usually write scripts in Python or Bash, depending on the task. I've had a fair amount of success using a cron for scheduling, but I've come to really enjoy using Jenkins for automated tasks. A lot of tasks make sense to trigger off of events other than the time and Jenkins is quite flexible in that regard.
Heh. I’m an intern on the ops team at a small-medium company (just under 150 employees, at least 50 or so engineers, ~$20 mil rev), and we use Chef for configuration management. I’ve observed that some members of the ops team are actually afraid to converge servers. I also find the precedence rules, node variable (?) rules etc to be horrifically confusing. I haven’t worked with Ansible before, but it sounds more similar to how I would implement it if I hacked away at the problem for a few months (my understanding is ansible basically just lets you run arbitrary scripts thru ssh).
Being able to have chef integration tests (or are they considered unit tests?) seems really powerful. But holy fuck does Chef have a ton of (what feels to me like) cruft
Chef got to where it is today because people used it to build systems at a scale that was simply not feasible before. And as it grew more capable, people built more tooling in and then leveraged that to build even larger systems.
So, if you're not building systems at the Netflix or Amazon scale, then Chef might have features and tooling that you don't need -- today. But as you grow and you find you do need those tools, they will be there.
I can tell you that Chef was a key part of the system for taking the Raytheon GPS OCX system and letting us build out an entire virtual datacenter in a matter of hours instead of months. Once everything is racked and stacked and cabled together, just press the "Go" button and everything builds itself and installs itself in a fully automated way.
If you're not familiar with GPS OCX, that's the next-generation ground control systems for GPS satellites -- both the current generation of satellites that is currently aloft and the next-generation fleet that is being developed.
With regards to Ansible, there are many lessons that the Puppet and Chef communities learned years (or decades) ago that are being re-learned yet once again -- like ssh isn't a very scalable communications mechanism when you start talking about handling thousands of servers.
The concept of "just let me run my custom scripts everywhere" is a nice one, so long as you're talking about a dozen or so machines, each of which is a unique snowflake "pet". But when you want to start building a cattle farm, that method stops being so useful.
>I get the impression from these stories that the dishonest part of what the self-automaters are doing is that they could [...] increase their productivity, but instead chose to keep their productivity the same
I get the impression that the dishonest thing the employers are doing when they become aware of the automation is that they could increase the person's salary, but instead they keep it the same...
I realized at my last job that I was working to essentially replace myself and my co-workers. It was a pretty sobering thought.
We often joke about training our replacements but we're definitely in an age where it's just as easy (if not easier) to build our replacements.
This doesn't have to come in the form of AI which can ingest requirements and write code. It typically comes in the form of automating specific aspects of our current job. Build systems, pipelines, workflows, etc.
It's nice to kid ourselves and think of it as work intended to improve productivity but from a company's point of view the value is decreasing overhead and cost which comes in the form needing 1 person to do the work instead of 10.
Cross your fingers that you're the 1 and not one of the 9 :).
> I realized at my last job that I was working to essentially replace myself and my co-workers. It was a pretty sobering thought.
You've just described the purpose of the entire software industry. Did it really not occur to you that writing systems to automate tasks would displace anyone doing those tasks manually?
No need to cross your fingers. The demand for software is still out-pacing the creation of new developers. Those 9 have nothing to worry about, other than perhaps dusting off their resume.
Replacing yourself with something you built is what engineers should strive for.
Engineering problems just move higher up in the stack. Few people are coding assembly code now days, and in the future few people would be writing in other low level languages.
I've always seen this as the _point_ of what I do. The promise is there in work by Church, Gödel and Turing, but Grace Hopper is the one who made it tangible. She called the thing she's responsible for a "compiler" but today we'd understand it as a linker.
Grace understood in engineering terms what Turing et al. grasped only as a mathematical principle. We can get the machine itself to take the tedious parts of programming the machine and automate them, so that we're left only with some higher level task, and then, we can just automate that too, this recursion continues forever.
One thought that keeps me awake at night is that my past automation work has cost others their jobs. I understand that that's "how the world works", but it still deeply affects me that people have lost their livelihoods because of my actions.
I understand this guilt but it doesn't belong to you. We're rapidly entering a post-scarcity economy and most of the western world are employed in service industries anyways. I think the lack of more societal guarantees to survival is a critical issue especially in the US, it'd be nice to see UBI or alternatives explored more and rolled out so that losing one of these tedium jobs isn't devastating on the former employee.
Yeah, probably. My career started in a job that could have easily been automated, but never was (intentionally). So in a lot of ways, I feel indebted to it and the idea of entry level tech jobs, because it allowed me to build a career without a degree. From that experience, it feels kind of sad that certain automation can displace potential careers.
It's possible that your automation saved jobs by enabling your former employer / client to remain solvent. Sometimes the choice is not "30 jobs without automation or 10 jobs with automation," but rather "10 jobs with automation or 0 jobs without automation."
That makes no sense. If people were doing jobs that could literally be replaced by automation, they were not great jobs and either soul destroying or they would have gone away anyway.
Progress enables productivity which is a net win for everyone, your work has contributed to productivity a LOT more than the work of the people who needed to move on. Without technology we’d almost all be in poverty.
You're making a hell of a lot of assumptions there.
In the end you're probably right for a population of people. I'm not talking about that, though - I'm talking about very specific people with families to feed.
Back in the 90s I had a high school summer job where I had to run some scripts against a production database. I was told, "You have to watch it in case there are errors." Boring work. Essentially, I sat for 2-3 hours a day watching a status bar move.
I would run a backup script on a production database, then copy the backup over to a local storage drive, then run a sanitation script to clean up customer data, then copy the database again to a public folder where the devs could access it.
I would use the time to try and dissect the script and read up on SQL. A few months in, I added a few lines to the script that emailed me if there were errors (and of course this list of errors evolved over time...), and set it to automatically do the download and sanitation work.
Then I corrected a few parts of the sanitation script to block out a few more bits of customer data that whomever wrote the original script had missed, and then set it up on a schedule to pull a copy every hour... the devs loved that the data was coming down more frequently.
I was so proud of my little automation project, and I showed my boss. I was a little worried he'd be upset that I was running this script on production. He wasn't. He loved it. Then he told me to delete it.
"You cost me $8 / hour, but when you go back to school I'd have to hire someone who costs a lot more to maintain this. The budget is already approved for the year, I can't change it. This is great... and I know what I'm asking you to do is stupid... glad you're learning here... but really I just want you to sit and watch the status bar move."
We need a HOWTO for Job Automators that addresses things like:
* when to automate versus when to quit and
start a company
* who owns the code, and how to find out
* when/if/how to reveal the automation
to your employer
* etc.
>The gains from automation have generally been enjoyed not by those who operate the machines, but those who own them. According to the Organisation for Economic Cooperation and Development, the share of income going to wages in OECD nations has been decreasing since the 1970s, while the share being funneled into capital—into things like cash reserves and machinery—has been increasing.
In Australia these benefits have largely gone to land owners, as opposed to capital. See this chart:
Even a scheme such as universal basic income would not help much as the benefits would end up being captured by land owners, via inflation of rents and land prices; unless this was addressed another way, for example with a land value tax.
And what happens when this job eventually ends (as they all do) and the only thing you've had to show for your time spent in industry is your league of legends score? Meanwhile your peers would have likely moved on, gained skills and progressed in their careers in someway. Sounds like a sure-fire way to deadend your career and limit your future prospects.
One thing that I find maddening about this topic is the assumption that people who automate their jobs won't take the new time they get back and put it to better use. For some, that could be learning skills or working on a startup, and others might just want to spend time with their kids.
That said, it seems incredibly wrong to judge someone for being clever enough to relax and get paid for it. And if someone enjoys relaxing as much as I enjoy coding, who am I to say that I'm righteous and they are a loser?
I was addressing the exact situation in the article where the guy used the time to play league of legends. But you’re right it’s not for me to judge how others spend their time.
I'll weight in from a slightly different angle: I consider my job as a coder to be 90% bullshit. I call it plumbing. Inject that data stream into these input, buffer this, convert that, cache that shit. Launch a thread to do that in parallel, manage a thread pool, poll that stuff, convert that data format into that other, I could go on for pages.
My real job is in the 10% remaining: understanding the problem, producing an algorithm or an architecture, optimizing things in a way that require a deep understanding of the data, designing the UI the users really need.
I'd gladly automate the plumbing in order to do 80% of interesting stuff instead of 20%.
One of the only discussions I've "Favorited" on Hacker News was related to this: "Is it unethical for me to not tell my employer I've automated my job? "
I don't believe that a salaried employee is duty-bound to work any more hours in a week than is required to accomplish their given assignments. Nor do I believe that the tools they create themselves to do that job more effectively should automatically become the property of the employer.
The reason people do not disclose the automation of their own jobs is because they do not believe they can monetize their cleverness more effectively than by keeping secret their shortcuts. They sincerely believe the company will fire them and pay nothing for their automation tools.
It is ultimately a "truth to power" phenomenon. If you have the power to plunge me into a lifestyle of deprivation and poverty, I will avoid giving you any reason for doing so. If you have the power to take some of my profits for yourself, I will seek to avoid informing you that is possible.
The philosophy of "Office Space" applies. It's a question of motivation. If I bust my ass so the boss makes more money, I don't see another dime, so I just do the minimum amount to not get fired. And we also have to know that the minimum amount of flair is not the actual minimum amount we can wear.
I'm sure many of us have seen extra effort go completely unrewarded, or even get punished. That experience takes a toll. Not one of us can trust our employer to do the right thing all the time--even for those of us that are founders! So we preemptively choose for them, and sometimes do the thing that is right only for us. If more companies were capable of more accurately assessing the value of software automation, we wouldn't have to think twice--we'd take the bonus equivalent to several years salary, and start automating something else.
One thing I find fascinating about our culture is how much we elevate corporations above people. If a corporation found a way to automate production in such a way as to keep their product prices flat but increase their profit margin, most everyone would applaud. This is the exact same thing, but a decent portion of society finds it to be unacceptable behavior.
A question for the people that have a positive attitude towards keeping time savings for yourself instead of passing them on to your employer.
Would you be also okay with the following situation: You have someone remodell your garden. He comes up with an estimate of 1 week worth of full-time work for two people. Based on your experience this seems reasonable and you agree on a fixed price of 10000$.
Two scenarios of what happens next:
1) He shows up the next day with a gardening robot you never knew existed and he never told you he would use. The work is done in 30 minutes. He goes home to spend time with his kids. (Or maybe contract more "2 week projects"?)
2) Two gardening people show up every morning to greet you when you drive to work. They leave when you come back and make steady progress every day. On the last day you come home early and witness that actually the daily work is done by a gardening robot in 5 minutes and the two people actually drive home during the day to spend time with their kids.
One important distinction that you omit is the robot gardener costs exactly the same as other people doing the work manually. If I had to choose between two options that cost the same, but one is ultra fast and has consistently high quality, it's a no-brainer for me.
Why would the robot cost the same? If it costs the same, then there is no incentive to introduce robots in the first place. I think the wide-spread automation is a testament to the much lower price of robots compared to human labour, no?
You say you would feel "sad". To be honest, I would feel cheated. And to set up this smokescreen with pseudo-gardening people (or prerecorded data entry screencaptures to stay with the article) is outright fraught, IMHO.
To worry about how work is done if it is done well is micro-management.
Some people do want to pay money to have employees that look busy. I knew someone (in America it has to be said) who lived on a road where one person would constantly be getting gardening done just to show that they could afford it. It was constant re-work and pointless, which just showed off how much money they had. Maybe there is an element of that at work.
Security guards and secretaries are a similar phenomenon. They're not really needed, so god forbid they were to study for evening class while at work.
Maybe it really is a cultural difference. I think there is a continuum of valuations at work here:
If a contractor gets his materials cheaper or does have cheaper labor available, I don't see any obligation or market process to pass these savings onto clients, when the work is of the same quality.
On the other hand, when you delegate work to an expert, and he doesn't tell you about the 99% savings you could employ with existing technologies, I feel this is bad conduct, regardless of output. It just amounts to a 9900% markup on his value. I don't think this kind of markup is ethical, but probably the market will catch up to this expert and revalue him.
- Commissioning a script to automate something is expensive, plus you need to find the talent who can automate it and do a reasonable good job of it. It's sometimes a risky investment.
- If ready-made robots (and scripts) were available on the market, the employer would definitely use that instead
Yes, to make the analogy better, say the gardener invented the robot while on your "gardening time".
Edit:
Writing a script might be expensive, but is the market price of this script really a lifetime of data-entry salary? Seems unlikely, or we would not see as much automation.
In the first fire-engines[1], a boy was constantly employed to open and shut alternately the communication between the boiler and the cylinder, according as the piston either ascended or descended. One of those boys, who loved to play with his companions, observed that, by tying a string from the handle of the valve which opened this communication to another part of the machine, the valve would open and shut without his assistance, and leave him at liberty to divert himself with his playfellows. One of the greatest improvements that has been made upon this machine, since it was first invented, was in this manner the discovery of a boy who wanted to save his own labour.
I look forward to the blog post in a few years with someone detailing how they're earning $1M/yr because they have 20 data-entry jobs they've fully automated.
It depends if your employer is nice or not. In one job the boss was thankful and made my job more enjoyable (no extra money though). In another I saved the company a million and got demoted (due to politics). It doesn't give any incentive to share next time.
I used to intern for a large Australian bank and we had a fairly complex access management workflow.
A month into the job after I'd figured out how it all works, I spent a week automating it and was promptly told I was allowed to run my scripts do it if it was kept secret from the higher-ups (to avoid the red tape and the intern they don't trust much).
This automated a backlog of work that had a team of 5-10 people scheduled on for a good year along with any future requests, a month or two after my internship I bumped into my boss again they told me they had gone back to doing it the slow way because the bosses wouldn't approve it, despite showing a 0 failure rate compared to a pretty big one from the bored employees.
This is why equity is the best compensation and it’s going to be even more important to negotiate for it as our profession evolves. You can never be automated out of your equity.
If you create something that generates continuous value for your employer, you should share in that.
"There’s little evidence of any interest in doing so, but theoretically, self-automators could organize, and distribute automation techniques among middle- and working-class coders, giving rising to an industry that could actually enjoy that 15-hour workweek. It seems a rare opportunity—perhaps, with the advance of AI, one of the last—to try to set the terms for a mode of automation that puts people first."
This was a pretty good article until the conclusion. It's like he's totally unaware that all the information is already shared. I guess it could be a weird plea for some sort of blockchain union or something. Homie should just google "task automation github".
I had to automate my job when working full time in grad school, otherwise I never would have passed a class.
Since I entered the work force, most jobs have been some version of "automate some task for other people (customers) to exchange for pieces of paper representing effort($)" or "automate some internal task so company spends less $ paying meatware to do things saving effort($)". Rinse, and repeat until either:
a) company makes $$$$!
b) company runs out of $
If you manage to automate all-the-things and haven't hit state a) or b) then you start flame wars on internal mailing lists about how the free company snacks suck or whatever. :-)
If you wanted to only work 2 hours per week, do you think there's a place in the industry for you? Maybe for a freelancer or consultant or anything else where you are outside the company, but there's no place for this internally anywhere, no matter how efficient you are with those two hours. As long as that's the case, people will be incentivized to hide how efficient they can be.
The article suggests at the end that these people have a strong position to negotiate, and I wish it were true, but I just don't see it ever happening :(
I think a lot more would be automated by now had the right incentive structures been in place, there are still tonnes of low hanging fruit in areas that are to small or too diverse to productize.
One example I remember is a company I worked for that had a lot of people doing data entry, basically reading faxes from a variety of sources that could have been 90% automated by OCR and some trivial AI. It was too specialized for any off the shelf system but too expensive for the company to invest in automating. I probably could have built an automated system but it would take a huge time investment to get to a point where they'd be willing to buy it and they would likely not pay enough to support me full time.
Now imagine if I could retain some rights to my automation to my automation efforts? I could take one of these data entry positions and with a bit of my own time invested I could probably automate 20% of the work fairly quickly, freeing up enough time to further automate things without sacrificing my own time. Sooner or later enough would be automated that I could start doing multiple jobs if the company were willing to license it. Eventually I could take on another entry level role and start the process over.
I would come out in front, the company would come out in front and the world would be more efficient, but the incentives just aren't there.
The article is a red herring. They're asking the question "Is it immoral to fire someone for automating their job?", when the question should be "Why aren't more companies encouraging their employees to automate their job?"
Yes, a person can automate their job until they're not doing anything, and yes, a company can punish an employee for sitting idle. But the latter is inherently stupid. Automation both achieves the goals originally set out for an employee, and frees them up to do more work, without any additional cost.
The business's goals should include adding value and productivity and reducing cost. If an employee automates their job, they've improved on their job productivity, which adds value to the company at no extra cost. In the article, the company has a choice:
A) fire the employee and hire a new one to keep doing the job manually.
B) fire the employee and keep the automation.
C) keep the automation, keep the employee, train the employee for a new manual job.
D) keep the automation, keep the employee, train them for a new manual job, and have them automate that.
If the company chooses A), they're just stupid. If they choose B), they're at least eliminating an unnecessary position. If they choose C), they do the same as B), except they also retain a person that is already trained and accustomed to the company, which saves time and money. If they choose D), it's the same as C), plus they can continue to lower costs and add value.
Now look at it from the employees perspective; None of these cases result in the person who did the automation from gaining additional compensation and half of them result in them loosing their job.
> The business's goals should include adding value and productivity and reducing cost.
This is a business goal that rarely translate properly into the real world. For as much as companies tout these values it's rarely played out. Companies plod along, doing the same thing they've always done because cash flow is king and change is scary. It's easy to become complacent and addicted to steady money.
I once landed a job by telling the CEO something like, "If you're doing it right, programming is all about replacing yourself with automation."
In Cybernetics there is a formal measure called Variety which is something like a limit or measure of complexity of a system. Programming can be considered the art of extracting the low-variety parts of a process into automation, leaving the high-variety parts to the (high-variety) humans. This process itself is low-variety. Therefore, from first principles, programming is automatable. Our programming environments will eventually look like automatic systems that we instruct with our intentions, and then they consult us as oracles to determine the high-variety parts of the necessary process, having automatically computed the low-variety parts.
In fact, this is already happening as fast as people can accept it. The limiting factor is not in the machines (they are already superbly fast) but in the psychology of the people involved. Most of the research and much of the technology already exists and is in many cases decades old. (Cf. "The Mother of All Demos" and Prolog.)
As time goes on, given the exponential nature of the meta-process, it will feel like a step function for many of us: one day relevant and employable, then the next day replaced by a machine and unemployable, and unable to learn the next thing fast enough to beat the masses of your peers competing against you in the same boat.
I realized all this years ago, and have been asking peers and coworkers, "If you could write a program that could replace yourself, would you?" However, to date, no one has taken the question seriously.
I find this article, appearing in a non-geek publication, to very heart-warming. Maybe people are finally catching on?
Anyhow, this is why e.g. Universal Basic Income is important: You're going to need it sooner rather than later.
Unless there is some essential economic activity that humans can perform that machines can't we are all on the "discard pile" of history.
I actually think we'll just mellow out and enter a Golden Age, but again, only as fast as we can accept it. Certainly the Universe is willing for us to live in peace and harmony, it's up to us to choose to, or not.
> "If you could write a program that could replace yourself, would you?"
I've done it a bunch of times, sometimes by accident.
In one case I was going to be assigned to do testing every evening. But I wanted to go home at 6 every day, so I automated the tests on my first day, then came back in the morning and started 'working on my next task'; never realizing that previously the testing job had been a full time position.
I ended up doing about 5 people's worth of work there that summer.
Of course, it's probably because the project wasn't particularly organized, and our team was explicitly given a free hand to find inefficiencies and fix them. Still, it's a nice story to tell people ;-)
It's great to do that, in the puzzles we're all trying to sort out in our daily jobs actually managing to entirely automate yourself out of a job is basically solving the equation.
Granted the value created by such tasks usually isn't fairly compensated so there are a lot of societal issues.
I work in Finance/Investment Industry and was "let go" from one of the companies I worked at because I automated a large portion of my job (among other things). I even wrote an instruction manual for the entire process (not knowing that I could/would be let go). They ended up replacing me with a guy who didn't know how to program, but had 20 years of experience. Live and learn.
That's one big problem in companies. If you are below a certain level any kind of improvement you make may actually threaten your job and the company will not move you somewhere else.
The funny thing about coding is that every time we automate something away, we just go on to take on ever more ambitious projects. We've been automating away our own jobs for decades, and... the jobs haven't gone anywhere. If anything, there is more demand now than ever. Short of strong AI, I don't see this changing.
This is actually one of my biggest reasons why I don't think we'll ever develop a true engineering discipline of software. In other engineering disciplines, there's a notion of a routine set of tasks that require skill and displine to perform. In software, whenever we discover routine anything, we automate it away. Therefore there is a relentless force moving against the routinization of our work, that is precisely what has made it so lucrative to be in software.
Who knows, maybe some day that trend will end. But at least for a good while, I suspect the more likely possibility is that we'll keep expanding the scope of our work as the tools keep taking on more of the work.
At the first internship I had in the late 90's, part of my job was taking these text files full of data and creating these huge excel reports with them.
It was something that would take a few hours to do because of how much data there was. I taught myself VBA and wrote up this little program where you just upload the file and it spit out the report in about a minute.
I luckily had a boss who saw the potential in that and while I wasn't promoted, I was just an intern after all, at the end of the summer, I was the only intern the company kept.
And they moved me all around the company to different departments and I learned a ton and it was a great experience.
I did automate a few departments to the point where people who were doing full time work had their work cut down to couple of hours a day at most.
I finally left when my friends who started doing internships at these "internet" companies were getting paid more than I was and I had asked for a raise and didn't get it.
I use a calendar pretty heavily to stay on task. I automatically accepted meeting invites because my job was so boring going to meetings was probably the only good part. My managers found out I accepted them automatically and told me to turn it off. Instead of turning it off I put a 5 minute delay on the invite receipt. I was laid off for "attitude problems".
They said I didn't look at a meeting so they were mad when I'd show up a minute or two late. Of course no one cares when other managers showed up a minute or two late. This was at Charles Schwab. I'd never work or invest there.
Businesses are mostly just complicated cybernetic programs that try to turn money into more money. But it's like shitty spaghetti code where you have to understand years of debt to understand why A needs to talk to B, C, D and process the results into some new form E. Maybe they do this manually with a spreadsheet and arcane business rules passed down from generation to generation or maybe those rules are encoded in some awful program written twenty years ago that is terrible by any modern measure but is bespoke tailed to their shop/industry/regulatory environment.
You could probably automate this process but it requires a holistic understanding of the whole system which no one may even have, much less someone with the technical skills to automate. Plus it's like refactoring spaghetti code with little to no documentation, no specification except the current output, no tests, and likely involves a some combination of multiple technologies and manual human-powered processing.
What's disappointing is the opening story of the QA guy who automated his job and then proceeded to spend time playing video games. To each their own how to use new-found efficiency, but if this person had truly automated their job in 50 hours, I'll bet someone within the company could find him something more interesting to do, for a lot more money.
I read r/financialindependence from time and time, and it's not uncommon for me to read about people who have nothing to do at their job. From their account, they ask for more work, but nothing comes, and they spend their days redditing and watching youtube. Thus, they want to retire ASAP as they find this mind-numbing.
This is completely bewildering for me. All managers I've had were always eager to pile on more work on my desk when I was starting to look like I was finishing something, sometimes to a fault.
Is it a US thing? Have you guys experienced something like that? What is it, something like having to keep people around to justify budgets?
I am currently trying to automate my job. This will allow me to focus on more important issues.
In other words, I am automating away the job I don't want to do, to focus on the job that I want to to, and that will bring more value for the company. I don't expect the workload to ever decrease, just that our team will be able to tackle bigger issues.
One perspective I haven't seen here yet: these employers are willing to pay an entire person-salary to get this task done. Therefore, if there was a SaaS service that did the same task, the company should be willing to pay a person-salary worth of money for that SaaS product.
So why not build the automation in your free time, knock out a little website with a Stripe subscription form to sell it, convince your boss to pay for this SaaS service instead of paying you to do it, and then ask if they have any other work for you to do?
If they do, great: now you're making 100% of your salary from the SaaS (and you can grow it from there if you like), and then 100% of your salary again because they've retained you to do a new thing.
If not, great: now you can quit and do what you like and continue to receive 100% of your previous salary in passive SaaS-business income.
But they were just paying that, in the form of paying you. If they don't think the task is worth paying that much to get done, they would have just been not-doing-the-task.
Also, note that I never suggested mentioning that the SaaS service you create should make any mention of its service being automated.
Consider an entry in the "cloud bookkeeping SaaS" genre: they sell you on having real accountants looking at your books, with automation to ensure the reliability of those accountants' work. They never mention that they'll also be using automation to make your workload easier to handle, such that each of their accountants is handling the books of 1000 clients. That's an implementation detail.
They were paying you that, sure. But then you showed them that they didn't need to pay you that anymore, because you automated that job away. So now they won't pay you nearly so much.
You're welcome. Now, get back to work, you slave! ;)
Ah, but you didn't automate the job away. Like I said, you did the automation on your own time, with your own resources. It wasn't work-for-hire; they don't own the rights to it. And there's no instance of it already set up for them to use. As of the moment that you offer them the opportunity to subscribe to your SaaS service (and note that you don't have to mention that it's your SaaS service), they're still in the position of having no automated process, just you sitting there able to do the process manually.
So they have two decisions to make: whether to buy the SaaS service (in order to receive the benefit of the automation); and whether to keep paying you.
They can choose to say "no" to both... but now, not only do they not have an automated process, and just as little idea of how to automate it as they did when they started; they also don't have you there to do the process for them, and they lose your hard-won expertise on the process that would be crucial for building any sort of in-house automation.
(I'm assuming here, note, that the company isn't one that tends to automate processes—if they did, they'd probably have already found the low-hanging automation fruit that your job consisted of. As such, they likely don't have any in-house automation expertise, nor do any in-house expertise for evaluating the competence of automation consultancies.)
ETA: my original point was that everything I'm saying here (and more) is what some person with sufficient motivation to think through all the details would be saying to their boss to convince them. "Convincing your boss" includes "thinking through all your boss's objections and having rehearsed, polished counters for them." Have I done that? No. But I'm not someone with an automatable job.
I used to train clients on the BI product the company I worked sold and supported. This was mostly taking users through the demos. The users would follow what I was doing on their training PCs. The problem was that in one class it was possible to have users who might have been exposed to the software before or were just fast learners. Sometimes the software would have issues on the training PCs and I would have to trouble shoot what the error was. In a nutshell it was tough running demos and attending to slow users and issues with PCs.
So I automated the demos part by creating screencasts of the demos. I would play the demo whilst I was helping out my students. The first class loved the demos. They asked for copies which I gladly gave them. Management didn't like the idea and I was told not to use my screen casts.
I see this possible in only 2 kinds of organizations
1. Very large - where you are a practically a number and work in a department buried deep.
2. Small - where there is a reasonable amount of technology but no desire or budget to upgrade. It's working, so don't touch it.
If your work really is so simple that all of it can be automated then it initially sounds like a golden deal: the employer is getting what they're paying for and the employee has a lot of... free time.
But the trouble is that most decent programmers just couldn't stand that. They absolutely need to feel they're doing useful work. So they'll either expand their duties in the company (likely with no similar expansion in their pay) or leave for another company (that pays them to do the both challenging and useful work).
Another case are companies where you absolutely need to automate lots of stuff to get to do real work. If you fight the system you'll run out of energy sooner than the system ever would, but if you automate the fight you can stay operative yourself.
Easy to understand if you are cheating by automating your job and spending now freed time for leisure: if your contract says that you are paid by an hour or for fixed number of hours a week/month then you are cheating. Of course, not paying you for overtime can also be considered cheating from your employer.
The only way to not be cheating by automating your job is to spend now extra available free time for other duties mentioned in your contract, perfecting your professional abilities, or moving to a contract which is goal based, not work-hour based.
It is a pity that somebody can be clever enough to automate his/her job but don't see implications regarding the contract signed with the employer.
When I built my SaaS app Pluggio (a social media dashboard), I'll never forget a conversation I had with a customer, who gleefully explained how much they loved the product!
Apparently, before Pluggio they had someone working full time on social media. But now, they were able to fire them and do that same work in 1 hour a week for only the $25/month cost of the app.
After further digging, I realized that a lot of my customers had fired people because of the leverage that the app gave them.
To this day I don't quite know how to feel about creating products that mean people loose their job.
Anyway, it's one (amongst a few other) reasons I decided sell the business and move on.
It always bothers me how things could be automated better if people just put in a little more thought.
For example, where I work, we use both entity framework and raw SQL scripts. A common chore is to delete all migrations, delete the database, run "add-migration SetupDB", "update-database -script", and save the script (with some added boilerplate) in a specific folder
However, the "update-database -script" command does not pipe the script to output, but instead opens a new window in VS with the script. This is part of the reason why I am not a fan of Microsoft/Windows: relying on a GUI makes automation so much harder.
Aren't there ways to automate this though? Even if it's not 100%, maybe you could get the first parts, and then get everything setup so you only need to click a window and then "select all, copy, tab, paste" to finish.
I'm sure with some clever thought, you might even be able to use a GUI scripting program to work with the VS window. I'm thinking of a series of keyboard shortcuts to reliably set the state of the VS window to where you can script a mouse click in the appropriate spot and then more keyboard shortcuts to copy and save the output.
- I see your background is heavy in tech... we dont see these types of resumes normally
- yeah, i used to work on aproject for 4 years, it never saw the light of day because the people and business processes werent in place. I'm interested in exploring the non-programming side of business , the people relationships, (insert whatever aspects of position your applying for here)
I would imagine that you wouldn't want to disclose that information. There are a lot of businesses out there who want people with GEDs to do simple data entry. That's probably where I would start looking. Maybe craigslist or similar?
It seems to me that we are coming on a different paradigm of work. It makes sense in the industrial revolution to have assembly line like working. Where workers are "cogs in a wheel". But now we have tons of tools to do those strict tasks. After all, every programmer says you should program repetitive tasks.
So what do we shift to? A wider job duty and more creativity? Creativity is the thing that machines still fail at the most and (as far as I know) currently impossible to automate.
I am a researcher/trader and I spend a large portion of my time programming, but I am ultimately paid off the change in profitability of the strategies I've worked on and not on the code I've written. It's a means to an end.
When someone is working on a purely technical project, how can they successfully argue for the value of their work? How do you measure the value of a purely technical project? Are there other metrics that matter?
If you are getting money for not working because you automated your job away, good for you. But you should be aware that your company will likely not survive very long because it is being mismanaged. Chances are that it has smarter competitors already. Usually it is just a matter of time before the shit hits the fan.
So, you might want to consider using your time preparing for that eventuality. E.g. spend some time learning new stuff or jump ship to a better company.
This is a big generalization. Not everyone is looking to automate tasks, so it's not a sign of mismanagement that someone has employed a novel way to reduce work. Efficiency is a goal of management, but not the only one. It's unrealistic to expect a company to pursue and capture every inefficiency. Often it's cheaper to allow aspect of "work" go unabated than to invest in both the feasibility and implementation of its automation.
If you're referring to mismanagement due to knowing what an employee is doing, I think that too is a generalization. Dovetailing with the above, if someone is getting a job done, why invest time and resources into auditing how that's done? In 99% of cases that's waste.
In the grand scheme of things, big companies are vulnerable to degrees of malice and abuse by their employees (not necessarily ascribing those terms to these actions). But they don't necessarily fail to exist because those vulnerabilities were used.
I think you underestimate how defensible some businesses are. For example, a supermarket or bank in Australia. “A matter of time” could be your entire career.
Yes. I worked for a company that has such a moat surrounding its line of products, it will a couple of decades to erode.
70% of the people there were doing very little on a day-to-day.
I automated my job at a company. I did not tell management for a week after but was then bored. It took another few months of me nagging them for more work before the believed me and gave me another project.
It was a business critical application I inherited that was highly unreliable, my job was to keep it running. I just reworked the code so that it ran reliably and was resistant to outages etc. I also added in a few scheduled tasks etc to keep it ticking over
This could be a koan: If you write a program that works so well that it makes your job of programming easier - are you a good programmer or a bad programmer?
The opposite also happens. Almost fifty years ago at a large insurance operation in downtown Los Angeles, there was a programmer who programmed and maintained a suite of reporting programs. But his programming skills were limited, so he was actually just keypunching the needed reports into his programs as hard-coded data. If you get what you pay for, why care?
Many programmers who automate portions of their workload will use the extra time they gain to place bugs in the systems. When those systems fail, they quickly fix them and look like a savior. If they are on after-hours standby, they make extra money from the callouts. They thus reduce the stress in their own jobs, but increase the stress in other peoples jobs.
When I have "free time" at work, I put that time towards refactoring, improving/expanding test coverage, and scouting out potential performance boosts through our logs, load records, etc.
Wow we don't live in the same world here, programmer actually is mainly the job of automating tasks, so when I'm finished automating things, I automate other things.
I'm not placing bugs that would be so easy to uncover by my peers using the most rudimentary source control, and make me look like a fraud in front of all the company...
When I worked in IT, both in mainframe programming and before that in ops, I saw many cases of this. "borderline" is just another word for "plausibly deniable". Programmers doing it can claim to have made a mistake. Managers turn a blind eye to it because it's easier than getting pay rises for staff they don't want to leave.
I've never understood the profound lack of drive and ethics it takes to automate your own job and then conceal it from your employer.
The worst jobs I have ever had have ALWAYS been the ones where I'm not contributing to my company in an obvious way, or at consulting firms where we consistently kick ass and finish our sprints early, and then goof off for days on end.
That assumes you want to be doing the thing you're doing, rather than some other thing (which potentially doesn't generate money.)
Professionally, I'm a programmer. I write code for money.
But vocationally, I'm an author. You know what the best job in the world would be, for me? One where I'm paid a living wage to do nothing at all. Then I would have the free time, the energy, and the resources to write books.
"Why not just become a professional author?" Well, because being a professional author is only a little bit about writing books. A lot of being a professional author is about selling books. Going on tour to signings, appearing on morning talk-shows, and just generally running the business of extracting royalties from your book.
But I am not, vocationally, a businessman who happens to be good at writing books, and so sees that as an appealing strategy toward an end-goal of "making money." No, I'm an author. I love writing, not money. I love seeing people's smiles when I reach them with my writing. Money is a means to that end—a way to keep me alive so I can keep doing the thing that makes me happy. If I could be kept alive and functioning and able-to-write without any income, I'd gladly have none.
I would say that I have plenty of drive. Just... not for doing the thing that I do for money.
Honestly, your comment annoys me because it puts words in my mouth, as if I'm doing what I want to be doing. As if I DREAMED of being a back-end developer my whole life. As if I'm some artless drone that can't understand the mind of an artist.
> That assumes you want to be doing the thing you're doing, rather than some other thing (which potentially doesn't generate money.)
No, it doesn't at all. It means I would rather be doing something more useful than browsing facebook all day for a job I'm being paid to do. It means I don't dump all of my work onto the people around me and be a complete parasite. It means I want stability and praise instead of constant fear of being discovered and fired and ruining my own life.
Most of us do not want to work, that is why we are paid for it. The vast majority of people do their job to get by.
> But vocationally, I'm an author. You know what the best job in the world would be, for me? One where I'm paid a living wage to do nothing at all. Then I would have the free time, the energy, and the resources to write books.
Yes, I would love to hang out at home and read books all day, constantly learning new things.
If I could drop everything and not have to care about having a roof over my head, I would be a video game developer or an artist.
BUT, I don't have rich parents or anybody to support me. I don't have the privilege of not working, most people do not.
So instead I'm a slacker programmer who doesn't work overtime, gets by, and lives his life the best he can in his down time.
> I would say that I have plenty of drive. Just... not for doing the thing that I do for money.
To be clear: I'm specifically talking in the context of people who are so dysfunctional that they automate their jobs and do literally nothing for years. If I was in their position I would find something more interesting to spend my time on.
What do you do after that? Who is going to hire you after being fired for defrauding the company? Also: I believe doing things like this CAN open you up to liability. Also often a company owns everything you do with their computer, or that you do during work hours.
I am currently building and selling software that automates fx and fixed income otc traders out of a job.... Or rather....allows them to spend more time on higher value tasks (so goes the theory!)
It's fairly addictive automation, I'm finding all sort of functions and jobs that could / should be automated to the growing frustration of my colleagues :-)
In A Winter's Tale by Mark Helprin (different one, but still something of a jerk), the rich daughter of a Newspaper magnate who has needed glasses since she was a child gets an eye exam and is declared to have perfect vision and not in need of glasses. Her father says to bill him for one pair of perfect glasses that will never break.
I'm employed at a company that engineers financial institution software. I have no qualms admitting when I moved to QA I quickly wrote a program to do my testing. Now each release I just update the relevant variables compile load and run. I see no problem with using my grey matter to it's full potential.
I've read on HN (don't remember exactly) a story about a military service person, who automated his data entry job and told his commanding officer, who scolded him and told him to do what he was supposed to do and "not to be clever". Maybe someone recalls the article I'm talking about?
There's a big difference between a Software Engineer and a Data Entry worker. While I (Software Engineer) can definitely automate certain parts of my job, I cannot automate taking an issue from the board, figuring out how to solve it, writing code to solve it, and getting it reviewed in a PR.
I work for a financial software company in QA and I have no qualms admitting right after arriving I wrote a program to test the new release code for me. Each release all I have to do is change some variables load and run. I see nothing wrong with using my grey matter to its fullest potential.
The real story is that management didn't hire someone to automate these tasks in the first place!
That's what we have software for, do boring stuff so we don't have to! By automating these people proved themselves to be developers, and not just software-in-a-meatbag, or SIAM, if you will.
Well it seems that if your work can be so easily automated, we shouldn't call you coder in the first place.
That's an interesting debate, but basing the article on 2 anonymous reddit posts whose authors couldn't be reached to get the full story is not what I expect from journalists.
Automating data entry work or similar is one thing, there are many companies out there automating a high-value-added work like IT project management. Most of the work project managers do today will be automated in the coming years. Mark my words!
One thing that PM's do that I don't ever see a computer doing is managing clients/workers. It's the classic idiom: technology is easy, it's people that's the hard problem.
The people automating their jobs are automating themself out of the job,but freelancers are just simplifying their job.
The difference is freelancers aren't obligated to reveal the magic of their work. They just "do it".
It would seem automated coding would be right up "Ditching Hourly" Jonathan Stark's alley... It would instead require a shift in attitude about value and time. It follows in the lazy (automate it) ethic.
Inter Alia, this article is another piece of evidence that a lot of pretty smart people are stuck in jobs that aren’t very complex. The accumulated cost of this to the rest of us is quite high...
We automate everything we can, but I never felt for a single moment that I will have no job tomorrow if I do this, there is always so much problems to solve, so much to do.
Moore's Law seems so ingrained in Silicon Valley, that not questioning automation opportunities every 18 months is a guaranteed predictor for obsolescence.
Not sure why so many people here are surprised that benefits of efficiency accrue to the owners of capital. That's the basic premise of capitalism in a way.
Profits float upwards, hard negotiation pushes downwards on actual workers and managements try as much as possible to reduce what's owed to actual "doers" of work.
And no mention of Marx or Socialism? If there's ever an appropriate time to bring up worker-owned means of production, it's this right here. As I've heard it (I have not read the Communist Manifesto myself), Marx viewed automation as one of the ways in which workers can liberate themselves.
The merit of welfare economics is predicated on the "winners" being able to compensate the "losers", and thereby obtain a Pareto-optimal wealth distribution. The fact that this compensation does not happen is the reason that aggregate consumer welfare has grown tremendously, but people still have to work 40 hours a week for their food, housing, and healthcare.
It's tempting to say that employees ought to be compensated proportional to the value they generate. Let's say every employee is allowed to license their work output in such a way that, if they automate a process, they are entitled to royalties stemming from the automation of that process. Should that license be perpetual? How do you decide how big the royalty should be? How do you determine the actual value generated by a given automation?
this is in a class of problems i've been thinking about recently
- usury
- patents
- copyrights
- land
- software as a service
the first 3 all have some slowly changing socially acceptable period of profit. and they are all enshrined in law. but this means there are also frameworks in place for adjusting this period of profit (lobbying, etc.)
the 4th is only capped by property taxes and sometimes with unintended consequences (cf. prop 13)
the 5th is unregulated and seems socially acceptable to have no definite end date due to a combination of (sometimes artificial) technical difficulty (need for support, e.g. RedHat, any other company based on FOSS) and slow addition of pithy features.
i'm not sure i have any conclusions, but I think this framework is useful because it allows us to examine it with an older moral framework rather than a more (post) modern marxist.
I never see anyone suggesting that maybe we should be rethinking the contracts we sign as developers and rethinking how our compensation is determined. Despite how well you think you're being paid, you're being underpaid (this is almost necessarily true economically) -- in addition to that, companies have literally colluded in order to suppress your wages, despite making profits fit for history books.
The idea that an employer owns everything (in particular IP, basically the products of your mind) that you generate on their time or yours while you work for them is bullshit -- it's a complex problem but business has chosen to resolve it 100% in their favor and workers just laid down and taken it. Non-competes and strict laws against selling secrets are one thing, but laying defacto claim to everything you generate is ridiculous, yet is the norm.
-- rant incoming --
Software Engineers/Developers/programmers are just the bottom rung of this century's gold rush. Half the time the mines they're working in are canary-less coal mines. Some drink the kool-aid and think the "startup" they work for is anything more than an aspiring too-big-to-fail company, after a few years they wise up and by that time they're too bogged down with life to care/change course. I remember reading a post earlier in the week on C-level compensation and noting that CTOs were the least paid of all the C levels, despite being maybe the second most directly tied to the economic value of any tech company (sales might be #1).
Despite how smart we think we are, software engineers are fucking stupid. This article is stupid, but only because the premise is stupid (outside of taking ~20 paragraphs to go through random internet musings/anecdata to get to it's point:
> Self-automators show that coders are actually in a unique position to negotiate with employers over which automation-derived gains—like shorter workweeks and greater flexibility to pursue work that interests them—should be kept by workers. There’s little evidence of any interest in doing so, but theoretically, self-automators could organize, and distribute automation techniques among middle- and working-class coders, giving rising to an industry that could actually enjoy that 15-hour workweek. It seems a rare opportunity—perhaps, with the advance of AI, one of the last—to try to set the terms for a mode of automation that puts people first.
People who deliver out-sized value for a company but aren't naive enough to think they'll be anywhere near properly compensated will not share their secrets. The ethics question isn't even on the right side, companies should be paying employees for the value they create properly, this situation exists because that doesn't happen. Companies are "people", yet aren't beholden to ethics and are largely run by people divorced from the realities they impose. Where you land on this issue is basically how your employment contract was written and how you interpreted it, against the backdrop of the culture it's in -- the only difference is that people at the just about always cheat/bend rules or find luck to get to where they are, but preach that they "put in the time" and honestly just worked hard for forever to get where they are.
There is nothing inherently noble about doing work -- that's vassal brain fodder. If working was the only way to build discipline and dedication then we should all be working graveyard shifts at 3 jobs, and not wanting to get rich.
> “They took what I had developed, replaced me with an idiot that they showed how to work it, and promptly fired me for ‘insubordination.’ I had taken a business asset that was making them $30 grand a year profit and turned it into a million dollar a year program for the company, and they fired me for it to save ~30 grand a year on my salary. Job creators my ass.”
There's an inherent conflict of interest and power struggles in many organizations. The business people rarely do create value by themselves; they create the opportunities where value can be created -- and not all businessmen. So when they see something that changes the game, they utilize the convenient clauses in the contract and seize that new power which they can utilize and try and gain the upper hand on others like them. Cynical I know, but it's what I observed first-hand and what many others have told me.
> Ideally, automation decisions would happen collectively, with colleagues’ and peers’ input, so, the gains could be evenly distributed.
Cute, but I don't see this happening anytime soon. Let's face it: most of us fight for scraps from the tables of others, much more rich, people, for most of our lives. Look at a lot of politicians.They start off so idealistic and some of them even strongly believe everything that got them elected. What happens next? We don't know what happens but the end result is that they get more and more disconnected from the problems of the people who elected them. Why do you think that is?
I believe it's because they got their hands on money and connections. Additionally, they worked a LOT to get where they ended up eventually. Tell me, would you like to start over in a brand new area and not get your hands on poorly documented money and just work for a meager official salary? All of that when you are 50+? We the people burn out and we need our efforts to lead to a better future where we work less. IMO it's inevitable.
What I am saying is that I don't feel the need to share a piece of $500,000 a year consultancy with fellow programmers if I do NOT have several beach houses and apartments in downtown areas of several capitals. And have a healthy reserve of money to last me a economical crysis akin to the 2008.
...Basically, I don't see myself being very generous up until I hit 8 figures of income. I am greedy and I am real about it. I don't feel many others are very benevolent and will STAY benevolent when faced with the choice to live peacefully and leisurely with all the financial security they desire vs. taking risks to finance people who might just be looking for a secure paycheck and don't care about the cause you want to invest your wealth into. This is a very real risk and is the reason for the failure of a lot of startups.
But if you have different view I am interested to hear it.
> “The system shouldn't be more important than the individuals who helped make that system relevant.”
That is unequivocally true. And IMO it will never change anyway. :(
The people who collect and get to redistribute wealth are greedy and aren't that stupid that they will invite competition out of a good heart.
Many years ago, one of the secretaries was on holiday and the big boss asked me to write a program that, unbeknownst to me at the time, completely automated her job away. When she came back she came to me in tears, couldn't believe I had stabbed her in the back like that. Well this story has a happy ending, the boss did it so he could promote her, he just thought it would be a nice surprise! But ever since then I have been very conscious of the power we have and I try to work on new things, not merely automating away old ones. I make the exception obviously for using automation to bring work back in-house that had previously been outsourced or offshored. Those jobs are already destroyed, and automation always improves the quality and turnaround.
Yes the employer is dumb for not realizing the job can be automated. Yes you are smart for writing code that automates the job. But I feel, as an employee of the company, it is un-ethical for you to knowingly see an extreme inefficiency and hide it for your own personal gain.
Also, it seems like a huge way to waste your life. Find another job where they can actually use your skill set to do something meaningful.
So its perfectly ethical for a company to hire you for $50K to produce say $100K revenue, and continue paying you $50K even though you produce $1M in revenue after automating (or even fire you and keep the code)?
Why is it ethical for companies to get away with paying you FAR less than the value you produce for them?
It's only unethical if you're being paid hourly, where you're being paid to work a certain amount of time, and you're just sitting around goofing off while your scripts run. If you're getting paid salary, then you're getting paid to get the job done, regardless of how you do it. However, if part of your salaried job description is to find ways to do things more efficiently, and you don't share your efficiency implementation, then I can see how that would be unethical, but that is usually at the executive level, not the coder level.
It may or may not be a waste, but why do you believe it to be unethical? The employer employee job is a contractual one. When it is the company that sees me as an inefficiency I will be eliminated for the companies gain. Similarly when I the employee see an inefficiency in the company, I can eliminate (automate) it for my gain. This is the symmetry in the contractual relationship. To say that this relationship should be asymmetric is to grant even more power in the employer-employee relationship to the employer.
I actually believe that there's a culture war implied in this debate; the question of who deserves to reap the gains of automation is more than just philosophy or ethics. The question "is there inherent nobility in work itself?" seems to be just as much a political divide as any of the current popular hot-button issues. Your gut reaction says a lot about the regional values of where you grew up, whether you'd ever support a basic income, and whether you believe that someone's refusal to work should condemn them to destitution.
The closest comparison is the attitude people have if they find a wallet. In Japan, you will get your wallet back with cash intact. Yet in the west, there exists a large contingent of people who believe with all of their heart that God wanted them to find it, that the person who lost it should have been more careful, that they are just having a lucky day. Unless God shows up and declares one side to be ethically correct, it will remain a toss-up.
One thing I find fascinating about the article is that it's assumed the cleverness was the code written to automate. This is incorrect; the cleverness is in noticing when a task can be automated. Typically, the code itself is trivial.
Anyhow: automation is surely one of the best reasons every person should learn a little bit of programming. And even with that task accomplished, I suspect that the rate of people seeing the opportunity to automate will stay roughly flat.