I have spent some percentage of my life attempting to rewrite all software from first principles up.
Software is so spectacularly broken. Applications that don’t let me adjust the position of a little button for my work habits. Why is that impossible!?! A global software and commerce system, where you can buy candy or transfer $ billions, both with cute warnings like “Please, oh, please, sir! Please don’t hit the back button!”
I can sum up the results of my quest quite simply: “The rewrites continue…”
Is this chasing windmills? The case for that seems solid on the surface, but…
It is true that every rewrite of a specific set of features, or a platform for enabling better support for efficiently and correctly commingling an open class of features, inevitably runs into trouble. Some early design choice is now evidently crippling. Some aspect can now be seen to have two incompatible implementations colliding and setting off an unnecessary complexity explosion. Etc.
But on the other hand, virtually every major rewrite points to a genuinely much improved sequel. Whose dikes keeping out unnecessary complexity hold up longer with less finger holes to plug, for a better return. Before its collapse.
Since there must be a simplest way to do things, at least in any scoped area, we have Lyapunov conditions:
Continual improvement with a guaranteed destination. A casual proof there is a solution.
It’s a dangerous phantom to pursue!
——
It would be interesting to compile a list from the heady 90’s, when corporations created boondoggles like Pink and Cyberdog, and had higher aspirations for things like “Object Linking and Embedding”.
You just don’t see as many romantic technological catastrophes like those anymore. I miss them!
Yes. Well, "tilting at," jousting specifically. The figure relates to the comical pointlessness of such an act; the windmill sail will in every case of course simply remove the lance from the rider and the rider from the saddle, and turn on heedlessly, as only a purblind or romantic fool could omit trivially to predict.
> You just don’t see as many romantic technological catastrophes like those anymore.
The 90s were a period of unparalleled economic surplus in the United States. There was more stupid money than at any other time and place in history, and stupid money always goes somewhere. Once that was tulips. This time it was this.
> I miss them!
I miss the innocence of the time, however amply undeserved. But I was young myself then.
> I miss the innocence of the time, however amply undeserved. But I was young myself then.
I see things slightly differently.
Big failures whose practical and theoretical lessons and new wisdoms are then put to use, more carefully, ambitions unabated, teach things, and take technology to unexpected places.
But big failures, institutionalized as big failures, become devastating craters of resources, warding off further attempts for years or decades … but only after the fact. That didn’t need to be their legacy.
The abatement of American ambitions is something the world has long, not to say desperately, awaited.
Not that Americans should not aspire; indeed, the world has long loved us best when we dream most generously the utopias of which we forever will dream as long as we call ourselves Americans. It's only that generosity, not the reverie, of which we've lately lost the habit.
I don't know if this is post-hoc justification, but I see myself as somebody who wants to know what everything is and how everything works - so to me, re-implementing (and always failing to take it to completion) is the means to an end. I think I spent the first 25 years of my life studying, so learning has become the goal itself. Work is there to provide funds to support me while I learn. Re-implementing the basics of something is a terrific tool for learning how it works.
If you're looking at really from first principles, it's hard to beat forth systems.
You can type in Plankforth (https://github.com/nineties/planckforth) in a hex editor ie. this can be built from zero software, by effectively morse-coding it into bare memory.
Forth has been a great inspiration. A demonstration that great flexibility, and low level control, can be had with very low overhead or complexity.
As you note too, Forth is also useful as a counter demonstration of how important abstractions are. Without powerful abstractions (or simple abstractions that can be composed into powerful abstractions), Forth fails to scale, most especially across a team or teams, and for any expectation of general reuse, beyond basic operations.
The first version of Forth I used I wrote myself, which is probably a common event as you point out. Forth language documentation is virtually its own design doc.
Lisp is the other language I began using after buying a book and writing my own.
Thanks greatly for the links! I will be following up on those. Any insight from anywhere.
This, but with proper balance. TBH, you can live a happy life if you just stop caring about every technical problem, but that would make you unimaginative and passive. Just make sure your pick a hole (or two) you're gonna die in.
Amazing piece of text. Honestly, I saw myself in everything you wrote. The struggle, the attempt to write a single line of code to make it perfect, durable, etc. it never works at the first try...but man the joy of having the control over fixing things... And I also relate with the personal chaos that maybe we tend to fix by fixing our software... I see a lot of this "unfinished" behaviour with other things in my life as well... Cleaning the shed, finishing videogames.... Sometimes even the feeling of having the challenge is enough...I don't even try, because I know it will take time to make it right
So true. I have tried building from scratch so many times for specific use-cases with my own opinionated experience only to recreate the bloat over time. That’s actually good. The alternative was building something based on momentary spark of creativity that no one, not even me end up using.
Some truth in there, but I have to admit that most simple static generators I have written I wrote out of fun and curiosity and not because I thought all existing ones had flaws (even if they did).
It is okay to do things and abandon them later, that is how we learn. We programmers are multipliers, which gives us special responsibility. If we create a shit tool with a shit workflow that wastes time, we waste time multiplied by the number of users of our software. If we save time or bring joy, the same is true. That can be beautiful and devastating.
But every software needs to be maintained somehow and maintainability is a technological choice as well. I have an embedded project running for well over a decade without a single maintenance step of either the hard- or the software. I could have built that project also with more dependencies to the outside world, or in more sophisticated ways with more moving parts, but I wanted to not deal with the consequences of that. This choice isn't always easy, but it is a choice. Ask your sysadmin which things worked for the past decades without having to touch them and investigate. Typically it is boring tech with boring choices.
Another aspect the article does not tackle is that if you know to repair or build many things, people will naturally also come to you asking you to do precisely that. But that again produces maintenance work and responsibility. This is why I like working in education, you can show people how to do it and then it is their project.
Playing devil's advocate here, but is that simply validation that stuff you've written is actually useful?
This could be seen as a proxy for self worth, which if something is useful, helps stave off that nagging anxiety in the back of your head?
The question here is, is that a useful driver to build new things, or do we let things go? That's kinda similar to the article's premise.
It's more like society factorio, but unlike factorio it's not fun and you're forced to play against people with much more resources and talent than you.
Don't start, I've started a playthrough again with the new expansion and just landed on the first planet after overbuilding my home base with grids and trains and stuff.
Family is the F-word I can't stand, much like Louis Rossman. Whenever someone pulls "but I'm your family" or "but I'm your friend" into an ask, there's a 95% likelihood you're being guilt-tripped. Whether you wish to help the manipulators is your choice, but it's important to understand what's happening.
Depends on the family member. My parents? They fed and clothed me for a couple of decades (not to mention literally wiped my ass for years). I owe them big time and I'll do basically anything that isn't immoral for them. My cousins? I like them and will try to help them, but I'm not going to bend over backwards either.
And yet, that doesn't take away their responsibility to carry their load in projects. One person is never responsible for the entire output in any organization. Even if some would like to see it that way (whether they imagine they ought to be the person, or someone else).
“Calvin: Know what I pray for?
Hobbes: What?
Calvin: The strength to change what I can, the inability to accept what I can't, and the incapacity to tell the difference.”
—Bill Watterson (1988)
Great article. I know it's not the main subject, but I really liked this part:
> Technical Work as Emotional Regulation
Men are taught to do that in most societies. You are unhappy - don't bother talking about it (men don't cry), do sth for the society - you'll receive praise in return and your pain will go away for a while. Even if nobody'll praise you - you'll think better of yourself. Same thing that makes our fathers obsessively fix any minor inconveniences around the house instead of going to the doctor with their big health problem.
Men often laugh at women talking for hours instead of fixing the damn problem (and it is frustrating to observe). But we often do not fix THE damn problem either - we fix other unrelated problems to feel better about the one we fear thinking about.
What's more tech-specific IMO is the degree to which our egos are propped by our code. Code is the one thing many programmers had going for them when they grew up. It's what made them special. It's what was supposed to pay for all the bullying in school. It's what paid their bills and made them respected. It's very hard not to make code your main source of value.
People praise "ego-less" programming, and most programmers adhere to the rules (don't get overly defensive, take criticism, allow others to change "your" code, etc.) But that's not actually ego-less programming, it's just hidding your ego in the closet and suffering in silence.
If you procrastinate when programming - it's because you feel your code reflects on your worth as a human being. It's all ego. Changing what you do won't change that. You need to change what you think.
To expand, code is a means, the core "habits" that programmers develop (at least speaking for myself) is twofold; abstracting, trying to reduce things to simple stereotypes; codifying / decision-tree-ing interactions, things like that. And problem solving, when someone mentions an issue, the gut reaction is to try and fix it. And it takes a lot of internet wisdoms and/or therapy to learn that you are allowed to let people stew in their problems, or that unless you're asked for a solution you don't need to offer one.
Problem solving is easier than listening and empathy.
These days, knowing that instead of spending hours artfully crafting a solution to something, GPT could code up a far-less-elegant-but-still-working solution in about 5-10 minutes of prompting has all but solved this.
That makes me feel even more guilty for not solving them, now that I realize the solution is one or two orders of magnitude easier to do.
Not joking with orders of magnitude. At this point, I regularly encounter a situation in which asking ChatGPT/Claude to hack me a little browser tool to do ${random stuff} feels easier and faster than searching for existing software, or even existing artifacts. Like, the other day I made myself a generator for pre-writing line tracing exercise sheets for my kids, because it was easier than finding enough of those sheets on-line, and the latter is basically just Google/Kagi Images search.
Yeah but if you let go of your years of coding standards / best practices and just hack something together yourself, it won't be much slower than chatgpt.
There's a... sad comparison of this article about over-responsibility, and https://www.benkuhn.net/blub/ about the value of learning about the stack you use (the more you know about the workings of bugs, sometimes the more they gnaw at you).
I think about this from the perpective of change management. Every defect I hope to fix entails a change, which has a certain probability of creating another irksome deficiency or incompatibility. When building complex systems I try to design them with the end state, that you describe very well, in mind.
Each time you set about to make a single change ask what is the probability (p) that this change results in another change, or track this probability empirically, then compute 1/(1-p) this will tell you how much change you should "expect" to make to realize your desired improvement. If you have n interacting modules compute 1/(1-np). This will quantify whether or not to embark on the refactor. (The values computed are the sum of the geometric series in the probability which represents the expectation value)
So this is about how we manage change in a complex system in order to align its functionality with a changing environment. I suggest that we can do so by considering the smallest, seemingly innocuous change that you could make and how that change propagates through to the end product.
In the end, a solution may be to make systems that are easy and painless to change, then you can change them often for the better without the long tail effects that drag you down.
That's what it says in the original post. It is also non-sensical. If the probability is 10% (p=0.1), and the number of systems is 11 (n=11), then you get 1/(1 - 11*0.1) which is -10.
I tried working this out, but I think the original was correct.
The cases where the answer is negative correspond to a 'runaway scenario' where every change is expected to cause more than 1 extra change. So the answer is 'nonsensical' (because that is indeed where the formula for geometric series no longer works) but the true answer is infinity.
Does this help explain why any simple household activity has a frustrating ~50% chance of turning into a string of dependencies and dependents that make you spend 10x the time you expected on it all?
E.g. you figure it'll take a minute to take the trash out and wash your hands. But on the way you discover you run out of trash bags, and while washing your hands you run out of soap, then as you pick the refill bottle from storage some light items fall out, and you need to put them back into a stable configuration, then you spilled a bit of soap during refilling so you need to clean up, but you just run out of paper towels, and...
What you've described is called "yak shaving", which is a series of neverending tasks that must be completed in order to complete the original task. It's apty named since shaving a hairy yak is a neverending task.
Right. I know the name (though it took me longer than I want to admit to connect the term with situations outside programming!) - what I now seek to know is, how to minimize it in personal life.
Letting go is probably most people's answer - nothing bad will happen if I do all the dependent tasks (cleanup, restocking things that just run out) later in the day - but I have difficulty getting them out of my head, they keep distracting me until they're completed.
When reality doesn't match your expectations, why do you blame reality instead of your expectations? Especially for thing like running out of soap, trash bags or towels that should be at least 90% in your own control.
I too suffer from this, but as I learned, Nature built an elegant solution to this. Have a family and kids. Your choice when you have time off of work will be reduced to hacking or playing with your child that you have been neglecting due to a crunch at work.
You’re welcome.
This is a great comment, as it hits far too close to my heart. Im currently trying to get my team to rethink how they are building the APIs for certain services in our product, and focus really on design and craftmanship. To the point where Im ready to start breaking it apart myself and coding up the solution on my off hours.
But then I look at my son, and say "screw it, they couldnt pay me enough to care out of hours and give up play time"
Or just have another hobby not involving programming. I got into this from being my main hobby as a kid, the passion thing I did when free time was available, I learnt a lot (enough to build it into a career), I had lots of fun but that time is gone.
My free time is to be spent on other things, I get paid to fix issues and that pays my bills, I don't want nor need to be thinking about these issues outside of paid hours, you know too much to the point where you know how much effort it will take to fix something that might look innocuous, innocent, but definitely has deep tendrils of other related issues to tackle. It's not worth it, not if I'm not being paid for it or it isn't part of a personal project I'm really passionate about.
So I learnt to not care much, I help my colleagues, deliver what I tell I will deliver, and free space in my mind to pursue other more interesting stuff to me.
> Or just have another hobby not involving programming.
This can actually make things (much) worse:
Since you have now another topic you are insanely passionate about, you see a lot of additional things in the world that are broken and need fixing (though of course typically not via programming).
Thus, while having a very different additionally hobby (not or barely involving programming) clearly broadens your horizon a lot, it also very likely doubles the curse/pain/problem that the original article discusses.
I agree with this. My hobbies tend to completely take over my thoughts and then it is difficult to switch to work context. It's much simpler for me if my hobby overlaps with my day job. If I get better in my hobby, that helps at job and vice versa.
Parent here, can confirm Nature solved this elegantly.
However, like every other solution built by Nature, this one also works through pain, suffering and death. Nature doesn't care if you're happy, nor does it care if you're suffering. And it especially doesn't care if your suffering is a low-burn, long-term pain in the depth of your heart.
So yeah, having kids will force you to make choices and abandon frivolities, in the same way setting your house on fire will free you from obsessing over choices for unnecessary expenses :).
Nature has another elegant solution, often applying both in conjunction: aging. As I age (and, yes, take care of my kids), I find myself more and more on the side of exploit in the exploration–exploitation dilemma. This will most likely endure after the kids have left.
Sometimes kids do make one feel that the house is on fire though I think I won't be looking forward to be hugged every evening by a burning house excited to see me.
You don't need kids, just a partner who has a "normal" job and likes to do stuff on the evenings and weekends is enough. If you have a partner who also does thought work and tends towards the workaholic then things might be more difficult...
Indeed. Marriage alone led to a complete reevaluation of my priorities in life. I still want to make cool stuff but my hobbies are so far down my list of priorities right now I would have to be actually getting paid in order to justify spending time on stuff.
I'm far from ready for being a parent yet, but this is honestly one factor I've noticed over and over again as a difference between my childless peers and the parents I encounter in work situations. Parents are just much better at prioritizing their time and energy and avoid perfectionism and trying to fix everything.
This was something I really enjoyed reading, having suffered greatly from the same conditions. It made me realize I’m not alone, and for that I hugely thank you, and everyone else in this thread who commented.
raf: from grins to smirks, thank you for repeatedly putting the smiles on my face. You know me so well considering we’ve never met. Ever so salient; thanks for (hopefully) course correcting any of my remaining years :)
There's plenty of Western philosophy as well that sees "not caring" (at least not about things outside your own actions) as very desirable. Not to mention the Epicureans, for whom freedom from worries ("ataraxia") was the highest attainable state.
OP's fear of (being seen to be) "coasting" would be entirely foreign to them.
Letting go of everything means stopping to care about anything, sure. But the point of the article is to try and stop caring about everything and focus on the things that are really important to you, focus on the things you can change.
This reasoning (which I can easily identify with) is a slippery slope towards OCD anxiety and depression when you refuse to acknowledge that you can't fix everything.
You need to be realistic, set your priorities within a limited, defined context, take decisions and actions based on those, and forget about the stuff that didn't make your priority list.
That's not not-caring. That's focusing on what really needs your care.
Tnx for the comment. Discussing tools (in this case, vibe coding) naturally raises the issue of what skills are actually needed to use them effectively, such as prompting, which in turn leads to a broader question about the role and relevance of traditional software engineering skills. It's a whole other topic...
You can create value with vibe coding. As I said, know your trade-off, your context.
You wouldn't use a hammer to fix a watch, would you?
457 comments
[ 4.6 ms ] story [ 330 ms ] threadSoftware is so spectacularly broken. Applications that don’t let me adjust the position of a little button for my work habits. Why is that impossible!?! A global software and commerce system, where you can buy candy or transfer $ billions, both with cute warnings like “Please, oh, please, sir! Please don’t hit the back button!”
I can sum up the results of my quest quite simply: “The rewrites continue…”
Is this chasing windmills? The case for that seems solid on the surface, but…
It is true that every rewrite of a specific set of features, or a platform for enabling better support for efficiently and correctly commingling an open class of features, inevitably runs into trouble. Some early design choice is now evidently crippling. Some aspect can now be seen to have two incompatible implementations colliding and setting off an unnecessary complexity explosion. Etc.
But on the other hand, virtually every major rewrite points to a genuinely much improved sequel. Whose dikes keeping out unnecessary complexity hold up longer with less finger holes to plug, for a better return. Before its collapse.
Since there must be a simplest way to do things, at least in any scoped area, we have Lyapunov conditions:
Continual improvement with a guaranteed destination. A casual proof there is a solution.
It’s a dangerous phantom to pursue!
——
It would be interesting to compile a list from the heady 90’s, when corporations created boondoggles like Pink and Cyberdog, and had higher aspirations for things like “Object Linking and Embedding”.
You just don’t see as many romantic technological catastrophes like those anymore. I miss them!
Yes. Well, "tilting at," jousting specifically. The figure relates to the comical pointlessness of such an act; the windmill sail will in every case of course simply remove the lance from the rider and the rider from the saddle, and turn on heedlessly, as only a purblind or romantic fool could omit trivially to predict.
> You just don’t see as many romantic technological catastrophes like those anymore.
The 90s were a period of unparalleled economic surplus in the United States. There was more stupid money than at any other time and place in history, and stupid money always goes somewhere. Once that was tulips. This time it was this.
> I miss them!
I miss the innocence of the time, however amply undeserved. But I was young myself then.
I see things slightly differently.
Big failures whose practical and theoretical lessons and new wisdoms are then put to use, more carefully, ambitions unabated, teach things, and take technology to unexpected places.
But big failures, institutionalized as big failures, become devastating craters of resources, warding off further attempts for years or decades … but only after the fact. That didn’t need to be their legacy.
Not that Americans should not aspire; indeed, the world has long loved us best when we dream most generously the utopias of which we forever will dream as long as we call ourselves Americans. It's only that generosity, not the reverie, of which we've lately lost the habit.
Yes, implementing things, even those that others have already done, reveals depths that no study of others’ artifacts or solutions ever could.
In terms of accessibility though, I'd recommend Forthkit (https://github.com/tehologist/forthkit), Miniforth (https://compilercrim.es/bootstrap/), Sectorforth (https://github.com/cesarblum/sectorforth), Sectorlisp (https://justine.lol/sectorlisp2/) Freeforth (https://github.com/dan4thewin/FreeForth2 contains an inlining cross-compiler for MSP430)
The problem with forths is that they don't seem as scalable as say lisp, from a social perspective. At a larger level, Project Oberon (https://projectoberon.net/) builds from the base CPU on FPGA, and A2 (https://en.wikipedia.org/wiki/A2_(operating_system)) show what can be done to scale up.
Steps (https://github.com/robertpfeiffer/cola/tree/master/function/...) also was supposed to do this, but the available code is rather disjointed and not really easy to follow.
As you note too, Forth is also useful as a counter demonstration of how important abstractions are. Without powerful abstractions (or simple abstractions that can be composed into powerful abstractions), Forth fails to scale, most especially across a team or teams, and for any expectation of general reuse, beyond basic operations.
The first version of Forth I used I wrote myself, which is probably a common event as you point out. Forth language documentation is virtually its own design doc.
Lisp is the other language I began using after buying a book and writing my own.
Thanks greatly for the links! I will be following up on those. Any insight from anywhere.
This, but with proper balance. TBH, you can live a happy life if you just stop caring about every technical problem, but that would make you unimaginative and passive. Just make sure your pick a hole (or two) you're gonna die in.
It is okay to do things and abandon them later, that is how we learn. We programmers are multipliers, which gives us special responsibility. If we create a shit tool with a shit workflow that wastes time, we waste time multiplied by the number of users of our software. If we save time or bring joy, the same is true. That can be beautiful and devastating.
But every software needs to be maintained somehow and maintainability is a technological choice as well. I have an embedded project running for well over a decade without a single maintenance step of either the hard- or the software. I could have built that project also with more dependencies to the outside world, or in more sophisticated ways with more moving parts, but I wanted to not deal with the consequences of that. This choice isn't always easy, but it is a choice. Ask your sysadmin which things worked for the past decades without having to touch them and investigate. Typically it is boring tech with boring choices.
Another aspect the article does not tackle is that if you know to repair or build many things, people will naturally also come to you asking you to do precisely that. But that again produces maintenance work and responsibility. This is why I like working in education, you can show people how to do it and then it is their project.
I find joy in receiving praise from my colleagues when they have good experiences with my tools.
(takes one to know one here)
We are playing software factorio and the winning move is not to play.
My honest, brutal answer is: "Your problem is very likely self-inflicted. Buy a decent Brother laser printer."
This attitude resolves you of nearly all such requests. :-)
https://en.wikipedia.org/wiki/Serenity_Prayer
> Technical Work as Emotional Regulation
Men are taught to do that in most societies. You are unhappy - don't bother talking about it (men don't cry), do sth for the society - you'll receive praise in return and your pain will go away for a while. Even if nobody'll praise you - you'll think better of yourself. Same thing that makes our fathers obsessively fix any minor inconveniences around the house instead of going to the doctor with their big health problem.
Men often laugh at women talking for hours instead of fixing the damn problem (and it is frustrating to observe). But we often do not fix THE damn problem either - we fix other unrelated problems to feel better about the one we fear thinking about.
What's more tech-specific IMO is the degree to which our egos are propped by our code. Code is the one thing many programmers had going for them when they grew up. It's what made them special. It's what was supposed to pay for all the bullying in school. It's what paid their bills and made them respected. It's very hard not to make code your main source of value.
People praise "ego-less" programming, and most programmers adhere to the rules (don't get overly defensive, take criticism, allow others to change "your" code, etc.) But that's not actually ego-less programming, it's just hidding your ego in the closet and suffering in silence.
If you procrastinate when programming - it's because you feel your code reflects on your worth as a human being. It's all ego. Changing what you do won't change that. You need to change what you think.
Problem solving is easier than listening and empathy.
Not joking with orders of magnitude. At this point, I regularly encounter a situation in which asking ChatGPT/Claude to hack me a little browser tool to do ${random stuff} feels easier and faster than searching for existing software, or even existing artifacts. Like, the other day I made myself a generator for pre-writing line tracing exercise sheets for my kids, because it was easier than finding enough of those sheets on-line, and the latter is basically just Google/Kagi Images search.
Each time you set about to make a single change ask what is the probability (p) that this change results in another change, or track this probability empirically, then compute 1/(1-p) this will tell you how much change you should "expect" to make to realize your desired improvement. If you have n interacting modules compute 1/(1-np). This will quantify whether or not to embark on the refactor. (The values computed are the sum of the geometric series in the probability which represents the expectation value)
So this is about how we manage change in a complex system in order to align its functionality with a changing environment. I suggest that we can do so by considering the smallest, seemingly innocuous change that you could make and how that change propagates through to the end product.
In the end, a solution may be to make systems that are easy and painless to change, then you can change them often for the better without the long tail effects that drag you down.
The cases where the answer is negative correspond to a 'runaway scenario' where every change is expected to cause more than 1 extra change. So the answer is 'nonsensical' (because that is indeed where the formula for geometric series no longer works) but the true answer is infinity.
E.g. you figure it'll take a minute to take the trash out and wash your hands. But on the way you discover you run out of trash bags, and while washing your hands you run out of soap, then as you pick the refill bottle from storage some light items fall out, and you need to put them back into a stable configuration, then you spilled a bit of soap during refilling so you need to clean up, but you just run out of paper towels, and...
Letting go is probably most people's answer - nothing bad will happen if I do all the dependent tasks (cleanup, restocking things that just run out) later in the day - but I have difficulty getting them out of my head, they keep distracting me until they're completed.
Structure, order, habits.
But then I look at my son, and say "screw it, they couldnt pay me enough to care out of hours and give up play time"
My free time is to be spent on other things, I get paid to fix issues and that pays my bills, I don't want nor need to be thinking about these issues outside of paid hours, you know too much to the point where you know how much effort it will take to fix something that might look innocuous, innocent, but definitely has deep tendrils of other related issues to tackle. It's not worth it, not if I'm not being paid for it or it isn't part of a personal project I'm really passionate about.
So I learnt to not care much, I help my colleagues, deliver what I tell I will deliver, and free space in my mind to pursue other more interesting stuff to me.
This can actually make things (much) worse:
Since you have now another topic you are insanely passionate about, you see a lot of additional things in the world that are broken and need fixing (though of course typically not via programming).
Thus, while having a very different additionally hobby (not or barely involving programming) clearly broadens your horizon a lot, it also very likely doubles the curse/pain/problem that the original article discusses.
However, like every other solution built by Nature, this one also works through pain, suffering and death. Nature doesn't care if you're happy, nor does it care if you're suffering. And it especially doesn't care if your suffering is a low-burn, long-term pain in the depth of your heart.
So yeah, having kids will force you to make choices and abandon frivolities, in the same way setting your house on fire will free you from obsessing over choices for unnecessary expenses :).
I, for example, would perhaps not be a bad parent, but very likely at least one who does not obey the social expectations of how to raise a child.
OP's fear of (being seen to be) "coasting" would be entirely foreign to them.
This reasoning (which I can easily identify with) is a slippery slope towards OCD anxiety and depression when you refuse to acknowledge that you can't fix everything.
You need to be realistic, set your priorities within a limited, defined context, take decisions and actions based on those, and forget about the stuff that didn't make your priority list.
That's not not-caring. That's focusing on what really needs your care.
Wish I was better at it though.
It all boils down to the 3 key factors: speed, quality and cost. And you can't have it all
Know your trade-offs.
You can create value with vibe coding. As I said, know your trade-off, your context.
You wouldn't use a hammer to fix a watch, would you?
Jokes aside, you find the crème de la crème of engineering, and pay as much as they ask for.
Speed + Quality = $$$$$
On the other hand,
Speed + Cheap = Crap Quality
Cheap + Quality = Slow