Here's my personal submission for "UI problem that has existed for years on touch interfaces, plus a possible solution, but at this point I'm just shouting into the void":
In short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering, or especially, while it is still in the midst of reflowing or repopulating itself in realtime, or still sliding into view, etc.
Most frustratingly this happens when I accidentally fat-finger a notification that literally just slid down from the top when I went to click a UI element in that vicinity, which then causes me to also lose the notification (since iOS doesn't have a "recently dismissed notifications" UI)
alias_neo · 10m ago
I've had this a few times, particularly on mobile, where you're doing something and some pop-up will steal focus, but of course you were tapping or swiping or something the exact instance it popped; it stayed just long enough for the after-image on your retinas to catch a single word and you realise it might have been important, but it's gone now, with no sign.
This happened to my just the other day; I was purchasing something online with a slightly complicated process, from my mobile, I didn't want to f* up the process, and I was tapping occasionally to keep the screen awake while it was doing "stuff"; needless to say, something popped up, too fast for me to react, I have no idea which button I tapped if any, or if I just dismissed it, to this day no idea what it wanted but I know it was related to the payment process.
I've seen this solved in dialogs/modals with a delay on the dismiss button, but rarely; it would also make sense to delay a modal/dialog of some kind by a couple hundred milliseconds to give you time to react, particularly if tapping outside of it would dismiss it.
I find myself using Notification History on Android more and more often, but a lot of the time it's not even notifications, it's some in-app thing that's totally within the developer's control.
majewsky · 23m ago
I have another submission for most annoying UI problem: Trying to read a thing, but it's on medium.com. The sheer amount of popups and overlays I need to click away before I can actually read your thing, geez.
sevensor · 5m ago
The worst is when somebody has a custom domain, but it’s actually medium so I don’t know not to click on the link.
LeifCarrotson · 3m ago
The sheer amount is zero with an ad blocker enabled.
I consider UBO basically mandatory for browsing the web in 2025, too many sites are unusable and infuriating without it.
PixelForg · 3h ago
Hopefully the future me is able to relate to this, because I really feel like I'm in a rut when it comes to working on personal projects.
I have many ideas that I want to build, but I'd have to learn new languages, yet I just can't sit and go through the documentation every day like I should. Still haven't finished the rust book.
The other way is start building already, and if you come across a block, then learn about that thing and move on, but I feel uncomfortable having gaps in my knowledge, AI exists but I don't want to use it to generate code for me because I wanna enjoy the process of writing code rather than just reviewing code.
Basically I'm just stuck within the constraints I put for myself :(, I'm not sure why I wrote this here, probably just wanted to let it out..
maxbond · 2h ago
I like to say programming is about knowing which rabbit holes to plunge down and which to step over. There's too much to know to go depth-first down every rabbit hole. Go breadth first and accept gaps in your knowledge - everyone has them. If something never comes up and never causes an issue you need to look into, and the project gets done, it doesn't matter. There's always an improvement that could have been made, but done is better than perfect because perfect never gets done. But the projects never getting done or even started - speaking for myself, that is corrosive to my motivation.
I've written a lot of Rust. I've read less than half of the Rust book. Your competence in Rust is a function of how many lines of Rust you've written; getting to the point you can start working with it is more important than completing the book. Jon Gjengset's videos were really critical for me there, seeing how he worked in Rust made it possible for me to develop a workflow. (I broke down what I learned in more detail at one point [1].)
Rust is an example I've honed in on because you mentioned it and I related to it, but this is broadly applicable. Dare I say, more broadly than just programming, even.
(Also, note that I'm a giant hypocrite who shaves yaks and struggles with perfectionism constantly. I learned Rust 5 years ago to start a project, and I've written 0 lines of code for it. If I sound critical, that's my self criticism leaking through.)
> I've written a lot of Rust. I've read less than half of the Rust book.
Just knowing that there's someone out there who has worked like this or has been in the same situation gives me enough confidence to go through it!(the just write code part)
I've gone through so many resources (including the book) and I never managed to finish any of them. But I think now I need to get comfortable with having gaps and just start writing code and not be afraid of writing non-idiomatic rust code, atleast for now.
ChrisMarshallNY · 1h ago
I've -literally- been writing Swift, every day, seven days a week, 52.4 weeks a year, since June 2, 2014 (the day it was announced), yet, I still have huge gaps in my knowledge of the language.
I speak it without an accent, but not at Ph.D level.
As to home projects, that's pretty much all I do, these days, ever since I "retired"*, in 2017.
I'm quite good at what I do, and generally achieve every goal that I set, but, since I'm forced to work alone, the scope needs to be kept humble. I used to work as part of a worldwide team, doing some pretty interesting stuff, on a much larger scale.
But what's important to me, is that I do a good job on whatever I do. Everything I write, I ship, support, and document, even if it isn't that impressive. The bringing a project to completion, is a big part of the joy that I get from the work.
* Was basically forced into it
speleding · 1h ago
Another approach that may help you, that worked for me. I was not familiar with rust so I wrote an initial proof of concept in another language (Go in my case). Then I asked Claude AI to translate it to Rust. It compiled on the first try, the only bugs being problems in the source file I gave it. Then I iterated a bunch of times by saying "please make this more rustacean style".
I only tend to use AI for assistance, but for me at least it's easier to get started this way than to start with an empty source file.
maxbond · 2h ago
That's awesome, best of luck to you.
vanjajaja1 · 2h ago
> I like to say programming is about knowing which rabbit holes to plunge down and which to step over.
I like this a lot. I told someone once I avoid documentation like the plague and it just didn't have the same poetic ring as this line.
Sometimes you need to dive in, other times you need to hobble together something to step over
liefde · 24m ago
What you're feeling is not laziness. It's the quiet ache of misalignment between your values and your current energy. You love the craft. You want to savor the process. But the weight of “shoulds” — finish the book, learn the language, do it the right way — has turned your joy into pressure.
The discomfort of having gaps in your knowledge is not a flaw. It’s a sign of integrity. But perfectionism disguised as discipline can become a cage. You’re not stuck because you lack ability — you’re stuck because you’ve built a narrow path and called it the only way forward.
There is another way: give yourself permission. To build messy. To learn sideways. To follow joy, not obligation. To trust that your curiosity is enough.
You wrote this here because something in you is ready to shift. You’re not asking for advice. You’re asking to be seen. And you are.
dspillett · 33m ago
> Hopefully the future me is able to relate to this, because I really feel like I'm in a rut when it comes to working on personal projects.
I've been there for a decade or more. It is part of my recent burn-out…
The trick is to prioritise and not care too much about too many things, to avoid the choice paralysis in choosing what to do next. Unfortunately I've not mastered that trick yet, or even come close. In fact I'm increasingly of the opinion that dropping tech projects completely, accepting that is no longer a hobby and no longer something that will ever bring me joy again in future, is the prioritisation I need to perform, so I can instead have more mental capacity for other hobbies (and, of course, commitments in life).
You are far from alone in this trap!
xandrius · 23m ago
Just for info, you can use AI to teach you the code fundamentals you're lacking, not just to write the code for you.
Say, you have to use a new IDE and don't know how to use it, ask the LLM the steps to perform whether action your want to take.
The worst you can do is nothing at all.
kunley · 3h ago
Very well said, to enjoy the process of writing the code.
I don't understand why so many people suddenly started to insist on taking this all away, and they totally seriously proposed to become a janitor of a hallucinated output of some overhyped tool. That's the most frustrating thing one can imagine about programming, yet people insist on it.
6LLvveMx2koXfwn · 2h ago
And even if it is correct output from said overhyped tool it still detracts from the enjoyment of building/fixing stuff. I used to love going over the code I wrote to fix a specific issue, now not so much as half of it was written by AI so half of the satisfaction has gone too.
CivBase · 2h ago
I don't want an AI to write my code. Coding is one of the only things I enjoy about my job and I barely get to spend any time doing it right now.
throwanem · 2h ago
> I feel uncomfortable having gaps in my knowledge
Understanding why I feel this, when I have, has always proven enlightening. I find it never has to do with the gap or what would fill it.
funkydata · 1h ago
Don't be hard on yourself. We're in the same boat.
There is two things I validated from reading Barbara Oakley and Kató Lomb is that a) it's okay to be a slow learner b) it's okay to learn differently.
Just do your thing.
speedupmate · 2h ago
Don't code, validate your ideas first (to first 1000 paying customers if monetization motivates) and 99% is not even worth to be started with, life is just too short for that.
With AI there's nothing to be ashamed of as it is "what you can dream of, you can get today". There's not much left in programming in most of the projects (that are just repeated code, output, what not over and over) after AI , tools are just too powerful today.
rcfox · 1h ago
How do you validate an idea with 1000 paying customers if you don't have a product?
totaa · 1h ago
landing page / waitlist / speaking with customers
you shouldn't write code until you know someone is willing to buy
i'd say somewhere between 20 < n < 100 for B2B makes sense, rather than 1000
lelanthran · 3h ago
> I have many ideas that I want to build, but I'd have to learn new languages,
Why? Why, specifically, do you "have to learn new languages"?
So, sure, I can see that, for some product, you might need to learn a new tech (say ... some specific AWS/GCP/Azure service), or perhaps a new configuration language (YAML, TOML, whatever).
And, sure, for some ideas (for example a mobile phone app) you're forced into that specific ecosystem.
Other than the mobile exception above, why do you need to learn a new language to build your idea? There is nothing stopping you from implementing your idea in (for example) Python. Or Javascript. Or Java, C#, C++, etc.
A programming-language-barrier absolutely does not stop you building your idea.
You gotta make the call - are you interested in building $IDEA, or are you interested in learning $NEWLANG?
PixelForg · 2h ago
> There is nothing stopping you from implementing your idea in (for example) Python. Or Javascript. Or Java, C#, C++, etc
Except there is, my brain :), that's one of the constraints I'm talking about, I'm a frontend web dev and I only know JS/TS, and like some frontend web devs, I'm enamored by Rust because it seems so different. I already use JS/TS at work so I want to use something else for my personal projects. So I definitely would have to learn something new.
> You gotta make the call - are you interested in building $IDEA, or are you interested in learning $NEWLANG?
If I was only interested in building my idea, I'd have just used what I know and used AI to accelerate the process. However for me the journey is also important, I want to enjoy thinking and writing code (and this project is something only I'd use, so there's no hurry to release a prototype). The problem is I want to start writing code right away, but that has the issue that I've mentioned above (gaps in knowledge).
Nobody is at fault, other than me for setting these constraints for myself. I know the solution is to just suck up and go through the rust book, read a chapter daily and eventually I'd have all the concepts in my head that I can then just focus on writing the code. But whenever I go about doing this, my mind always persuades me that there must be a better way, or it finds some flaws in my current approach and so on. So I need to learn how to not listen to my mind in such cases, and stick to the goal that I set.
Edit - After reading a reply to my comment, I've decided to just start writing the code and not worry about having gaps, anytime I start having doubts again, I'd go through this comment thread
wofo · 17m ago
Good luck in your adventure! By the way, I think many people here on HN (myself included) would love to help you out if you get stuck / are struggling to get started / want a code review / want to chat about programming. Just shoot any of us an email ;)
lelanthran · 1h ago
> I know the solution is to just suck up and go through the rust book
No. The solution is to skip Rust and choose Java, C# or Go. Rust has a steep learning curve and if you project can tolerate a GC, there is next to no return for using Rust.
Instead of spending the next 6 months (for most people it's longer) to learn Rust, spend the next week getting to grips with C# (or Go, or Java) instead.
jaapz · 1h ago
I personally try to follow the method of "make it work, then make it nice". You build something that works, it does what you need it to do. After that, you probably already know where the code rubs you the wrong way, so you know where to look to improve and learn.
yehoshuapw · 1h ago
I sometimes do that too - but sometimes this leades to another trap:
I have something which works, but not the best. and I won't fix it, since the plan is to now do it "right". so I end up staying with a PoC forever..
dakiol · 2h ago
I guess it depends. If they have been developing mobile apps, and now want to develop a web app, then they definitely need to learn something like PHP, or Go or Python kr Java. On the other hand if they have been doing web development and now want to develop a native app, they must learn Java/Kotlin/Swift.
Same for databases (perhaps you never worked with one, then you must learn sql). Even html+css must be learned if you never used them before.
skydhash · 1h ago
There’s react native and cordova, if all you want is to build the usual mobile apps and you only know JS. And Java, Kotlin, and Swift are used for web development if you’re going the other way.
SafeDusk · 2h ago
This is why I tend to build a simple version of a complex tech just to feel what I am getting into - https://github.com/aperoc/toolkami (a minimal AI agent) as an example!
jrib · 2h ago
My advice would be to build with what you know.
Even if you need to really shoehorn a component of the system in, just make a note about it and keep building. When you're done, you can go back and focus on replacing that one piece.
My view is that you learn a lot through the process of building this way.
rmonvfer · 3h ago
I very much relate to this feeling (and I haven’t finished the rust book either!). In my case, I do use AI a lot (especially o3 and Sonnet 3.7), not to write code but to help me understand things that would’ve taken me a week, in a matter of hours (the conversational aspect is a game changer for me).
tpoacher · 3h ago
You are not alone. I feel the same way.
nonrandomstring · 2h ago
You have "epistemic integrity'.
I heard someone say "epistemic humility" the other day to mean
fallibilism [0] and the conversation got interesting when we moved on
to the subject of "what one can and should reasonably claim to know".
For example: should cops know the law?
Not every programmer needs to be a computer science PhD with deep
knowledge about obscure data-structures... but when you encounter them
it's a decision whether to find out more.
Integrity is discomfort with "hand-waving and magical" explanations of
things that we gloss over. Sure, it's sometimes expedient to just
accept face-value and get the job done. Other times it's kinda
psychologically impossible to move forward without satisfying that
need to know more.
Frighteningly, the world/society puts ever more pressure on us to just
nod along to get along, and to accept magic. This is where so much
goes wrong with correctness and security imho.
Software engineers, I love yall. To see the light at the end of the tunnel. To see some glorious perfect paradigm that maybe could be. I envy you.
I grew up in a datacenter. Leaky air conditioners and diesel generators. Open the big doors if it gets too hot.
Now let’s go back. Back to when we didn’t know better.
Software doesn’t stay solved. Every solution you write starts to rot the moment it exists.
Everything, everywhere, is greasy and lousy and half broken. Sysadmins, we accept that everything is shit from the very beginning.
bonoboTP · 3h ago
This is quite hard to grapple with fresh out of school, where you worked mainly on pristine implementations of eternal algorithms, proven to be optimal in multiple ways, elegantly crafting each loop and feeling accomplished by expressing the algo with even higher clarity, reading and idealizing Knuth etc.
Then you see the real world and you think it must be because people are stupid, the bosses are pointy-haired, they don't understand, they don't value elegance, they are greedy, they etc. etc. But once you spend enough time on your own projects, and they evolve and change over the years, they turn more and more into a mess, you rewrite, you prioritize, you abandon, you revive, and you notice that it goes much deeper than simply laziness. Real solutions depend on context, one caching algo is good when one medium is x times faster than another, but not when it's only y times faster. It makes sense to show a progress bar when downloading a file if the usual internet speed is X but not when it's Y. Over years and decades the context can shift, and even those things can change that were only silent assumptions of yours when you made the "perfect" program as a young'un, looking down on all the existing "messy" solutions that do a bunch of unnecessary cruft. It's an endless cycle...
XCSme · 1h ago
> Software doesn’t stay solved. Every solution you write starts to rot the moment it exists.
I don't really agree with this. Yes, it gets outdated quickly and breaks often if you build it in such a way that it relies on many external services.
Stuff like relying on "number-is-odd" NPM package instead of copy-pasting the code or implementing it yourself. The more dependencies you have, the more likely it will break.
If your software works locally, without requiring an internet connection, it will work almost forever.
Now, if you want to keep developing the software and build it over a long period, the secret is to always keep all dependencies up-to-date. Is there a ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be.
chamomeal · 1h ago
That sorta supports the point the article was making though:
> ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be.
Is, to me, almost the same sentence as
> Every solution you write starts to rot the moment it exists
XCSme · 58m ago
I mentioned updating is only necessary if you plan to keep developing the software.
If you build it once, and the existing functionality is enough (no plans to add extra features ever again), then you can remove all external dependencies and make it self-contained, in which case it will be very unlikely to break in any way.
As for the security aspects of not updating, with the proper setup, firewall rules and data sanitization, it should be as secure 10 years later as any recently developed software.
galbar · 3h ago
I have said many times to teammates: the only code that is perfect is the one that hasn't left our minds. The moment it's written down it becomes flawed and imperfect.
This doesn't mean we shouldn't try to make it as good as we can, but rather that we must accept that the outcome will be flawed and that, despite our best intentions, it will show its sharp edges the next time we come to work on it.
moffkalast · 3h ago
I'm sure some mathematicians would disagree.
bonoboTP · 3h ago
Math can be greasy and messy. Definitions can be clumsy in a way that makes stating theorems cumbersome, the axioms may be unintuitive, proofs can be ugly, they can even contain bugs in published form. There can be annoying inconsistencies like optional constant factors in Fourier, or JPL quaternions.
Yes, prototypical school stuff like Pythagoras are "eternal" but a lot of math is designed, and can be ergonomic or not. Better notation can suggest solutions to unsolved problems. Clumsy axioms can hide elegant structure.
pjc50 · 3h ago
I think applied mathematicians started to encounter this reality of the impure world the first time someone taped a dead moth into the logbook of the Harvard Mark II.
jurgenaut23 · 33m ago
> Burnout does not just come from overwork. It comes from overresponsibility.
I don't _think_ it is accurate. I think burnout comes from putting energy into things that don't have meaning. Case in point, this article: as you realize that fixing everything is a never-ending game with marginal ROI, you end up burning out.
If overresponsibility alone caused burn out, I think that every parent out there would be impacted. And yes, parental burnout is a _very_ real thing, yet some of us may dodge that bullet, probably by sheer luck of having just the right balance between effort and reward.
Throw this tradeoff off balance, and most parents just burn out in weeks.
diggan · 29m ago
> I think burnout comes from putting energy into things that don't have meaning.
That'd mean that people who are burned out all did so because they did stuff that didn't have meaning? Ultimately, I think you can get burned out regardless of how meaningful it is or isn't. People working at hospitals (just as one example) have probably some of the most meaningful jobs, yet burn out frequently regardless.
More likely that both different people burn out because of different things, and it's a mix of reasons, not just one "core" reason we can point at and say "That's why burnout happen, not the other things".
fendy3002 · 18m ago
the meaning of `overresponsibility` in this case, IMO is taking / considering the matters as something that we take responsibility of. That way of thinking itself (taking the responsibility) is causing a burden on the mental health of OP. Being ignorant or able to let go relieve the burden, thus preventing burnout
figassis · 5h ago
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.
TeMPOraL · 4h ago
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 :).
isolli · 2h ago
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.
yuppiepuppie · 4h ago
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"
aleph_minus_one · 3h ago
Not everybody who is a great programmer is a great parent. :-(
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.
phito · 2h ago
Same. Also I have absolutely no interest in having them.
piva00 · 4h ago
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.
aleph_minus_one · 1h ago
> 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.
globular-toast · 3h ago
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...
thedanbob · 1h ago
I used to never finish personal projects. Then I realized that the biggest thing preventing me from finishing them was (perversely) my sense of duty to get them finished. Once I decided that I was under no obligation to anyone to work on them, not even myself, I had no trouble finding the motivation to get them done. So now side projects are a strictly "just for fun" affair. I work on them when I feel like, no deadlines, and once they're "in production" I maintain them because I like tinkering.
The only problem with this approach is I've gone from hating the thought of programming after work to coming up with side projects at work.
itfossil · 54m ago
This post resonates a lot with me. As somebody in the twilight of their coding career - I totally understand what the author means by "over-responsibility"
After 25 years - I'm over it. But the flip side of that is that I can't un-see the fact that so much of the tech shit in my life is broken and it has practically become a second job trying to manage it and / or fix it. Thankfully I don't do it by trying to code replacements like the author seems to. Instead I try to come up with workarounds or find replacements.
Nevertheless the weight of the curse is about the same I figure.
gbuk2013 · 44m ago
> The trials are never complete.
This is not true - one day you will be dead. Hopefully that day is a long way away but it will eventually come around.
It is good to keep this in mind and spend some time coming to terms with this. If you do, the problem this article talks about will naturally fall away.
Realise and acknowledge the limitations to your ability to act. Then consciously make a choice as to what you spend your limited time on and don’t worry about the rest.
throw_away_0613 · 3h ago
As I'm getting older, I want things to be as standardized as possible, and just don't worry about the details. I have learned from my mistakes
The script I made for deployment, because existing solutions didn't "feel" right, required a lot of work and maintenance when we later had to add features and bug fixes.
Another script I made for building and deploying Java applications, because I didn't like Maven and Puppet.
The micro service I rewrote because I wanted to use my own favourite programming language. I introduced a lot of bugs that were already fixed, missing features and another language for my co-workers to learn when they inherited the application when I left.
DavidPiper · 2m ago
Totally agree, standardisation makes everything so much more legible, even if there are problems with the standard.
I also think there is a profoundly non-linear relationship (I don't want to say negative-exponential, but it could be), between:
- The number of lines of code, or distinct configuration changes, you make to the defaults of an off-the-shelf tool
- The cognitive and practical load maintaining that personalized setup
I'm convinced that the opportunity cost of not using default configurations is significantly higher than we estimate, especially when that environment has to be shared across multiple people.
(It's unavoidable or even desirable in many cases of course, but so often we just reinvent hexagonal wheels.)
clan · 3h ago
I hope many people read this and take it to heart.
It is a rare and wise insight which only becomes crystal clear with age. Choose your battles very carefully.
This is a golden nugget up there with "time flies". I never understood that as a kid but really hits hard with your mid-life crisis.
Listen carefully little grasshoppers.
No comments yet
pammf · 46m ago
A good part of that is a disguised sense of superiority.
Life becomes way lighter when you realize other people are also smart and what you’re “fixing” can very likely be:
- something so unimportant that no one felt it was worthy working on
- something that was supposed to work like that, and you simply don’t agree and want to make it your way
arkey · 15m ago
> A good part of that is a disguised sense of superiority.
Or not. It can be the struggle of having higher than average standards.
Sadly, your list is incomplete without:
- something someone didn't bother to put any effort or thought into at all.
ferguess_k · 1h ago
I believe after a certain age the most valuable skill is know how to remove things from your life instead of piling things up. Things that other people believe to be so crucial that your action of removing them from your life is going to offend them.
walterbell · 5h ago
> I can fix something, but not everything.
“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)
There is the curse of knowing how, and maybe more importantly there is the curse of other people knowing you know how.
Cthulhu_ · 3h ago
Family members asking you to fix their printers.
caseyy · 35m ago
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.
aleph_minus_one · 3h ago
> Family members asking you to fix their printers.
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. :-)
brianhama · 3h ago
It never ends.
caseyy · 37m ago
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).
maephisto666 · 6h ago
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
throwanem · 5h ago
What would it mean to be finished with life? Where are you going in such an all-fired hurry?
1dom · 1h ago
Trying to get to the world that all the people unlike us live: a world where a brain can power down for a bit because everything is fine for now.
throwanem · 1h ago
You think that's where "people unlike us" live? My God, have you ever met any?
bookofjoe · 47m ago
As a non-techie (retired M.D.) who wouldn't know source code from Morse code, reading these comments is extremely absorbing.
arkey · 9m ago
Do you perceive this as a tech-specific thing though? I'm a software engineer but this resonates with me more within other aspects of life in general than my professional background specifically.
bookofjoe · 3m ago
Not sure what "this" refers to.... OK, I just went back and reread the parent post and now I understand what you're asking. I do agree with you, this is generalizable across the board: file under the old saw "Perfect is the enemy of good."
It is not down, we are probably overwhelming the server. It works, intermittently.
bookofjoe · 19s ago
Truth.
d4rkn0d3z · 5h ago
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.
TeMPOraL · 4h ago
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...
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.
kmanraj · 3h ago
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.
d4rkn0d3z · 1h ago
It is remarkable how small p has to be for change to be cost effective.
TeMPOraL · 3h ago
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.
arkey · 3h ago
> how to minimize it in personal life.
Structure, order, habits.
d4rkn0d3z · 1h ago
Arrange things so they are easy to change.
rocqua · 4h ago
The N systems case equation has to be wrong. I think you need either 1/(1-p)^n or 1/(1-p^n)
d4rkn0d3z · 1h ago
I think it says 1/(1-np).
d4rkn0d3z · 1h ago
It is easy to see this by forming the geometric series and rearranging terms, the standard Euler trick.
survysandwich · 26m ago
If you started coding in the 70s like most xers, once you hit your mid fifties you stop caring. You realize it is easier just to use the tools as clumsy as they are to make your own happiness. As bob villa said: only an amateur blames his tools.
esjeon · 6h ago
> Knowing which problems are worth your energy.
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.
codelikeawolf · 2h ago
> We write a new tool because we are overwhelmed. Refactor it, not because the code is messy, but your life is. We chase the perfect system because it gives us something to hold onto when everything else is spinning.
This really got to me because I've been doing this without realizing it for as long as I can remember.
z3t4 · 1h ago
Modern software is like sand castles, you can go there every day to maintain it, but one day it will be completely washed away. Everything that is beautiful will start to rot. After something have reached perfection it will change or die. It doesn't have to be that way though, you can put the OS in a virtual machine, so every time you work on your beautiful software it will feel like you are carving rune stones.
moconnor · 2h ago
> I believe sometimes building things is how we self-soothe.
> I have written entire applications just to avoid thinking about why I was unhappy.
I think this is true too. The prefrontal cortex is inhibitory to the amygdala/limbic system; always having a project you can think about or work on as an unconscious learned adaptation to self-calm in persistent emotionally-stressful situations is very plausible.
I wonder how many of us became very good at programming ~through this - difficult emotional circumstances driving an intense focus on endless logical reasoning problems in every spare moment for a very long time. I wonder if you can measure a degree of HPA-axis deregulation compared to the general population.
And whether it's net good or net harmful. To the extent that it distracts you from actually solving or changing a situation that is making you emotionally unhappy, probably not great. But being born into a time in which the side effects make you rich was pretty cool.
A_Stefan · 3h ago
Thank you for sharing your personal journey. I too have (too) many ideas floating around, getting ready to fix everything I see broken, ignoring what's really important. So I whole-heartedly agree with "You learn how to program. You learn how to fix things. But the hardest thing you’ll ever learn is when to leave them broken."
mgaunard · 4h ago
Letting go means stopping to care. That's a slippery slope to coasting.
arkey · 2h ago
> Letting go means stopping to care.
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.
pjc50 · 4h ago
I think the Buddhists would disagree with you on the moral valence of this.
WJW · 3h ago
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.
Cthulhu_ · 3h ago
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.
davnicwil · 3h ago
Fractal complexity.
It's not only that solutions decay, though that's true, but also that the search for improvement itself becomes recursive.
When you identify something can be improved, and fix it, your own fix and every individual step of it now become the new thing that can be improved. After the most fleeting of pauses to step back and appreciate your work, this becomes your new default.
Indeed I often look back at my own solutions and judge them more harshly than I would ever judge anyone else's. Why? Because as the article says, I know much more about how it works. Cracks increase surface area by a lot. I know about a lot of the cracks.
I wrote a blog post [0] about this mindset getting in the way of what you care about in product development which you might enjoy, if you enjoyed this article.
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.
naabb · 2h ago
Anyone else unable to access the site? I get a connection refused.
Having kids is an excellent solution to this feeling.
Besides occupying any time you used to have for unnecessary work, they have an uncanny ability to remind you just how little you actually control.
However you get to the end of the OCD tunnel, the journey is often very worthwhile.
olup · 2h ago
I am a father of two, and I could not have penned that any better.
edelans · 42m ago
Slow down, you crazy child
You're so ambitious for a juvenile
But then if you're so smart
Tell me why are you still so afraid? Mm
Where's the fire, what's the hurry about?
You'd better cool it off before you burn it out
You've got so much to do
And only so many hours in a day, hey
But you know that when the truth is told
That you can get what you want or you can just get old
You're gonna kick off before you even get halfway through, ooh
When will you realize Vienna waits for you?
Slow down, you're doing fine
You can't be everything you wanna be before your time
Although it's so romantic on the borderline tonight, tonight
Too bad, but it's the life you lead
You're so ahead of yourself, that you forgot what you need
Though you can see when you're wrong
You know you can't always see when you're right
You're right
You've got your passion, you've got your pride
But don't you know that only fools are satisfied?
Dream on, but don't imagine they'll all come true, ooh
When will you realize Vienna waits for you?
Slow down, you crazy child
And take the phone off the hook and disappear for a while
It's alright, you can afford to lose a day or two, ooh
When will you realize Vienna waits for you?
And you know that when the truth is told
That you can get what you want or you could just get old
You're gonna kick off before you even get halfway through, ooh
Why don't you realize Vienna waits for you?
When will you realize Vienna waits for you?
I was in the middle of rewriting a library and adding sensible defaults for the CLI. I feel like I wrote this for myself
dandellion · 2h ago
I really can relate with the article. Also, it doesn't just apply to software but to lots of other things. It's the same mentality as being into cars and always tuning or restoring old ones. Being into woodworking or craftsmanship and fixing and building stuff around the house, etc.
bobrobpr · 1h ago
It's like you went inside my brain and heart and divulged my feelings. Well done! Now, back to feeling worthless.
GardenLetter27 · 3h ago
This is well-written. I think LLMs can help a bit here too - the other day I was watching a rare, old film with my wife and the subtitles kept de-syncing. I.e. the frame-rate was slightly different as well as a fixed offset.
So I explained it to Claude and made it write a Python script where I could manually set a few fixed times and it would adjust the SRT file, and it worked perfectly.
I literally paused the film and did that in under 5 minutes. It was amazing.
So fixing a lot of small things has become easier at least.
urig · 3h ago
My takeaway from this post is not to find better ways to do, but to find a way not to.
GardenLetter27 · 3h ago
Yeah, but the main thing is I didn't publish the script, or try to develop it into a more generic tool with more features (automatic synchronisation, etc.) - that is where things become overwhelming.
Like I have published a FOSS tool from some scripts I had for managing VPNs, and there I get constant issues around new providers / updates and it not working in people's specific environments (which I can't test).
The LLMs make it viable to write quick throw-away scripts with almost no time investment, and as such you feel no pressure to share or improve them.
Melkaz · 5h ago
I'm seeing myself in the text, but one aspect that doesn't seem to be covered enough is the ego.
I find joy in receiving praise from my colleagues when they have good experiences with my tools.
alexisread · 3h ago
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.
(takes one to know one here)
mentalgear · 1h ago
Link is broken, maybe someone has a backup archive.
sapht · 4h ago
I'm compulsively drafting ideas along these same lines, but now I don't need to fix that. Wonderful, brilliant text, thank you raf.
howtofly · 3h ago
Serious software development is rarely an individual endeavor; most issues should be resolved through collaboration. In other words, they should be addressed through management. What the author needs to overcome, in my view, is essentially a form of extreme individualism.
TeMPOraL · 2h ago
I guess that's a problem for a lot of us who learned to program as teenagers. A big reason programming felt good for me is precisely because it let me do interesting and impressive stuff myself, and not collaboratively. There were very few kids who had even remotely similar interests to me back then - and that's true in adulthood too, outside of work contexts. While on the job, my projects may be collaborative in nature, but after hours, there's very few people among my family and friends who'd even be interested in doing a small software project, much less capable of doing so.
dmichulke · 5h ago
Wow, great piece.
We are playing software factorio and the winning move is not to play.
Cthulhu_ · 3h ago
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.
WJW · 4h ago
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.
TeMPOraL · 3h ago
Also if you stumble and fall behind, you don't get to hit pause and plan your next steps carefully - that'll only make you fall behind even further.
dusted · 2h ago
This resonates a lot with a thought that I've had for a long time..
A computer is not a tool, it never was, it never will be..
It's a workshop.
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!
alexisread · 2h ago
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.
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.
exe34 · 4h ago
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.
napolux · 1h ago
It's funny how it's returning a 503 :(
nyanpasu64 · 5h ago
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).
kookamamie · 4h ago
It's good to remember it's a marathon, not a sprint and that everything rots over time.
mrheosuper · 2h ago
My most useful hobby project is the one i just "hack and find out".
I make a matrix led clock that can sync time through network, using Arduino and esp32. Due to time constraint, the coding standard is horrible(magic number, dynamic allocation, no abstraction between module, etc), but hey, it works, at least for 7 years now. The code took me 3 days to finish, and i would never write such code in production FW.
There is a bug that may makes it unable to connect network, but it can be fixed by turning off then on again, i never bother to debug or patch it.
Perfect is the enemy of good.
Barbing · 4h ago
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 :)
abhisek · 6h ago
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.
arjvik · 5h ago
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.
pmkary · 5h ago
I went down this road and it doesn't free up time, you just get to fix many many more problems.
arjvik · 4h ago
I should clarify - I don’t mean I use GPT to write these solutions, I leave them unsolved knowing that they’re solvable in a very inelegant way.
TeMPOraL · 4h ago
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.
layer8 · 42m ago
For some value of "working".
Cthulhu_ · 3h ago
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.
daliboru · 4h ago
I see a similar issue in 2025, but with vibe coding.
It all boils down to the 3 key factors: speed, quality and cost. And you can't have it all
Know your trade-offs.
layer8 · 41m ago
How do you achieve speed and quality at the same time?
daliboru · 30m ago
To quote one movie character: "Bro, when you can't fix a problem with money, you fix it with a lot of money."
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
Tepix · 3h ago
With vibe coding, you have none of those. The initial speed advantage will disappear once you need to maintain the mess.
daliboru · 37m ago
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?
foobahhhhh · 4h ago
Glad I'm low enough on the bell curve to not have this problem. If a tool is broken I shrug. Maybe someone will fix it
Why do I have 244gb of environments and beat myself up when I delete something to play a game?
This deep desire to affect change in a controllable way...
This infinite desire for self value defined by external validation.
It's not sustainable.
Perfection can only be obtained by observation of perfection of combined self through self and other.
It's okay to discard parts of yourself to balance yourself with your counterpart. A willing violation is no longer a violation.
Not observation of one or the other on a pedestal, but accepting that both are vital parts to the system and observing the perfection that comes from co-iteration.
Essentially turning a binary system quantum.
ajuc · 5h ago
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.
Cthulhu_ · 3h ago
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.
metalman · 2h ago
This is very amusing, and evocative of what creative makers go through in many other fields....and as an do it my self absolutist, got me mired in attempts to pick up programing as another side gig/hussle in a life that is wildly over subscribed.
So reluctantly I am letting go of a bunch of stuff that lingers, Presque vu skills, always almost, and never enough time to push up and over.
The bonus is that I have focused on things that I did level up on, and can now do with ease, and a bit of flare......and perhaps more importantly give others a bit of joy to watch and see, "hey! that doesn't look so hard now!"
One of the things I picked up.along the way was, audio engineering, live and studio sound, where when it kicks in, it's pure misery, and every mistake and buzz, ruins all music listening, fingers twitching for sliders that are not there, griping like a back seat driver.....the better the stereo, the worse the experience, especialy with heavily produced studio work.....at least with live recordings, all the mistakes are honest and oten the recovery is where the magic happens.
atoav · 5h ago
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.
pknerd · 2h ago
The site is down
jeffreygoesto · 2h ago
/.ed :(
arlyle · 6h ago
we wont fix things by adding but deleting
esjeon · 5h ago
Yes, but deleting is more difficult and often more expensive than adding. It becomes another burden if you are not bold and determined enough.
maephisto666 · 6h ago
The less, the better
bflesch · 6h ago
This resonates
abstractspoon · 6h ago
Can't disagree with any of that
brador · 3h ago
The next step is burn out, then keeping everything default and just living with it. I know of no steps after this.
WesolyKubeczek · 33m ago
Then one day you die and get a standard-issue funeral. I guess.
anthk · 3h ago
Well, with OpenBSD:
- Updates often don't break things
- Remind for notes
- Gopher as my main site
- Multimarkdown+git for a wiki
- A web/blog without RSS is not worth your time
- Nvi can be good enough against vim, entr+make do magic
- mbsync/msmtp/slrnpull and so work in batch mode, fire mutt and forget
I don't hack my tools any more. I don't distrohop. CWM, XTerm, MuPDF, GV and friends like Bitlbee do everything well since years. Now I'm focusing in Forth, because in a near future low power microcontrollers and laptop will say a thing or two.
Here's my personal submission for "UI problem that has existed for years on touch interfaces, plus a possible solution, but at this point I'm just shouting into the void":
https://medium.com/@pmarreck/the-most-annoying-ui-problem-r3...
In short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering, or especially, while it is still in the midst of reflowing or repopulating itself in realtime, or still sliding into view, etc.
Most frustratingly this happens when I accidentally fat-finger a notification that literally just slid down from the top when I went to click a UI element in that vicinity, which then causes me to also lose the notification (since iOS doesn't have a "recently dismissed notifications" UI)
This happened to my just the other day; I was purchasing something online with a slightly complicated process, from my mobile, I didn't want to f* up the process, and I was tapping occasionally to keep the screen awake while it was doing "stuff"; needless to say, something popped up, too fast for me to react, I have no idea which button I tapped if any, or if I just dismissed it, to this day no idea what it wanted but I know it was related to the payment process.
I've seen this solved in dialogs/modals with a delay on the dismiss button, but rarely; it would also make sense to delay a modal/dialog of some kind by a couple hundred milliseconds to give you time to react, particularly if tapping outside of it would dismiss it.
I find myself using Notification History on Android more and more often, but a lot of the time it's not even notifications, it's some in-app thing that's totally within the developer's control.
I consider UBO basically mandatory for browsing the web in 2025, too many sites are unusable and infuriating without it.
I have many ideas that I want to build, but I'd have to learn new languages, yet I just can't sit and go through the documentation every day like I should. Still haven't finished the rust book.
The other way is start building already, and if you come across a block, then learn about that thing and move on, but I feel uncomfortable having gaps in my knowledge, AI exists but I don't want to use it to generate code for me because I wanna enjoy the process of writing code rather than just reviewing code.
Basically I'm just stuck within the constraints I put for myself :(, I'm not sure why I wrote this here, probably just wanted to let it out..
I've written a lot of Rust. I've read less than half of the Rust book. Your competence in Rust is a function of how many lines of Rust you've written; getting to the point you can start working with it is more important than completing the book. Jon Gjengset's videos were really critical for me there, seeing how he worked in Rust made it possible for me to develop a workflow. (I broke down what I learned in more detail at one point [1].)
Rust is an example I've honed in on because you mentioned it and I related to it, but this is broadly applicable. Dare I say, more broadly than just programming, even.
(Also, note that I'm a giant hypocrite who shaves yaks and struggles with perfectionism constantly. I learned Rust 5 years ago to start a project, and I've written 0 lines of code for it. If I sound critical, that's my self criticism leaking through.)
[1] https://news.ycombinator.com/item?id=38020654
> I've written a lot of Rust. I've read less than half of the Rust book.
Just knowing that there's someone out there who has worked like this or has been in the same situation gives me enough confidence to go through it!(the just write code part)
I've gone through so many resources (including the book) and I never managed to finish any of them. But I think now I need to get comfortable with having gaps and just start writing code and not be afraid of writing non-idiomatic rust code, atleast for now.
I speak it without an accent, but not at Ph.D level.
As to home projects, that's pretty much all I do, these days, ever since I "retired"*, in 2017.
I'm quite good at what I do, and generally achieve every goal that I set, but, since I'm forced to work alone, the scope needs to be kept humble. I used to work as part of a worldwide team, doing some pretty interesting stuff, on a much larger scale.
But what's important to me, is that I do a good job on whatever I do. Everything I write, I ship, support, and document, even if it isn't that impressive. The bringing a project to completion, is a big part of the joy that I get from the work.
* Was basically forced into it
I only tend to use AI for assistance, but for me at least it's easier to get started this way than to start with an empty source file.
I like this a lot. I told someone once I avoid documentation like the plague and it just didn't have the same poetic ring as this line.
Sometimes you need to dive in, other times you need to hobble together something to step over
The discomfort of having gaps in your knowledge is not a flaw. It’s a sign of integrity. But perfectionism disguised as discipline can become a cage. You’re not stuck because you lack ability — you’re stuck because you’ve built a narrow path and called it the only way forward.
There is another way: give yourself permission. To build messy. To learn sideways. To follow joy, not obligation. To trust that your curiosity is enough.
You wrote this here because something in you is ready to shift. You’re not asking for advice. You’re asking to be seen. And you are.
I've been there for a decade or more. It is part of my recent burn-out…
The trick is to prioritise and not care too much about too many things, to avoid the choice paralysis in choosing what to do next. Unfortunately I've not mastered that trick yet, or even come close. In fact I'm increasingly of the opinion that dropping tech projects completely, accepting that is no longer a hobby and no longer something that will ever bring me joy again in future, is the prioritisation I need to perform, so I can instead have more mental capacity for other hobbies (and, of course, commitments in life).
You are far from alone in this trap!
Say, you have to use a new IDE and don't know how to use it, ask the LLM the steps to perform whether action your want to take.
The worst you can do is nothing at all.
I don't understand why so many people suddenly started to insist on taking this all away, and they totally seriously proposed to become a janitor of a hallucinated output of some overhyped tool. That's the most frustrating thing one can imagine about programming, yet people insist on it.
Understanding why I feel this, when I have, has always proven enlightening. I find it never has to do with the gap or what would fill it.
There is two things I validated from reading Barbara Oakley and Kató Lomb is that a) it's okay to be a slow learner b) it's okay to learn differently.
Just do your thing.
With AI there's nothing to be ashamed of as it is "what you can dream of, you can get today". There's not much left in programming in most of the projects (that are just repeated code, output, what not over and over) after AI , tools are just too powerful today.
you shouldn't write code until you know someone is willing to buy
i'd say somewhere between 20 < n < 100 for B2B makes sense, rather than 1000
Why? Why, specifically, do you "have to learn new languages"?
So, sure, I can see that, for some product, you might need to learn a new tech (say ... some specific AWS/GCP/Azure service), or perhaps a new configuration language (YAML, TOML, whatever).
And, sure, for some ideas (for example a mobile phone app) you're forced into that specific ecosystem.
Other than the mobile exception above, why do you need to learn a new language to build your idea? There is nothing stopping you from implementing your idea in (for example) Python. Or Javascript. Or Java, C#, C++, etc.
A programming-language-barrier absolutely does not stop you building your idea.
You gotta make the call - are you interested in building $IDEA, or are you interested in learning $NEWLANG?
Except there is, my brain :), that's one of the constraints I'm talking about, I'm a frontend web dev and I only know JS/TS, and like some frontend web devs, I'm enamored by Rust because it seems so different. I already use JS/TS at work so I want to use something else for my personal projects. So I definitely would have to learn something new.
> You gotta make the call - are you interested in building $IDEA, or are you interested in learning $NEWLANG?
If I was only interested in building my idea, I'd have just used what I know and used AI to accelerate the process. However for me the journey is also important, I want to enjoy thinking and writing code (and this project is something only I'd use, so there's no hurry to release a prototype). The problem is I want to start writing code right away, but that has the issue that I've mentioned above (gaps in knowledge).
Nobody is at fault, other than me for setting these constraints for myself. I know the solution is to just suck up and go through the rust book, read a chapter daily and eventually I'd have all the concepts in my head that I can then just focus on writing the code. But whenever I go about doing this, my mind always persuades me that there must be a better way, or it finds some flaws in my current approach and so on. So I need to learn how to not listen to my mind in such cases, and stick to the goal that I set.
Edit - After reading a reply to my comment, I've decided to just start writing the code and not worry about having gaps, anytime I start having doubts again, I'd go through this comment thread
No. The solution is to skip Rust and choose Java, C# or Go. Rust has a steep learning curve and if you project can tolerate a GC, there is next to no return for using Rust.
Instead of spending the next 6 months (for most people it's longer) to learn Rust, spend the next week getting to grips with C# (or Go, or Java) instead.
Even if you need to really shoehorn a component of the system in, just make a note about it and keep building. When you're done, you can go back and focus on replacing that one piece.
My view is that you learn a lot through the process of building this way.
I heard someone say "epistemic humility" the other day to mean fallibilism [0] and the conversation got interesting when we moved on to the subject of "what one can and should reasonably claim to know". For example: should cops know the law?
Not every programmer needs to be a computer science PhD with deep knowledge about obscure data-structures... but when you encounter them it's a decision whether to find out more.
Integrity is discomfort with "hand-waving and magical" explanations of things that we gloss over. Sure, it's sometimes expedient to just accept face-value and get the job done. Other times it's kinda psychologically impossible to move forward without satisfying that need to know more.
Frighteningly, the world/society puts ever more pressure on us to just nod along to get along, and to accept magic. This is where so much goes wrong with correctness and security imho.
[0] https://iep.utm.edu/fallibil/
I grew up in a datacenter. Leaky air conditioners and diesel generators. Open the big doors if it gets too hot.
Everything, everywhere, is greasy and lousy and half broken. Sysadmins, we accept that everything is shit from the very beginning.Then you see the real world and you think it must be because people are stupid, the bosses are pointy-haired, they don't understand, they don't value elegance, they are greedy, they etc. etc. But once you spend enough time on your own projects, and they evolve and change over the years, they turn more and more into a mess, you rewrite, you prioritize, you abandon, you revive, and you notice that it goes much deeper than simply laziness. Real solutions depend on context, one caching algo is good when one medium is x times faster than another, but not when it's only y times faster. It makes sense to show a progress bar when downloading a file if the usual internet speed is X but not when it's Y. Over years and decades the context can shift, and even those things can change that were only silent assumptions of yours when you made the "perfect" program as a young'un, looking down on all the existing "messy" solutions that do a bunch of unnecessary cruft. It's an endless cycle...
I don't really agree with this. Yes, it gets outdated quickly and breaks often if you build it in such a way that it relies on many external services.
Stuff like relying on "number-is-odd" NPM package instead of copy-pasting the code or implementing it yourself. The more dependencies you have, the more likely it will break.
If your software works locally, without requiring an internet connection, it will work almost forever.
Now, if you want to keep developing the software and build it over a long period, the secret is to always keep all dependencies up-to-date. Is there a ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be.
> ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be.
Is, to me, almost the same sentence as
> Every solution you write starts to rot the moment it exists
If you build it once, and the existing functionality is enough (no plans to add extra features ever again), then you can remove all external dependencies and make it self-contained, in which case it will be very unlikely to break in any way.
As for the security aspects of not updating, with the proper setup, firewall rules and data sanitization, it should be as secure 10 years later as any recently developed software.
This doesn't mean we shouldn't try to make it as good as we can, but rather that we must accept that the outcome will be flawed and that, despite our best intentions, it will show its sharp edges the next time we come to work on it.
Yes, prototypical school stuff like Pythagoras are "eternal" but a lot of math is designed, and can be ergonomic or not. Better notation can suggest solutions to unsolved problems. Clumsy axioms can hide elegant structure.
I don't _think_ it is accurate. I think burnout comes from putting energy into things that don't have meaning. Case in point, this article: as you realize that fixing everything is a never-ending game with marginal ROI, you end up burning out.
If overresponsibility alone caused burn out, I think that every parent out there would be impacted. And yes, parental burnout is a _very_ real thing, yet some of us may dodge that bullet, probably by sheer luck of having just the right balance between effort and reward.
Throw this tradeoff off balance, and most parents just burn out in weeks.
That'd mean that people who are burned out all did so because they did stuff that didn't have meaning? Ultimately, I think you can get burned out regardless of how meaningful it is or isn't. People working at hospitals (just as one example) have probably some of the most meaningful jobs, yet burn out frequently regardless.
More likely that both different people burn out because of different things, and it's a mix of reasons, not just one "core" reason we can point at and say "That's why burnout happen, not the other things".
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 :).
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"
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.
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.
The only problem with this approach is I've gone from hating the thought of programming after work to coming up with side projects at work.
After 25 years - I'm over it. But the flip side of that is that I can't un-see the fact that so much of the tech shit in my life is broken and it has practically become a second job trying to manage it and / or fix it. Thankfully I don't do it by trying to code replacements like the author seems to. Instead I try to come up with workarounds or find replacements.
Nevertheless the weight of the curse is about the same I figure.
This is not true - one day you will be dead. Hopefully that day is a long way away but it will eventually come around.
It is good to keep this in mind and spend some time coming to terms with this. If you do, the problem this article talks about will naturally fall away.
Realise and acknowledge the limitations to your ability to act. Then consciously make a choice as to what you spend your limited time on and don’t worry about the rest.
The script I made for deployment, because existing solutions didn't "feel" right, required a lot of work and maintenance when we later had to add features and bug fixes.
Another script I made for building and deploying Java applications, because I didn't like Maven and Puppet.
The micro service I rewrote because I wanted to use my own favourite programming language. I introduced a lot of bugs that were already fixed, missing features and another language for my co-workers to learn when they inherited the application when I left.
I also think there is a profoundly non-linear relationship (I don't want to say negative-exponential, but it could be), between:
- The number of lines of code, or distinct configuration changes, you make to the defaults of an off-the-shelf tool
- The cognitive and practical load maintaining that personalized setup
I'm convinced that the opportunity cost of not using default configurations is significantly higher than we estimate, especially when that environment has to be shared across multiple people.
(It's unavoidable or even desirable in many cases of course, but so often we just reinvent hexagonal wheels.)
It is a rare and wise insight which only becomes crystal clear with age. Choose your battles very carefully.
This is a golden nugget up there with "time flies". I never understood that as a kid but really hits hard with your mid-life crisis.
Listen carefully little grasshoppers.
No comments yet
Life becomes way lighter when you realize other people are also smart and what you’re “fixing” can very likely be:
- something so unimportant that no one felt it was worthy working on
- something that was supposed to work like that, and you simply don’t agree and want to make it your way
Or not. It can be the struggle of having higher than average standards.
Sadly, your list is incomplete without:
- something someone didn't bother to put any effort or thought into at all.
https://en.wikipedia.org/wiki/Serenity_Prayer
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. :-)
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.
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.
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.
This really got to me because I've been doing this without realizing it for as long as I can remember.
> I have written entire applications just to avoid thinking about why I was unhappy.
I think this is true too. The prefrontal cortex is inhibitory to the amygdala/limbic system; always having a project you can think about or work on as an unconscious learned adaptation to self-calm in persistent emotionally-stressful situations is very plausible.
I wonder how many of us became very good at programming ~through this - difficult emotional circumstances driving an intense focus on endless logical reasoning problems in every spare moment for a very long time. I wonder if you can measure a degree of HPA-axis deregulation compared to the general population.
And whether it's net good or net harmful. To the extent that it distracts you from actually solving or changing a situation that is making you emotionally unhappy, probably not great. But being born into a time in which the side effects make you rich was pretty cool.
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.
OP's fear of (being seen to be) "coasting" would be entirely foreign to them.
It's not only that solutions decay, though that's true, but also that the search for improvement itself becomes recursive.
When you identify something can be improved, and fix it, your own fix and every individual step of it now become the new thing that can be improved. After the most fleeting of pauses to step back and appreciate your work, this becomes your new default.
Indeed I often look back at my own solutions and judge them more harshly than I would ever judge anyone else's. Why? Because as the article says, I know much more about how it works. Cracks increase surface area by a lot. I know about a lot of the cracks.
I wrote a blog post [0] about this mindset getting in the way of what you care about in product development which you might enjoy, if you enjoyed this article.
[0] https://davnicwil.com/just-build-the-product/
So I explained it to Claude and made it write a Python script where I could manually set a few fixed times and it would adjust the SRT file, and it worked perfectly.
I literally paused the film and did that in under 5 minutes. It was amazing.
So fixing a lot of small things has become easier at least.
Like I have published a FOSS tool from some scripts I had for managing VPNs, and there I get constant issues around new providers / updates and it not working in people's specific environments (which I can't test).
The LLMs make it viable to write quick throw-away scripts with almost no time investment, and as such you feel no pressure to share or improve them.
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.
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!
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.
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 make a matrix led clock that can sync time through network, using Arduino and esp32. Due to time constraint, the coding standard is horrible(magic number, dynamic allocation, no abstraction between module, etc), but hey, it works, at least for 7 years now. The code took me 3 days to finish, and i would never write such code in production FW.
There is a bug that may makes it unable to connect network, but it can be fixed by turning off then on again, i never bother to debug or patch it.
Perfect is the enemy of good.
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.
It all boils down to the 3 key factors: speed, quality and cost. And you can't have it all
Know your trade-offs.
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
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?
This deep desire to affect change in a controllable way...
This infinite desire for self value defined by external validation.
It's not sustainable. Perfection can only be obtained by observation of perfection of combined self through self and other.
It's okay to discard parts of yourself to balance yourself with your counterpart. A willing violation is no longer a violation.
Not observation of one or the other on a pedestal, but accepting that both are vital parts to the system and observing the perfection that comes from co-iteration.
Essentially turning a binary system quantum.
> 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.
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.
- Updates often don't break things
- Remind for notes
- Gopher as my main site
- Multimarkdown+git for a wiki
- A web/blog without RSS is not worth your time
- Nvi can be good enough against vim, entr+make do magic
- mbsync/msmtp/slrnpull and so work in batch mode, fire mutt and forget
I don't hack my tools any more. I don't distrohop. CWM, XTerm, MuPDF, GV and friends like Bitlbee do everything well since years. Now I'm focusing in Forth, because in a near future low power microcontrollers and laptop will say a thing or two.