Coders Automating Their Own Job
theatlantic.com
theatlantic.com
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.
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 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.
Often, a mature codebase shrinks as code quality improves. This drives the efficiency wonks absolutely bonkers.
what do you mean by that?
I'm not putting this very well.
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.
What sort of work do you do?
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.
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?
> 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 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.
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.
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.
The latter does happen.
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).
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.
Hard work results in being able to take advantage of more opportunities. But you still have to have those opportunities.
I think this is a case where people confuse correlation and causation. Hard work correlates with success, but it doesn't cause success.
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?
>>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 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.
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.
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).
So there are many causes of success.
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.
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.
> Hard work correlates with success, but it doesn't cause success.
Absolutely, that's a key part, I think.
Unless you get hit by a truck. Or unless you have a stroke. Or unless you are otherwise unlucky.
Because we do not live in a just world.
As an employer .. if something can be automated, and you're paying someone to do it manually—do you deserve to get burnt?
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.
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.
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!
> 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".
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.
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?
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.
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.
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.
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.
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
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.
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.
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
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.
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.
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.
Nietzsche would hate this question: https://en.wikipedia.org/wiki/Master%E2%80%93slave_morality
Working is the opposite of noble in the traditional sense of the word.
Perhaps Nietzsche, with his critique of traditional Christian values, can be seen as a reaction against Christianity.
Nobles wouldn't work because that was for serfs.
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'.
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.
Called the guy when I found it. He totally panicked. Was odd.
When I handed it to him, that face! Worth it.
Amazingly, he proceeded to try and give me the cash. Was an effort to decline.
At the time, I really needed a warm fuzzy. The lost wallet was a great opportunity, and I got a good one.
But, our conversation basically centered on, "who does that?"
Indeed. The stories of Japan make me want to visit just to soak a little of that in.
I think it all adds up. More of us just need to keep doing it.
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 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.
the cleverness is in noticing when a task can be automated. Typically, the code itself is trivial.
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.
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.
Well to be honest there's only a small number of people with the means and connections to even start such a venture.
> Anyhow: automation is surely one of the best reasons every person should learn a little bit of programming. And even with that task accomplished, I suspect that the rate of people seeing the opportunity to automate will stay roughly flat.
Absolutely. A minor observation I have, living in Operations/Finance. Don't merge cells in Excel. Observing a spreadsheet is a fantastic indicator of an individual's knowledge of automation vs manual process. Someone that uses lists without merged cells is someone that not only can save days of of the year with pivottables, various forms of looking up, but probably has the idea of 'tables' 'if' and 'for' in their head.
This is a great kicking-off point for coaching through ugly VBA. I like VBA. It's also often the only choice in corporate environments. But it is an option, and the chance to coach someone that's on the edge of...
> I suspect that the rate of people seeing the opportunity to automate will stay roughly flat.
...to push over that edge.
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 he found a better employer.
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'.
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.
[1] https://www.huffingtonpost.com/david-briggs/no-time-for-crim...
[2] http://marripedia.org/effects_of_religious_practice_on_crime...
[3] https://academic.oup.com/socrel/article-abstract/78/2/192/30...
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.
Contentiousness is not a 'romantic past', it's a perennial ideal.
But these communities do tend to have a dark side along with the positive attributes you correctly mention.
Additionally, if the basis is faith, and people no longer have that, what then?
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.
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.
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.
Quantity is no substitute for quality.
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.
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.
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.
Do you have any evidence to back up your claim in the OP?
> The notion that religious people are less likely to do bad things is highly problematic, objectively and logically.
What exactly do you mean by “highly problematic, objectively and logically”?
> People should not need to subscribe to a paranormal belief system to understand that theft, rape and murder are bad.
“Should not” and “do not” are two very different things.
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 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 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?
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.
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.
Also, yes - anybody can do management, and anybody can do coding. Learning to do either effectively is a skill.
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...
Perhaps people are worried you'll automate them straight to a layoff?
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!")
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.
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.
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.
Show, don't tell.
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?“
Whatever floats your boat — I‘m CTO by now.
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.
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.
Here, I will show you. https://news.ycombinator.com/newsguidelines.html
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.
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.
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.
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.
That is so depressing.
There are tremendous financial opportunities waiting behind automation of expensive tasks usually performed by developers.
For many of those tasks, the moment is right now, and the code itself is not trivial.
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.
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.
these days I get brain chills whenever I do something un-intellectual but very sensory-based: crafting wood, molding things, taichi..
Work today is a twisted version of sharing group survival/happiness.
I'm experiencing a shift in that thinking right now. I write reusable, modular, tested code. My co-workers don't. I use a project management system (Phabricator, on my own personal server, which I maintain); the company doesn't. For most of the last year, I've used these to produce more and better code than others have, but my responsibilities have only expanded while my pay hasn't.
I've vocally evangelized these practices and I'd love nothing more than to see them get adopted by the other developers, but so far it's not getting any traction.
So I'm shifting towards logging the value of the work I produce -- regardless of whether I'm just copying in a file from my extensive library -- rather than the time it took me to accomplish the task.
And starting to look for a new job.
I hate to burst GP's bubble, but the attitude and environment at his next job probably won't be any better in regard to "best practices." It's extremely difficult to gauge how your attitude toward development compares with a prospective team's after an hour of chatting. I became a manager last year and quickly discovered that changing others' behavior and habits is next to impossible. And if he does happen to find a new team that matches his work ethic he can be certain that 1 or 2 years down the line it won't any longer.
I think the only two ways to avoid this is to become a contractor and switch gigs every 2 years, or start your own company and hope the people you hire share your attitude.
If you're interested in progress and growth, I can say with a high degree of certainty that what you don't want to do is apply to work on a very stable team. These people are always confident that they know what they're doing - even when they agree that the outcomes aren't great. They've had lots of time to practice their rationalizations and that kind of cognitive dissonance can be pretty jarring/aggravating.
By definition, starting your own company or contracting will avoid that situation, but you don't need to take your ball and go home just to get the right kind of environment.
Fifteen years later I sit in meetings telling people (some of them still older than me) not to touch the stove because it will hurt, and I have to patiently wait until someone gets hurt before we can discuss the proverbial oven mitts.
The problem with doing something right the first time is nobody appreciates how hard it was.
Sometimes if you do put in quality and do it right in development it costs you in time and then by perception.
When you hit the ship date over finishing the iteration/version/product you have problems after ship from external customers, when you do it right and handle the problem in development before ship, you take a hit in perception internally.
The problems after ship can harm a product/company more than a slight delay in shipping, but today it seems people don't care as much as there is more specialization and larger teams where it is 'not my problem'. Some clients/project managers see a bad product shipped on time as good, and a good product shipped late as always bad. The external perception should play more into that perception not just hitting their part of the project goals/milestones.
Hitting dates is hugely important, but messing up a product with the customer can be deeply problematic. Noone truly remembers a late product after it ships and is quality, creative and functional, they remember a bad product.
I prefer the Valve Time [1] philosophy, get the product right over the date, and don't set dates until you have the product actually ready.
Does a development agency that focuses on this model exist? Of course they should be paid more per hour (or other unit) than your average, less optimized agency, but the sum total should be less than hiring inefficient agencies.
(P.S. I understand the best developers probably don't want to start or work at development agencies, but assuming there are some.)
Seems to be a good idea to separate out the architecting from the actual implementation. Makes sense, because if someone knows they'll have to be implementing, it could cloud their plan for the ideal solution. Similar to separating out design, UX, and development roles.
If you know of a development agency, odds are that it is probably a body shop.
The places that do work like this are more like Unicorns. And Unicorns are damned hard to find and hire -- or get hired by them.
This sort of thing is how I now pay the bills.
In many cases, what somebody does (and why) is not documented, or if it is the documentation is most likely out of date and inaccurate.
To effectively automate a task, you need to fully understand what needs to be done as well as have the skills to do the actual automation. Getting somebody in who is unfamiliar with the job, can work, but in most cases you will end up with an off the shelf system that has been customised to perform the original task but come with a large overhead of maintenance that may take more work than the original task.
My suggestion would be that rather than get an outsider to create the automation tools, up-skill and authorise the staff doing the work now to allow them to gradually automate the process. Make sure you make it worth their whiles to automate.
1) As person with business knowledge, vision, plan, etc, I should fully document the business goal and why we're doing it and what we're trying to achieve at the highest level, then work with the developer to figure out what should be developed to achieve that and where to automate.
2) Don't hire outside person or agency, but bring someone in full-time or as a part-time partner for the long term and incentivize them to get better and better?
I think we instead do the same amount of labor, but accomplish more.
They do that to and have always done so. It's barely remarkable because it is expected and part of the job. The problem is you can't benefit from that, as soon as you automate one part, you are given other tasks.
I don't hand-create machine code. I don't write assembly.
I write in the highest-level language that still lets me fully specify everything I care about, and then all of the lower levels of code generation are completely automated. Programmers have always automated programming jobs as much as possible.
And really, the existence of computers is the result of automating the job of human computers away. The entire history of computer science is this.
The difference is that these guys hit a local maxima, and just ... stop. Instead of moving up to the next level and making more money.
CS encompasses way more than automation. Graph theory, ADTs, complexity analysis (just by way of example) are all very relevant, even if the computation is done manually, by hand.
A lot of computer science presumes a very abstract computer; a human and a modern machine apply equally well.
That's assuming your employer will "move you up" and you'll make more money. Or that a future employer will see value in you automating your job. Then there's this story from TFA:
> a user posting as AcceptableLosses wrote, “They took what I had developed, replaced me with an idiot that they showed how to work it, and promptly fired me for ‘insubordination.’ I had taken a business asset that was making them $30 grand a year profit and turned it into a million dollar a year program for the company, and they fired me for it to save ~30 grand a year on my salary. Job creators my ass.”
Which sounds so entirely stupid as to be almost incredible. Why not just take this guy and move him, even sideways, to another role he can automate? But I believe him, because I've seen a lot of stupidity in Big Companies, especially the old school ones.
Modern web dev is fantastically more productive and efficient than it was 10 or 15 years ago.
Most/many SAAS apps are substitutes for aspects of what previously would have been part of a developers job to put into place.
And perhaps even then not so much: at a minimum you probably need to write unit tests.
I have to disagree. The esthetical expectations of the user/customer are higher now. If it's not "in style" they think you are sticking them with old tech. And you have the desktop/mobile split that frameworks only get half right and require days of black-box fiddling to get working right on all devices. And JavaScript gizmos often "break" as new browser versions or related components come out. It's almost as bad as the "DLL hell" that desktop applications used to face.
From a purely utility standpoint, I was much more productive back then because I only had to make it work and be easy to use, not "pretty" and animated with toys or the latest style fad.
Is that even true? Is there any survey showing that users consider those bad or old tech? Because with things like the reddit, ebay, paypal, gmail redesign, the common thing i ve noticed is that nobody asked for those.
As far as old-looking sites like Ebay, if an Ebay competitor appeared with equivalent services and product choices, yet LOOKED fancier/stylish, Ebay would start to lose customers. Lucky for Ebay, no such site exists. (If they appeared, Ebay would probably spend on a visual revamp.)
Not pretending for a second I'm safe.
That's not always true. In at least 2 different organizations I worked at they were creating a combinatorial mess of search screens and/or reports.
Using a little bit of meta programming, query-by-example forms, data dictionaries, click-able drill-downs, and modular design; such "reporting stacks" could often be simplified into either a fewer number of screens and/or designed in such a way that a non-programming power user could configure most reports on their own. Allowing CSV exports of query results also reduces the number of "paper" report requests because Excel users can then format their own.
The result is something that needs roughly 1/3 as many programming hours to update and maintain.
One caveat is that you have to know the domain fairly well for it to be practical. You have to learn the domain patterns and habits in order to factor those patterns into meta-patterns. When I tried it as a newbie to the org, I usually did it wrong.
As a sysadmin who started out replacing power supplies as a datacenter tech, and nowadays wrangles AWS auto-scaling groups, the idea of _not_ automating away the tedious parts of my job is pretty hilarious. I had one operations/support job where this was the case, and thankfully, I quit after one month.
If anyone out there has the gumption to cobble together a dev environment and automate away their BS job, yet can't get recognition from your employer; it is time to seek out a new job, you've certainly got the skills for something better!
Operations is a pure cost center. Cost centers only exist for the express purpose of being compressed twice as much this month as they were last month, so that you can make them half as expensive.
Developers are valuable. They create value.
When all the good Operations staff has left because they're tired of being treated like mushrooms, all the Operations stuff gets thrown over the wall and then the Developers get told that they are now DevOps.
One such tool is very popular here in South America:
https://www.genexus.com/en/global/products/genexus
GeneXus™ streamlines application development by automatically generating everything from databases to code, frontend to backend, and server-side to client-side services. It’s not magic — just a smarter way to create smart technology.
It ends up being a kind of DSL.
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.
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.
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.
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.
Although, slavery existed within the feudal system as the lowest class of serf.
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.
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 :)
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.
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.
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.
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.
That is the crux right there.
If you automate something and don't tell your boss then you have cheated the capital owning class out of their right to all capital.
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.
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 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.
Rent people at sub-subsistence wages? I guess it's okay.
My advice is to not fight this state of affairs. Figure out your own way to stay productive. Divide up your spare time between coming up with ideas for your employer and doing side projects. Take long lunches with your coworkers and leave at 4.
You can find happy professional nirvana but you have to believe in it first.
As long as that is properly understood you can get a contract that is permissive enough to allow you to work on something else at work when nothing is burning. Even if you have to offer a reduced salary, it's worth it.
Another option is to go the work on OSS route, especially on tools you use for work. After a couple years of doing semi-fulltime OS work you'll be commanding double the salary.
In practise, achieving some sort of "steady state" or status-quo doesn't work for a few reasons:
1. Inherent system complexity ensures something always breaks. Human attention is always needed.
2. Markets evolve rapidly due to technology changes, regulatory changes and the very nature of markets: Strategies and ideas that worked in the past cease to work in the future.
Once two different traders discover how to 'perfectly' trade, the game changes and as they say 'here we go again'
- currency is very different from equities - while one could argue that a central bank deciding to peg it's currency to $ is a realistic scenario, it simply doesn't make sense for equities (an equity is basically a right for present and future earnings of a company - good luck 'perfectly' predicting that !)
- as you note, there would still be speculators, since there is always uncertainty. There are numerous examples of countries pegging their currencies and then when unexpected happens...
- traders / sales would still compete for order flow of the clients (and get the cut), so there would still be a game to be played albeit for smaller margins
* actions of any given platform doesn't meaningfully influence the market
* all have ability to forecast weather with 100% accuracy
* all have ability to perfectly predict human behavior
* all acquire the exact same news at the exact same rate
* all connect to the same exchanges with the same latency
* all have the same amount of capital to leverage trades
Simply put, there are incalculable ways for a trading platform to gain advantage over another, so I don't think this will be an issue in many lifetimes.
Yes - this... Buying or selling even 1 share in the markets adds information to this giant calculating engine. Anything you do will alter the course of the future.
I've never seen a backtested strategy that didn't look great on paper. The moment you drop it into the market - you can take a steep discount to your expectations.
Doesn't make the decisions for you but manages the other 80% of the complexity involved in deploying a trading strategy.
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.
It is not necessarily an easy path, it takes time, and there's going to be trial and error involved and although the discussion is about automating 100% of a job away, there's many other possible outcomes such as effort-multiplication, getting rid of the grunt work and gaining more time to focus on deeper problems.
This is effectively "out-of-band" work that is a great experience for the individual but which _many_ organizations do not condone. A LOT of workplaces don't tolerate workers doing stuff that they're not being "told" to do.
Or they fire you because they don't need you anymore.
This is the kind of ridiculous thinking I'm talking about in my other comment. You just made your job into a cheap, automated process. That's the most valuable thing you could do in a company! If you did that in my company, you'd get a promotion and you'd be put to work finding other things to automate. You're the kind of person every company wants! Why would we fire you? If we're dumb enough to fire someone like you, you're better off at another company anyway.
Sadly, while there may be some logical people in a company, many companies (most?) wind up not being run in a logical manner due to a wide variety of internal politics and societal issues.
What you hope (and pray for) is that the logical people in a company are not also sociopaths, in which case you are really well and truly screwed.
> Or they fire you because they don't need you anymore.
What actually happens is that regular people who you would not assume are "programmers" start picking up computer skills and employ them in a piecemeal fashion a little bit at a time until eventually their day-to-day work becomes something quite different from when they started out.
This has been going on for at least as long as there has been a computer on every desk. I think "software engineers" should not be so smug to think that everything worth doing is something that they're going to get a chance bid on and then get a project managers or scrum teams to implement.
As for whether the person that does this gets fired or promoted depends on their skills at managing their peers and superiors, and what kind of environment they work in.
Obviously there is a balance - a company shouldn't get ALL that savings (although in the long run, that savings would need to be passed on to customers, since competitors will also be able to automate the same tasks).
At the same time, I don't think it is fair (or sustainable as a society), to expect to live forever off of work you did over a few weeks (no matter how valuable that work might be).
If we allow people who automate things to live off the work of that automation FOREVER, then we are creating that sort of distopia that anti-technology people claim; that WOULD be taking jobs, because ALL of the benefit for the automation would be going to the automater and none to society. Society would still be paying the same amount for the resource, it would just all be going to the person who made it.
Obviously, it shouldn't all go to a company either, but if ALL (or many) companies in the same field also automate, they will HAVE to pass on the savings to customers to compete. This will provide a net gain to society, since the resource is now cheaper for everyone (at the cost of the people who used to do the job).
The cost decreasing with automation is REQUIRED to make it a net positive for society, and the automater taking all the rewards for the automation in perpetuity ruins that.
In perhaps the simplest possible example, they live on land that belongs to a country that defends and otherwise manages it. In that case, paying a basic land tax should be enough. If there are other interactions between the family unit and its society, then other arrangements might need to come into play to allow them to maintain the entitlement for that lifestyle.
In return, he is giving the output of something he worked a few weeks on.
In your example, it would be like the son invented a machine to do HIS chores for him, but then sat around while the rest of the family still did their work
I think where this analogy breaks down and becomes gray area in modern society is when the group unit that benefits gets too large to ascertain where the gains are accruing.
We're biologically wired to optimally deal with groups of ~150 or fewer people.
Yeah, but that person still has to feed and house their family. And in some areas there are "plenty of companies", but not in all.
Back in the late 90s I worked at a place that sold all kinds of automotive parts. Everything from nuts and spark plugs to turbochargers and large assemblies. The secret sauce of this company was a small team of people who worked through thick supplier (paper) catalogs and figured out which parts from different suppliers are in fact interchangable by comparing their specifications. This all went into the database for the sales team's use.
Well one younger guy in this team worked out a way to largely automate his job using OCR and spreadsheets. Instead of taking 8 hours to work through his day's load, he would do it all in an hour or two. Then he'd slack off for the rest of the day.
Soon the manager found out but the manager was not upset, instead the manager was disappointed. Why didn't this employee share this system with the others? Why did he think it was OK to slack off for 6 hours a day instead of doing 4 times as many catalogs? If this employee worked for me, I'd be putting him to work finding other things to automate!
In the past I've had many comments from people saying 'oh he should have kept it a secret' or 'he is getting paid to do X and if he is more efficient then why cant he slack off' or even 'oh no this is a disaster now most of that team will be laid off'
Because the consequences of him doing that are unclear. And since one potential (if not likely) consequence is management would simply retain 1/4 of staff doing this work and fire the rest, why would he share that?
Was there a huge sign at his workplace outlining the consequences of automating anything? An explicit policy that would alleviate such (reasonable - read the article!) fears? I don't think so either.
What was clear, presumably, is that as long as he processed X catalogs a day, he was getting his salary paid. That was what he was hired to do. And so that was exactly what he was doing.
>Why did he think it was OK to slack off for 6 hours a day instead of doing 4 times as many catalogs?
Because this is how work works. You pay someone to do something, and the expectations on the amount and kind of work - and the amount and kind of compensation - are discussed in advance.
>If this employee worked for me, I'd be putting him to work finding other things to automate!
Yes, and that's exactly the problem.
What if there aren't any? What if there are, but he doesn't find them? What if he finds them, but doesn't know how to automate the task? He was hired to go trough books and compare specs, automating his employer's business was literally not his job.
You see, your "reward" is not paying the employee 4X salary for being 4X efficient (you left that little part out!). Your reward is making the employee perform a more difficult job that they didn't sign up to do, presumably for the same salary (since you didn't mention paying them more).
Do you still wonder why they kept their silence?
Our company culture is the complete opposite of that. We want people to help each other. We want people to challenge how things are done. We want to change things all the time, experiment, see what works.
I have NEVER hired someone and said 'heres exactly what you need to do for 8 hours, have at it'. Not even close. All businesses must move forward, lest they die in the dust. The old cushy 9-5 job where you just do the same thing over and over your whole career is dying out quickly.
OK, so you are explicitly making this a part of the job description. Which, arguably, was not the case for that particular employee at that particular job.
>If someone with this attitude worked for me, I'd get rid of them ASAP.
When people are "got rid of ASAP" for their attitude and not due to their performance, that's more than reason enough to keep silent about, well, everything.
Because who knows what kind of attitude the boss might have on that day, or seek from their employees.
---------------------------------- Everything below is skippable ----------------------------------
Now on the me-note: in my current job, I do my best to automate and document processes to save my and my co-workers' time. But, unlike in the case above, that's my job as a software engineer. And I know that when I make things better, I am rewarded - either with a thank-you, a bonus, or joy from improving my own work flow. I don't have to fear being reprimanded or fired for that.
In my previous job, which was a Teaching Assistantship, I went over and beyond trying to improve things (I rewrote the lab assignments that everyone hated, and turned them into something useful and enjoyable) - and got hit with a plain, literal, "it's not your job" from the administration when trying to push these changes. Initiative was unwelcome there.
The moral? I've seen both sides. If you are the manager, it's on you. You create the environment where people will be either eager to be improving things, or will be scared to try (and will keep mum if they do).
>All businesses must move forward, lest they die in the dust.
And so do the employees.
>The old cushy 9-5 job where you just do the same thing over and over your whole career is dying out quickly.
Indeed, and that's why people move on to other jobs. I think the puzzle will solve itself once you put yourself in the shoes of the person your story was about.
>We don't want people sitting around saying ... 'I wasnt hired for that'
But surely you hire people for something? I hope you don't expect your software engineers to, say, clean toilets - and vice versa. And if you do, I hope you pay your cleaning staff as much as you pay your engineers.
Which, again, was not the case in the story you posted (the person doing the automation was neither expected to do it, nor was paid at the level that people whose job it is are).
You won't last the probation period working with us, thank god for that. I'd hate to be in an office full of people who only does what's in their job descriptions and never anything else. We hire people who care about each other and help each other in difficult periods. That's one of the reasons our employee retention is so high.
EDIT: If I thought that cleaning a toilet was for some reason the most valuable thing I could do for the company right now, I would do it.
Every company says they want people like you describe but few actually put the incentives in place.
So your employees (assuming you have any and this is not some hypothetical scenario) won't straight out say those things, they will just quietly do them :)
But we do try really hard to hire people that fit in our culture, and we make sure new employees understand how we work. If someone's just sitting there doing their assigned job as they were trained, they'd be fine but they would probably not get promoted or earn a pay raise every year.
And of course if someone DID need to go because we lost some clients or whatever, those are the ones we'd want to let go first.
The only real exception is employees who are really committed to the vision of the company. Ultimately though that's usually only the executive team and early hires since they're the only ones who (usually) materially share in the actual success of the vision beyond just keeping their job. Most of your frontline employees are not going to get any benefit from sacrificing their energy (and there is a real cost to this) and time to fulfill a vision they don't even really contribute to forming, besides just keeping their job. The incentives just aren't usually there. Furthermore, It's common for founders to be very deluded about how "laudable" the vision for their company is. There are very few companies that act as clearly morally good agents in the world. It's not a given that profit-seeking entities inherently behave in a way that's ethical. I just don't see how anyone could possibly expect employees to be 100% committed to executing on the vision of most b2b or even consumer facing businesses. Especially when they don't really reap the benefits of company success.
And yeah, you can argue that you're buying someone's time and you're entitled to expect 100% of their mental capacity etc... during that time. But like anything else in capitalism, you get what you pay for. There are plenty of other employers that don't expect that or don't have the time/resources/collective IQ to determine that you've automated, and I don't see why your employees wouldn't just go work somewhere where they can get away with doing 1/4 of the work for the same salary vis a vis automation unless you provide some extraordinary benefit just for being a "member" of your company. And if being challenged is important to the employee in question (I'm one of these) I'd just go find a job that pays 4x (or make my own) where I could be challenged. In general, you can't eat a corporate vision and it's just not that valuable for most workers (there really are exceptions, companies that are clearly "morally good", but that's the exception and not the rule.)
Which isn't to say it's fun to work at a place where people are just jumping through their daily assigned hoops. But speaking as an employee, I'm certainly not willing to put in extra effort at a company paying at or below market rate with bland corporate vision/culture and/or uninteresting problems. Which seems to be the expectation of most employers. I'm lucky to work at a company where even though I'm ambivalent about moral character of the product (it's b2b stuff, so morally neutral,) I'm well compensated and enjoy a flexible corporate culture and have interesting technical problems to solve. Ultimately though, most companies are bland (in terms of vision) somewhere on the scale of utterly toxic to tolerable (in terms of culture) and totally boring (in terms of the nature of the 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.
These stories seem to me like management failures — leaders haven’t built the necessary trust.
The employer earns my work by giving me a salary. My work has a value and the employer pays for it.
The minute they stop paying me, my offer cease and they lose any future value I might have brought them.
Maybe it's because I did a lot of freelance and agency work before working a full time contract.
Over here (Montréal) there's right to work laws and precedents that makes it so that those clauses are pretty much null if they keep you from working.
Non-compete pretty much only protects the employers from having a direct competitor recruiting their employees.
EDIT: And I would add, for anyone that has automated their job in this way...what you should really be doing is scaling it up, and finding other companies who are probably paying employees to do the same thing. Then start your own company that does whatever this task is as a service.
Can you expand on this? I don't understand the anology
Perhaps they're saying that the employer has to (indirectly) pay for a parking lot to accommodate them?
Careful, if it gets out that you wrote the code to automate your job as a coder while actually at your job, your company most likely owns that IP.
Yes, in theory. In practice, an employee's power to negotiate wages is limited. At some point, the employee just needs to work to eat/pay rent/etc.
Now, in most areas (of the US), software developers already are paid generously. Even in lower paying secondary markets, software dev are usually paid significantly above local averages.
And, anecdotally, that pay is often for a much "easier" job, where "easier" means less stress and fewer hours than professions that generate similar salaries (engineering, accounting come to mind).
Cause they have more power than you. That's about it.
These tasks might not be worth selling as a service, they could be relatively trivial yet very context specific... I suspect this is the case, and that the real issue is with the employers lacking the insight to realise the these tasks _should_ have been automated and have the initiative to do so as soon as possible.
More specifically they probably neglected to employ people between the grunt worker and executive positions that would _have_ the insight to automate these tasks as soon as possible. That's basically corner cutting in terms of employees, in which case perhaps they deserve to be exploited, the funds are correctly being appropriated to the people who realised they needed to be automated.
EDIT: to be clear I don't find it 100% morally acceptable, going behind the employer like this is underhanded of course, but it can be somewhat justified as I outlined above. I suppose the alternative is to explain to the employer how it should be done and do so and hope to gain some kind of promotion or compensation, but that entirely depends on the moral standards of that company.
For those that might say that a job description sets product based terms for employment, it's rare that they are offered that way. Almost all the job descriptions that I've ever seen (and all that I've written) have some sort of phrase to the effect of, "...and other work as might be assigned." A job description isn't a Statement of Work, they're usually just general expectation setting devices.
?
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.
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.
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?
Hopefully, the president canned him and referee his conduct to the police? Seriously, the less poisonous people like that, the better.
I get the impression from these stories that the dishonest part of what the self-automaters are doing is that they could do other tasks and use automation to increase their productivity, but instead chose to keep their productivity the same and relax with the extra downtime.
Being able to have chef integration tests (or are they considered unit tests?) seems really powerful. But holy fuck does Chef have a ton of (what feels to me like) cruft
So, if you're not building systems at the Netflix or Amazon scale, then Chef might have features and tooling that you don't need -- today. But as you grow and you find you do need those tools, they will be there.
I can tell you that Chef was a key part of the system for taking the Raytheon GPS OCX system and letting us build out an entire virtual datacenter in a matter of hours instead of months. Once everything is racked and stacked and cabled together, just press the "Go" button and everything builds itself and installs itself in a fully automated way.
If you're not familiar with GPS OCX, that's the next-generation ground control systems for GPS satellites -- both the current generation of satellites that is currently aloft and the next-generation fleet that is being developed.
With regards to Ansible, there are many lessons that the Puppet and Chef communities learned years (or decades) ago that are being re-learned yet once again -- like ssh isn't a very scalable communications mechanism when you start talking about handling thousands of servers.
The concept of "just let me run my custom scripts everywhere" is a nice one, so long as you're talking about a dozen or so machines, each of which is a unique snowflake "pet". But when you want to start building a cattle farm, that method stops being so useful.
It’s funny because I would say that Chef has yet to fully re-learn what the CFEngine community knew.
This is not the recommended way to use Ansible at all. Ansible encourages the use of modules, to perform tasks on the server in an idempotent manner.
There are modules[1] for installing packages, creating, 'editing files' and so on.
Running custom shell scripts for everything is specifically discouraged in their documentation.
[1] https://docs.ansible.com/ansible/latest/modules/modules_by_c...
And it is only not fair to the peers whose work cannot be automated, and as someone here said, it's a temporary privilege to be working in programming, we're in a different world, higher pay, more learning opportunities, more leverage than other jobs. But, nothing lasts forever. We're going to be automated away eventually.
The programmer who has extra time from automating his jobs has a choice on how to spend that time.
- Waste it playing games
- Learn other skills
- Work on other side projects
Only the first option is negative to the employer.
I get the impression that the dishonest thing the employers are doing when they become aware of the automation is that they could increase the person's salary, but instead they keep it the same...
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 :).
You've just described the purpose of the entire software industry. Did it really not occur to you that writing systems to automate tasks would displace anyone doing those tasks manually?
Engineering problems just move higher up in the stack. Few people are coding assembly code now days, and in the future few people would be writing in other low level languages.
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.
Progress enables productivity which is a net win for everyone, your work has contributed to productivity a LOT more than the work of the people who needed to move on. Without technology we’d almost all be in poverty.
In the end you're probably right for a population of people. I'm not talking about that, though - I'm talking about very specific people with families to feed.
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."
* 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.
In Australia these benefits have largely gone to land owners, as opposed to capital. See this chart:
http://www.prosper.org.au/wp-content/uploads/2009/01/unearne...
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.
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?
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%.
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.
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.
Would you contract this guy again?
- If ready-made robots (and scripts) were available on the market, the employer would definitely use that instead
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.
Also, they're not my employee. I contracted them for a one time job. Totally different working relationship.
I value outputs.
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.
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.
Some cognitive tasks become magically easier if we reframe them in terms of cheating. We seem to be hard wired for this.[1]
It's not a question of logic at all, but of human nature.
This is why it seems unfair to us when people 'use robots' to do their work.
[1] https://en.wikipedia.org/wiki/Wason_selection_task#Policing_...
-- Adam Smith, Wealth of Nations
https://en.wikisource.org/wiki/The_Wealth_of_Nations/Book_I/...
1. The modern term for these devices is the perhaps more familiar "steam engine'.
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.
A boss’s prestige is in how many people they manage, not how many scripts they run. That’s the key to understanding these kinds of decisions.
If you create something that generates continuous value for your employer, you should share in that.
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. :-)
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 :(
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.
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.
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.
The first 2, they lose the job.
The last 2, they lose the time-freedom.
In all instances, is there no good reason to tell of 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.
I've done it a bunch of times, sometimes by accident.
In one case I was going to be assigned to do testing every evening. But I wanted to go home at 6 every day, so I automated the tests on my first day, then came back in the morning and started 'working on my next task'; never realizing that previously the testing job had been a full time position.
I ended up doing about 5 people's worth of work there that summer.
Of course, it's probably because the project wasn't particularly organized, and our team was explicitly given a free hand to find inefficiencies and fix them. Still, it's a nice story to tell people ;-)
Granted the value created by such tasks usually isn't fairly compensated so there are a lot of societal issues.
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.
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.
This is completely bewildering for me. All managers I've had were always eager to pile on more work on my desk when I was starting to look like I was finishing something, sometimes to a fault.
Is it a US thing? Have you guys experienced something like that? What is it, something like having to keep people around to justify budgets?
In other words, I am automating away the job I don't want to do, to focus on the job that I want to to, and that will bring more value for the company. I don't expect the workload to ever decrease, just that our team will be able to tackle bigger issues.
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.
Once you've shown them that the job can be done easier/faster/cheaper, they will insist on that as the new standard.
Rinse and repeat until you are penniless and they have all the money.
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.
You're welcome. Now, get back to work, you slave! ;)
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.
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.
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.
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.
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.
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.
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.
- 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)
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?
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.
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.
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
Did you really see a lot of such cases??
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.
Do devs in actual programming positions do this?
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...
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.
> 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.
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 :-)
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.
https://medium.com/p/meta-executable-processes-for-software-...
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.
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.
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?
Edit: wew, instant downvote. Care to clarify?
- 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.
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.
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.
I learned that I was taken advantage of.
Also, it seems like a huge way to waste your life. Find another job where they can actually use your skill set to do something meaningful.
Why is it ethical for companies to get away with paying you FAR less than the value you produce for them?