My dream was always to be hired into obscure government bureaucracy and automate the data entry job away, while hiding it. After that, you basically exist in a free incubator.
Imagine the software you can write, if freed from societies expectations of sweat, tears and busy work. Not to be rich, just to be technical excellent, productive and at peace.
I wonder why this has not yet happened with open source. If a sufficient enough part of the public uses your software, the state offers you a maintainer role. Nothing big, but enough to life on and do work.
That's roughly my current situation. My humble business does well enough to let me focus on what feels right. I haven't thought about the income-generating bits for a while now.
It's nice to do good work and not pollute it with the usual growth strategies, to tell advertisers to sod off, and to obsess over details of your choosing.
This completely changed how I work. If it's sunny outside, I'll forget about work and go ride my bike. But I'll also take a day during my vacation to implement an idea because it's just can't wait.
I don't know how other people work, but I found my perfect way of working. I've never been so productive before.
I’ve met at least two developers living that life. One worked for a big German corporation. Sometimes he wouldn’t have any work to do for weeks. He got the authorization to work on a hospitality exchange network while in the office. Another one knew how to live on little money. He lived in squatted houses and was an adept dumpster diver. His lifestyle cost him one day of paid work per month. The rest of the time was spent volunteering code, among other activities.
I was deeply inspired by these lifestyles, but it turns out not working for a boss doesn’t fit my personality. I’m too much in need for social validation. Work and suffering are a religion where I live. Programming makes me mostly anxious and I need to be surrounded with colleagues to get comforted. Consumerism is also a religion. I have a hard time being surrounded with people who are able to indulge in consumption while I’m not.
Hey, do either of them have a blog? I'm interested in these lifestyles, especially the dumpster diving dude. My wife wouldn't let me squat or dumpster dive but I could always live vicariously through him.
He used to have a blog but no longer writes on it. There was quite an active community around Trashwiki but I haven’t had a look at it in a while. There’s also a dumpster diving subreddit, but it’s centered around finds rather than lifestyle.
I can relate to the vicariously living through reading part of your message, I love coming across people who share their alternative lifestyle!
> free incubator (...) freed from societies expectations of sweat, tears and busy work
The fact that the most successful ideas&products weren't born in such places might cast a shadow on the attractiveness of this perspective. I think that without a challenege the mind is at risk of atrophy.
Einstein was a patent office clerk. Gregor Mendel was a monk. Sergei Brin had a scholarship. The myth that struggle breeds success is just a narrative intended to keep working class folks grinding.
You do realize Einstein was always studying? Sergei Brin worked like a maniac. Struggle breeds success. Not everyone successfully picks the right thing to struggle on.
None of those things were products of their work environment.
Einstein was able to always study and Sergei Brin was able to work like a maniac precisely because they were able to remove the restrictions of paid technical labour that drains your brain before you even get to the interesting stuff.
Exactly. Even if I want to do something in my own time that's similar to my work after hours, I have no personal energy to devote to that unless I'm rested or very desperate. It's rare that I actually boot up an IDE on my personal machine.
Absolutely yes, it is. Or if not their "fault", then at least it is the direct cause for me not having any more energy afterwards. You don't expect a mine worker to come back home and do a bunch of manual labour, why would you expect a mental worker to do the same?
You must be joking. You can choose to leave the company and do whatever you want with your free time. I know craftsmen who come home after work and work on their own craft.
Programming is no different. Other developers code in their free time. If your low energy maybe you need to fix that part?
Africa should be delivering ground breaking work all the time right?
This idea that x person worked a little harder than the rest and therefore he is successful is laughable. There is a range, say 5% or 15% or even 50% ‘worked more than the rest’, ok so what? Do you think you are within 5% or 50% of working x hours more per day before you become the next tech billionaire? You are not. It’s not that easy.
Oh and then there are the struggling artists of the renaissance which all came from the illiterate peasantry struggling to feed themselves.
And the media common folk of today, who come up because they struggle therefore they act, and everyone we see in TV was a nobody before their first big role and just worked really hard right?
Or the government families which somehow if you are the son of a governor your chance of being in government and a high ranking official far outweighs any other factor.
Or if your parents are rich chances of you being rich far outweigh anything else…
But no, alas I’ll let everyone know we gotta push just a little harder and we’ll all be rich.
Struggle breeds stress, which intern breeds health issues. If we didn’t struggle the world would not end, innovation would not stop, WALL-E is just a cartoon.
My last sentence clearly states not everyone picks the right struggle. Also not all countries have equal opportunities the world is not fair. I simply was referring to the 2 examples the original poster was referring to.
Struggle & synthetic stress prevents large scale strategy pivots though.
You need to be able to let the subconcious do its thing, for which it needs peace, quiet and freedom from stress. Difficult to do the step back otherwise.
The stress returns, when things then get traction, so i guess the truth is - alternation between stress free "creative" periods and stressy "realization" periods?
>freed from societies expectations of sweat, tears and busy work
Struggle implies unsuccessful efforts. These men were not bound to busy work, crying for help. They had comfortable settings and could focus on what mattered to them. OP wants just that.
Arguing that "get out of comfort zone, grind, struggle" is the way to advance society is disingenuous at best.
Einstein was working in a patent office because he had trouble finding any work related to what he liked doing after his applications for various professorships at research universities failed.
A full time phycisist already tends to work a lot of overtime hours to get anything done, while already doing that as their main fulltime job activity, so with 100% certainty Einstein grinded like a madman in afterwork hours to do his actual research. This is also why he quit that patent office job as soon as he was able to.
Not to criticize your approach. genuine 0.1x programmers allow 10x (aka 1x) programmers to exist and get a lot of money doing a normal job.
This whole 'grind' narrative is construed as a distraction. "Stay busy. Don't raise your head. If you're not to exhausted to have an original thought you don't deserve to be fed and housed." This is some perverse manipulation.
You should not conflate focus and effort with physical busy work. Grind means literally to wear down physically. Theoretical physicists don't 'grind' by any stretch of the imagination.
People should absolutely be allowed to be comfortable, free of immediate concerns with acquiring resources to survive. As OP puts it, 'freed from societies expectations of sweat, tears and busy work'
Arguing against this right is drinking the elite's cool aid. If you don't profit from exploiting the working class, you shouldn't see a problem with setting them free.
Nobody said you don’t deserve to be fed if your not the greatest programmer of all time. Your skills should always be improving. Technology moves fast and so should you.
...because most people don't have that option in the first place. If 99% of population grinds away instead of having literal free lunch, of course most of the ideas will be from that.
> I think that without a challenege the mind is at risk of atrophy.
Not everyone needs external challenge of "afford rent". Some people are entirely fine with picking their own goal and striving for it, without their survival at stake.
That's how I became a software developer. I was working for a big tech firm as a data entry "specialist". Everything (except some pricing calculations) was done manually. I was hired as the 7th member of the team. It started with copy/pasting some simple VBA scripts to automate small tasks. In a year I managed to automate most of the tasks. More notably: A monthly task that took 2 days(and quite prone to human errors) of the entire team into a less than an hour job for a single person. And automated discrepancy checks between the data sources.
It was quite satisfying and made me realize that I should be doing this for a living. I quit that company for way better pay as a software developer. I don't know if I'll be able to find such a job again, but I really enjoyed it.
I never hid the scripts. The automation was out in the open and everybody in the team was making use of them.
I quit because I didn't receive pay raise and wouldn't have in that position(EDIT: They wanted to promote me to team lead(people management), but it is something I'm not interested in). Plus with the skills I've gained I managed to get a better paying job.
Maybe used to be like that (or maybe it's just prejudice against researchers), but from what I'm hearing it's pretty far from the truth today.
Before you get a tenured position, you're basically stuck in the publish-or-perish rat race and when you eventually get a tenure, you now have an enormous responsibility towards the younger non-tenured reseachers of your department, who will eventually lose their job if the department isn't “productive” enough, so unless you're a complete insensitive assh*le, you'll still be under pressure.
It sounds like you’ve been heavily influenced by the tone regarding academia here on HN. It’s one of the nuances of HN that people “hate academia” here. (Admittedly CS has a strange relationship with academia in that the pay discrepancy is so outrageous between industry.)
Some people love academia. My PhD mentor is as happy as a pig in mud in his academic role. He only has to teach every other semester, and his course/lecture plans are solidified such that all he has to do is recite his notes beside slides and answer questions. He has to schlep to the classroom two days out of the week in these semesters, but his classes are back-to-back so that even those days are spent mostly where he likes. All of the rest of his time is spent happily “doing research” in a domain in which he’s a world expert. Publishing is a specialized sausage-production manufacturing domain, but if you enjoy the subject matter like he does (and I do) it can be a low-effort byproduct of effectively playing with code and ideas.
It sounds like your PhD mentor is one of the lucky ones. My understanding is that academia used to be like that, but it is unusual to get away with such a light teaching load these days. Academics also tend to get loaded up with other bureaucratic "service" tasks that heavily take away from the available research time. Finally, getting the job in the first place is next to impossible (though that might start to change as the people who have been holding the positions for decades are literally starting to die).
Fwiw, an entry-level tenured professor in France has to teach about 200 hours/year. This is a bit daunting the first year, but as you gain experience it's not that hard. Notice that this also includes hours for mentoring undergrad interns, masters students, etc. So if you are active in research, it's quite easy to cover nearly half of this teaching load for "free", thanks to students that want to work with you in your little projects. It's an awesome environment to be honest!
Your point about bureaucratic service positions rings particularly true I think. It’s part of the job description and actually why I’ve decided the career path is not for me. The academics I’ve seen thrive all seem to enjoy that part of the job (my mentor, for example, goes out of his way to get involved in standards organizations and other international/academia-related groupings of bureaucratic process).
At my research university, even associate professors (not sure about the details of what’s tenure track) don’t have to teach that much. There are actually “teaching professors” here who’s sole responsibility is teaching without research pressure, and they still only teach two classes per semester (admittedly, those classes might have 300 students).
> I wonder why this has not yet happened with open source. If a sufficient enough part of the public uses your software, the state offers you a maintainer role. Nothing big, but enough to life on and do work.
It didn't happen because people already do it for free, so why overpay?
Those here talking about what the author is saying is actually a 10x engineer are missing that he's criticizing the meme of a 10x engineer [0] over an actually 10x more productive engineer.
In a way, it's more of a joke article responding to a joke meme that has some good points over actually being a fully serious article criticizing actual 10x more productive engineers.
Software folk taking the 10x thing seriously is akin to PC gamers unironically calling themselves the "PC master race". I have a hard time taking that conversation seriously.
Do you guys work on the same industry as me? There's easily a 10x difference between the best guy on the team and the worst guy who's about to be on the performance plan. It's a real thing. A lot of programmers really suck. I interview them and wonder why they're in this industry to begin with. I'm easily 10x those guys, they struggle with for loops. Then there are some superstars like Evan Wallace who created esbuild, churning out some 50k lines of code in a year, while working full time as CTO of Figma. He's 10x me. So there's more than a factor of 100x there without getting into the really important part. Solving the right problem. That's really hard, and after twenty years I'm still trying to get a handle on it.
It's more than 100x really, because of you took one of those guys who can't grok for loops and asked him to create esbuild, they will never be able to do it.
There's a lot of leverage in software engineering, and a lot of room for difference between people.
The problem is that it's reductionist. A CTO's productivity on a side project could be enabled by good on-call engineers, a CEO and board who don't demand 80 hours a week of work, a home situation that's stable and supportive, or a lot of other things. Transfer Evan Wallace to a company that doesn't fit him, give him some really dumb KPIs, and his productivity would drop (briefly, until he quit). Fix the personal and professional environment of the employee who can't do for loops and their productivity might rise.
The idea of a 0.1x developer, 1x developer, and 10x developer sitting frozen in amber beside each other, ungrowing and unchanging, never responding to their work environment, always at fault or worthy of praise for any differences in personal productivity, is ridiculous.
You're building up a strawman and then knocking out down. Obviously people perform differently depending on what things they have to overcome, and people also have good and bad days. For the purposes of my argument, it didn't matter why differences exist, it just matters that there are differences.
My problem with the label is twofold: it blames individuals for systemic problems, and it suggests 10x is some immutable trait.
You said that there's a 10x difference between the best and worst member of your team, in response to a post saying that the concept of 10x developers is hard to take seriously. I assumed this meant you thought calling the best member a 10x developer was a good idea, which is what I disagree with.
Are you saying that calling people 10x developers is not a good idea, but there's still a 10x or greater difference between the productivity of the highest performers and lowest performers within a single team when observed over a couple of years? I agree, but that argument's a very strange one in the context of the post it was responding to.
That’s not what 10x means to me. It means 10x the median productivity, i.e. 10x a competent programmer.
I don’t think anybody can dispute that 10x programmers exist, Bellard, DJB and Carmack being uncontroversial examples.
What’s controversial is the distribution. Are 10x programmers bound to become famous through their outsized contributions, such that their number is very few? Or are there a large enough number of 10x programmers working in obscurity such that you might have one on your team?
You don't ask 10x programmer to do 10x more forms or 10x more report generators than median programmer. You ask them to do the hardest things that your median programmers wouldn't be able to do. You all them to do the switch to new framework, you ask to conceptually change the way you make those forms and reports and save 10x or 100x more time in 6 months.
> That’s not what 10x means to me. It means 10x the median productivity, i.e. 10x a competent programmer.
There are quite a few engineers/devs out there that produces negative net value, when taking into account management overhead and other resources consumed (even when ignoring their salary). Some of these are just in the wrong place, they don't have the talent, skills or motivation to work well with their team, and but might be "competent" in another team.
Even at the median level, output may often lack creativity and inspiration, and add relative little value. The functions they do may be easy to oursource, replace by standardized software or could be built by better developers much more quickly and with higher quality.
I think in most companies who do software development, at least half of net value is generated by the top 5-10% or so developers. (Making them 10x engineers compared to the median). These are the ones that drive new ideas and approaches successfully (instead of chasing cargo cults for no benefit), they are the one that write the code that other developers imitate and build on top of, and they are the ones that contribute to team engagement and cooperation. (Or at least 2/3 above.)
As for the number being 10x the average developer, that's much lower, since the top 10% pulls the average up quite far from the median. I would guess 0.1%-1% is 10x the average, depending on company.
These would be the ones that are able to identify and solve problems others are not even aware exist (or have given up on), the ones that understand the business they're in better than most product managers, and actively drive development of killer apps/features that others didn't even consider. Often they're entrepeneurs or leaders as much as developers.
There are people who can attack new problems or develop completely novel solutions, and those who are capable of solving problems that that might not technically be new, but they require deep knowledge of several disciplines.
And there are people who are simply incapable of doing those things. They might be adequate programmers, able to work productively on existing projects and variations of solved problems, fine tune them, solve difficult bugs, make them work real nice. But it's not the same thing, and it's easy to see when you have worked with the former types.
> Yes it is absolutely possible, for particular problems.
When I said infinite is impossible, I meant in absolute terms, not relative to somebody else.
n-x-engineer means that:
productivity_of_n-x_engineer / productivity_of_reference_engineer >= n
(assuming the reference isn't negative)
etc
So, I'm arguing that the numerator cannot be infinite, so if n is infinite, the denominator has to be 0. In that case _everyone_ with positive productivity would be infinite-x, making the term kind of trivial.
I'm not arguing that such a situation cannot occur for some role, it can certainly happen that a company fills 50% of more of engineering positions with completely unproductive people.
And if, as you seem to do, measure this per problem, not per employee, it is really common. There are a lot of technical problems that only a small percentage of engineers can solve. Even then, though, even less gifted engineers may find some other technical solution that addresses the same business problem well enough to provide more than zero productivity.
> When I said infinite is impossible, I meant in absolute terms, not relative to somebody else.
The whole thread is about relative terms, including when I said infinite-x. And the context is clearly about certain worthwhile problems, nobody talks about a 10x engineer as someone able to make a trivial phone apps or web pages 10x faster than than average.
> The whole thread is about relative terms, including when I said infinite-x.
Relative means numerator/denominator. My first reply was simply breaking that down into parts, aruing that the numerator could not be infinite, and that the denominator being zero is not a very interesting case.
> nobody talks about a 10x engineer as someone able to make a trivial phone apps or web pages 10x faster than than average.
Actually, that's precisely what I think a lot of people who hear the term interpret it as. Especially from those who reject that the 10x engineer exists.
And there are quite a lot of engineers out there that believe that all any software engineer is doing, is to follow detailed instructions/specifications for some product, whether that is to make trivial web page or improve how gcc optimized code on a new cpu architecture.
While in fact, the most productive engineers out there do NOT follow such specifications from others, but rather develop something revolutionary based on their own ideas. You're not likely to find 10000-x or better software developers that don't do it like that (I would argue that people like Linus Torvalds or Elon Musk would rate at around the million-x level, but not infinite-x )
I didn't say the numerator could be infinite, because again, the whole thread was talking about the relative change. Pretty obvious from the name, 10x Pretty big hint there, it's clearly a ratio.
And what I was talking about are very complex or new problems, and here are absolutely infinite-x people. Things where the average engineer will create exactly zero value on over time. I don't know about Musk, but Linus is of course one of them. Task someone to write a scalable distributed version control system before 2005, and the average engineer will be incapable of doing that.
If you wanted to talk about something else entirely like working on simpler things, fine.
"Productivity" could be defined as the value (typically monetary value) that the value of the company is generating (before salaries) based on the contribution of that resource(engineer in this case), per unit time. Future income should be calculated using a present-day-value approach.
The productivity of a single engineer could be defined as the reduction in company value generation from removing that person from the company (assuming the company is large enough to have multiple people available in each role). Rank order this, and you can define the 10x as those whose removal would cost the company (before salaries) >10x more than the removal of the median contributor.
Note that this definition is based on productivity within a given company. A single person could be a 10x engineer in one company, and a 1x engineer in another. Some companies require engineers with very deep understanding of compter science, maths, statistics or physics. Others benefit from engineers that are domain experts within their business domain, and yet again other companies may primarily need engineers who understand and can work with people of all backgrounds.
Unfortunately, yes; there's a lot of companies - "enterprise" - that will hire a contractor which intends to make as much money as they can. They'll send a couple decent engineers, impress the client, they will ask for more, and they'll start filtering in more and more mediocre or outright bad developers, whose lacking skill is compensated for by the good ones.
But I'm 99% sure the enterprises are aware of this. They want the good developers, but realize they have to deal with bad ones too, and are willing to pay the cost and accept the risk it brings.
I mean outside of that it's fairly normal that a team will have a healthy mix of seniors (who do the meetings) and juniors (who do the work), but you'd still expect a baseline of quality and a technical interview there.
The worst programmers mostly work in very low paying jobs. You wont find that many of them in higher paying jobs since they are so easy to weed out in interviews, only desperate companies hires them.
The tragic thing is: Most of this industry takes the concept of the 10x, 100x developer very seriously.
Just talk to a manager and slide that into the conversation, I bet 9 out of 10 will recite the gospel unironically. I am guessing these numbers aren't that better for software developers.
Because all this can easily be mixed with job performance and effectiveness which are obviously real things.
A fun comparison is that Usain Bolt, who literally wins gold medals, is not even a 10x runner: a tenth of his world-record speed 100m works out to a brisk walk.
Depending on the source[0], average walking speed in older adults is about 0.8-1 m/s. The world record is 100m /9.63 s = 10.4 m/s, so it would not be at all surprising if your grandad were just about 10x slower.
Since the "10x engineer" is defined relative to other engineers, the right comparison is probably more like "other runners" than all people, which of course narrows that gap even more.
Compare a programmer with good autocomplete to a programmer who has to keep stopping to look up documentation online. That’s a double digit % improvement just by installing the right plugins.
A good editor (and the ability to use it efficiently) is a relatively small factor, comparable to the ability to type quickly.
Much greater leverage can be found in the ability to innovate, to have the undestanding needed to quickly select a good approach to solve some problem and the social skills needed to lead a team or company in a direction where they can (to re-use the term) leverage such new innovations in ways that generate maximum value.
For instance, if you have a team that uses RESTful java microservices on k8s for EVERYTHING, many compute heavy or IO heavy tasks may require massive clusters to run a data processing pipeline.
If you're the engineers that identifies this as inefficient, finds way to build the pipeline using a more suitable tech stack, and introduce this stack to your company, you could the infrastructure cost of a company by millions per year. That's kind of comparing the use of cargo ships to mules for transporting goods.
And if the tech you introduce also enable 10 other devs to develop 3x faster, this alone would make your effort as valuable as having at least 20 more such engineers. (20x).
The reason I don't like "10x engineer" as a term is that it's often presented as an attribute of the person, but I think it's really often an attribute of the situation.
People obviously differ in abilities, but those differences are massively exaggerated by the environment. The best engineer at Twitter probably isn't getting much done this month. Conversely, a few people who were solidly average at their last job are probably rocking it because they've landed in a place where the work is a good match for their skills, the path forward is obvious and feels secure, and they're getting the needed support from their colleagues.
Or build the right tool for a job, for others to use. Imagine a world without tractors. The engineer that designs a tractor and builds a tractor factory would be a million-x farmer, while the farmers who buy the tractors become 10x farmers, until the others catch up.
Innovations and inventions, even in a very small and local context, may easily generate >10x more value than the output of a stereotypical "code monkey" who at best delivers according to a well written documentation.
When he describes what he does he's describing a 10x engineer. 10x doesn't mean you write 10x more code, it means you deliver 10x more problem solutions
Unfortunately even the most prolific and very successful CEOs and management in our industry often fail to understand this.
A couple years ago I was rejected from a 3rd round interview for a very large company that should have known better for the primary reason that my "coding challenge" exercise didn't meet an arbitrary lines of code minimum, despite meeting all of their requirements.
And of course we have the recent example of a certain chief Twit firing engineers based on LoC.
Someone should enlighten them that less LOC is good in solving a problem, granted that the code is also more maintenable due to smaller surface area and no bad shortcuts were taken. Yes, it’s hard for management types to get that, perhaps because most of them want the problems entrenchability creates, and that for their own … benefits.
I had a recruiter ask me a few days ago, on behalf of the HM, how many lines of code I've written in my career. I told him that's a very weird question, and said nothing else. Needless to say, they're passing on me.
I just pair programmed with a student to help them get their code working. The first thing I did was delete unused variables and non-critical code that was distracting from the core algorithm.
After removing most of their print statements, it was obvious what the program was doing at run-time.
It's much harder to delete your own code than someone else's, especially when you're unsure of what's important.
Deleting stuff, compiling often, and proper indentation -- things beginners don't think they should waste time on, but which actually would solve most of their problems.
In my interactions with beginners, adding more tools has never helped them learn faster. That goes for linters, autoformatters, debuggers, and version control.
Manual formatting and printf debugging goes a long way, and takes only foundational understanding of the problem, not the manual for another tool.
(Don't get me wrong: I love those tools. For a person who already knows them, they're a productivity multiplier. But a complete beginner usually doesn't have that knowledge.)
It's good to have a teacher who can recognize the moment when print-debugging is no longer sufficient and a real debugger will solve the problem immediately.
Introducing debuggers too early leads to lots of "why do we need this? I can just print..."
It's a catch-22 though, because ideally you'd learn the debugger in an intro course, but intro course problems can usually be debugged with simple print statements.
To "strive to be a 0.1x engineer" means that whenever you are presented with an option, you intentionally choose the worst option; the one which requires the most work, solves the problem in an inefficient way, doesn't align with the direction of the project and which will require constant maintenance and will need to be rewritten within a year or 2.
10x developers tend to code really slowly, much more slowly than 1x and 0.1x developers (especially when working on the critical parts of the project). What makes them 10x is that once they've written some code, it solves the problem in a near optimal way, it aligns well with the direction of the project (it's easy to build upon), it doesn't require much or any maintenance and it doesn't need to be rewritten for a very long time (e.g. 5 years or more provided that there is no crazy startup pivot on the business side).
This also highlights an important point that not all companies need 10x developers. If the company wants to build a large but straight forward project (a lot of work but without any significant technical challenges), you may not need a 10x developer; you may be better off just hiring a bunch of juniors who can put together a disposable MVP quickly. 10x devs are good when you have a sufficiently complex project; which I would argue are most projects, but not all.
A 2x developer is like a sprinter. A 10x developer is more like a marathon runner.
That's not the definition from the article. They talk about knowing when to say no to a project, the concept of identifying value and trying to do valuable things.
I always enjoy the various ways people mythologize the 10x developer. Everyone has their own apocrypha about what makes a 10x developer and how they behave and it is all so different.
Maybe there are a few out there, but mostly, they are myths constructed from stories that are constantly retold and changed until no one really knows exactly what makes a 10x developer, but are convinced they can intuit it when they see it :)
Source: read the comments here. I caught at least 4 different explanations of what a 10x developer really is or does.
It's incredible how confident people are about the existence of some phenomenon when there is a total lack of credible sources about its existence (or even a commonly agreed definition for it!)
There is no value in reinventing the wheel, and not doing so gives you time to do other things that will give you value so someone should always be asking the question of if something should be done.
I mean it's a bit absolutist but that's to make a point; it's like the antithesis to Jim Carrey's Yes Man. A lot of developers are over-eager, simply looking for opportunities to work extra hours, pull an all-nighter, and show off to their peers. A lot of companies are over-eager to keep cramming features into their product, to keep pumping up those numbers, to build and release more and more services and products.
The nuanced point of view is of course in the middle; don't pick up more work or responsibilities without knowing the full story, without having done due diligence, homework, looking at alternatives, etc.
When I say "sounds like hell" I'm not necessarily looking at it from the point of view of what's economical, but rather from the point of view of job satisfaction.
Like: If a decision is made not to automate something, someone is going to have to do that boring repetitive work that could have been automated. The person making that decision not to automate is usually not the same person having to do that work. -- The former will usually be some kind of manager or owner, while the latter will usually be some kind of IC-level engineer or bookkeeper or something like that.
If a decision is made not to build that feature that a lot of customers requested, someone is going to have to explain to customers on a regular basis why they can't have their wish (usually some kind of sales person or customer service representative or something like that).
That's where the sadistic element of the Mordac character comes in.
There's a related problem that is discussed at length in the book "Peopleware" [1]: Often, from a strictly economical standpoint, you might be in a situation where you'd say "quality level x is the quality level that the market is willing to pay for, while any higher quality level is uneconomical". You might then be tempted to ask your employees to dial down the quality level of their work and produce worse work than they're capable of. -- The book argues that this is almost always a bad idea because of the demotivating effect. You'll get lower productivity and won't realize the cost-advantage you were hoping for in your purely economic analysis. Or to put it differently: Dialling up the quality-level in your product from the level you economically need/want to the level your employees are capable of will often pay for itself through increased productivity through increased motivation.
So, if you ask your employees to be 0.1x employees, you will truly get 0.1x employees. But the result won't be that you'll accomplish more with less, but rather that you'll do less and accomplish less due to lesser productivity.
"If a decision is made not to automate something, someone is going to have to do that boring repetitive work that could have been automated."
You did read the little sentences under the big bullet points, right? It's "first, let's see if it's smarter to not do the work at all, before we commit to automating", not "don't automate the boring stuff"
I did read that relativization, it just didn't pass through my bullshit filter.
This is because of a lifetime of managers telling me things like "before we do this thing that you want to do, please first conduct a fact-finding mission to consider the possibility that we don't actually need to do it". My mental bullshit filter turns that into just "no".
That's because the fact-finding thing only has two possible outcomes: I come back with evidence to support their no-position in which case: great job on that fact-finding. Or I come back with evidence to support my yes-position, in which case, guess what, there's something wrong with my fact-finding. Then they decide "no" based on their preconceived notion, plus they get to look very reasonable and evidence-driven. -- Conversely, a "yes" always looks very different. It's always "yes" from the start.
IMHO its not actually that hard to figure out what to work on if you talk to enough people. There is often some "L6" (the person six levels down in operations) who already knows what needs to be worked on but nobody has ever asked them ( https://podcasts.apple.com/us/podcast/episode-1-six-levels-d... )
FTA: this is the TL;DR and there's a lot of truth in it.
Given the cost of maintaining everything we build, it would
literally be better for us to do 10% the work and sit around
doing nothing for the rest of our time, if we could figure
out the right 10% to work on.
But then what will I put on my resume and how will I answer all those behavior questions in STAR format so I can pile a bunch of new tech into my next job and then rinse and repeat?
It works like this in scientific research too, except the worthwhile stuff is only 1%, not the full 10%, so that's another order of magnitude worse X.
So basically if you develop for 100 days, only one of the daily milestones will actually be useful, and it may or may not happen much earlier than when all 100 days have passed. Also you may or may not realize which 1% it is right away either.
But once you've got it, that's the critical 1% that allows you to go forward the very next day.
And the next day is what really counts, otherwise zero progress toward the larger goals.
Even after a large goal has been reached, you might still get the feeling that you wasted a whole lot of days along the line there. Knowing that if you just had, and recognized, the key milestone the very first day of the project, you would be as much as 99 days ahead by comparison.
Now, doing the math, if you work one tenth as much it will take 1000 days to accomplish the same thing instead.
These orders of magnitude are killing me, you must avoid even conceptualizing the possibility that 999 days could be wasted now.
Which is OK, for some things I do that too.
Other things I like to be a lot more than 99 days ahead on.
Having worked on my share of kitchen-sink SAAS I'd say it's hard to cut back on features when table stakes are always raising. Clients often want a buffet of different things.
If you over specialize there isn't much moat. Which is fine for small shops. Though it does limit market size and growth potential.
Which isn't to say don't trim the fat. Just measure twice before cutting.
Man that applying the 0.1x part really reminds me of being in mgmt. I felt like my job was more like chief disappointer and garbage tosser of ideas. People forget that its easy to sit and spit out 100 ideas at a session. The hard part is throwing away the stuff that is good but just doesn't need to happen for various reasons.
I've been doing this for more than 25 years and the income gains for being productive are miniscule. Strategizing your job hops carefully is what gets you the 1/2 million.
to offer an alterative: write all the code you want and throw it away. Don't get attached to the work of your hands. The code is the water; feel the problem, move towards the value.
Imagine the software you can write, if freed from societies expectations of sweat, tears and busy work. Not to be rich, just to be technical excellent, productive and at peace.
I wonder why this has not yet happened with open source. If a sufficient enough part of the public uses your software, the state offers you a maintainer role. Nothing big, but enough to life on and do work.