The curse of knowing how, or; fixing everything

There&#x27;s a quote I learned when doing theatre, which I&#x27;ve seen attributed to either the stage magician Doug Henning or possibly Stanislavski, describing the process of art as taking something that&#x27;s difficult and making it <i>habit</i>, then taking something that&#x27;s habitual and making it <i>easy</i>, and then taking something that&#x27;s easy and making it <i>beautiful</i>.<p>For example, as an actor, you learn your lines by rote (they become habit), then you gain an understanding of the character&#x27;s motivations (remembering the lines becomes easy, because <i>of course</i> that&#x27;s what your character would say), then you work to tune your performance so the audience shares in the emotion and unspoken meaning of the lines (that&#x27;s beautiful&#x2F;art).<p>As this relates to software, I think it goes something like: you learn the magic incantation to make the computer do what you want (solving a hard task becomes habit), then you learn <i>why</i> that incantation works (solving it becomes easy), then you figure out better ways to solve the problem, such that the original friction can be removed completely (you find a more beautiful way to solve it).

Oh wow. This hits hard in the feels.<p>Here&#x27;s my personal submission for &quot;UI problem that has existed for years on touch interfaces, plus a possible solution, but at this point I&#x27;m just shouting into the void&quot;:<p><a href="https:&#x2F;&#x2F;medium.com&#x2F;@pmarreck&#x2F;the-most-annoying-ui-problem-r3ditm-31773fe6bbd5" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@pmarreck&#x2F;the-most-annoying-ui-problem-r3...</a><p>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.<p>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&#x27;t have a &quot;recently dismissed notifications&quot; UI)

Hopefully the future me is able to relate to this, because I really feel like I&#x27;m in a rut when it comes to working on personal projects.<p>I have many ideas that I want to build, but I&#x27;d have to learn new languages, yet I just can&#x27;t sit and go through the documentation every day like I should. Still haven&#x27;t finished the rust book.<p>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&#x27;t want to use it to generate code for me because I wanna enjoy the process of writing code rather than just reviewing code.<p>Basically I&#x27;m just stuck within the constraints I put for myself :(, I&#x27;m not sure why I wrote this here, probably just wanted to let it out..

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.<p>I grew up in a datacenter. Leaky air conditioners and diesel generators. Open the big doors if it gets too hot.<p><pre><code> 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. </code></pre> Everything, everywhere, is greasy and lousy and half broken. Sysadmins, we accept that everything is shit from the very beginning.

I too suffer from this, but as I learned, Nature built an elegant solution to this. Have a family and kids. Your choice when you have time off of work will be reduced to hacking or playing with your child that you have been neglecting due to a crunch at work. You’re welcome.

This just sounds like perfectionism. I believe it is a curse, because I hate working with teammates like this. They&#x27;ll spin their wheels solving some insane problem no one asked them to do because it&#x27;s &quot;better&quot; while ignoring the larger scope and goals of the project. I&#x27;ve tried to coach people out of this mindset, because I used to have it very early in my career, til I realized the sheer impracticality of it.<p>I use this really annoying, poorly supported terraform provider. I&#x27;ve written a wrapper around it to make it &quot;work&quot; but it has annoyances I know I can go to that repository and try to submit a patch for it to fix my annoyance. But why? This is &quot;good enough,&quot; and IME, if you sit on things like this long enough, eventually someone else comes along and does it. Is that a good attitude for everyone to have? Probably not, but now it&#x27;s been a few years of using this wrapper module, I have 2-3 viable alternatives now that didn&#x27;t exist before that I can switch to if needed.<p>I could&#x27;ve turned it into a several week project if I wanted, but why? What purpose does it serve? As you grow, you realize there is very rarely, if ever, a &quot;right&quot; answer to a problem. Consider the way you think it should be done is not the only &quot;right&quot; way and you&#x27;ll open more doors for yourself.

As I&#x27;m getting older, I want things to be as standardized as possible, and just don&#x27;t worry about the details. I have learned from my mistakes<p>The script I made for deployment, because existing solutions didn&#x27;t &quot;feel&quot; right, required a lot of work and maintenance when we later had to add features and bug fixes.<p>Another script I made for building and deploying Java applications, because I didn&#x27;t like Maven and Puppet.<p>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.

One of the ways psychologists classify people is between those who are maximizers&#x2F;optimizers and those who are satisficers&#x2F;stop when things are &quot;good enough.&quot;<p>As someone who is very much on the optimizer side of things, and experiences the struggles described in this article, the lesson I take to heart is that while satisficers tend to be happier, optimizers get more done.<p>Your optimizer tendencies make you into an expert, they open up new opportunities for learning and growth, they have the potential to have real consequence in the world. Be thankful for them, even as you guide them to their appropriate application.

Very good post. I’m happy the author has had these important personal insights.<p>Things that I’ve learned (through much difficulty) for myself that feel relevant:<p>* Boundaries: not all problems are mine to fix. It’s okay to say no, even if someone else doesn’t like it.<p>* Acceptance: perfection is an illusion, there will always be an endless list of problems to work on, human time and energy have real limits, I am allowed to have different desires and motivations today versus yesterday (or an hour ago!)<p>*Emotional maturity: humans are emotional beings, it’s okay to get annoyed &#x2F; upset at something, including particular issues with software. The root cause of an emotion often becomes clear much later than after the initial trigger, which usually is only slightly connected to the deeper issue.<p>*Wisdom &#x2F; self-love: it’s ok to rest. It’s okay to not finish a project. It’s okay to say no. Human lives are immensely complicated, we will always make mistakes, and change happens always. Words like <i>need</i> and <i>should</i> are are directives springing from the shifting, hidden narratives we have imbued our lives with. We can understand and reshape these narratives.<p>If I had more time I would have a written a neater, more concise, and more complete list :)

&gt; Burnout does not just come from overwork. It comes from overresponsibility.<p>I don&#x27;t _think_ it is accurate. I think burnout comes from putting energy into things that don&#x27;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.<p>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.<p>Throw this tradeoff off balance, and most parents just burn out in weeks.

<i>&gt; I can fix something, but not everything.</i><p><pre><code> “Calvin: Know what I pray for? Hobbes: What? Calvin: The strength to change what I can, the inability to accept what I can&#x27;t, and the incapacity to tell the difference.” —Bill Watterson (1988)</code></pre>

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 &quot;unfinished&quot; 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&#x27;t even try, because I know it will take time to make it right

I don&#x27;t feel the &quot;moral weight&quot; the author mentions.<p>For one, there are many, many directions you <i>could</i> take at any given moment, but you have to choose only one. You have no choice but to triage. That&#x27;s not a moral failing, just the nature of agency and existence.<p>I do have some perfectionistic tendencies, which might be behind some of this. But a long time ago I graduated to a deeper perfectionism...<p>The problem with simple perfectionism is that you can only achieve a level of perfection in a simple and superficial way, often to the neglect of more interesting goals... after you &quot;perfect&quot; something, you look deeper and inevitably see more problems. You can pursue those, but you then just look deeper again and repeat. At some point you&#x27;ll realize you&#x27;re spending a lot of time on something that is only meaningful to an arbitrary standard that exists only in your own head (that you only recently invented).<p>So I moved on to &quot;perfecting&quot; the balance across the relevant competing concerns and constraints. Since there&#x27;s rarely a perfect balance, no closed-form answer, and since your attention is certainly one of the factors to balance, real perfection requires that you can find something &quot;good enough&quot; given the circumstance to move on to something else.<p>Put another way, if you can&#x27;t find satisfaction of your perfectionist impulse in finding something good enough, you could be doing &quot;perfection&quot; better, and should probably work on that.

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 &quot;just for fun&quot; affair. I work on them when I feel like, no deadlines, and once they&#x27;re &quot;in production&quot; I maintain them because I like tinkering.<p>The only problem with this approach is I&#x27;ve gone from hating the thought of programming after work to coming up with side projects <i>at</i> work.

A good part of that is a disguised sense of superiority.<p>Life becomes way lighter when you realize other people are also smart and what you’re “fixing” can very likely be:<p>- something so unimportant that no one felt it was worthy working on<p>- something that was supposed to work like that, and you simply don’t agree and want to make it your way

Great article. I know it&#x27;s not the main subject, but I really liked this part:<p>&gt; Technical Work as Emotional Regulation<p>Men are taught to do that in most societies. You are unhappy - don&#x27;t bother talking about it (men don&#x27;t cry), do sth for the society - you&#x27;ll receive praise in return and your pain will go away for a while. Even if nobody&#x27;ll praise you - you&#x27;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.<p>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.<p>What&#x27;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&#x27;s what made them special. It&#x27;s what was supposed to pay for all the bullying in school. It&#x27;s what paid their bills and made them respected. It&#x27;s very hard not to make code your main source of value.<p>People praise &quot;ego-less&quot; programming, and most programmers adhere to the rules (don&#x27;t get overly defensive, take criticism, allow others to change &quot;your&quot; code, etc.) But that&#x27;s not actually ego-less programming, it&#x27;s just hidding your ego in the closet and suffering in silence.<p>If you procrastinate when programming - it&#x27;s because you feel your code reflects on your worth as a human being. It&#x27;s all ego. Changing what you do won&#x27;t change that. You need to change what you think.

There is the curse of knowing how, and maybe more importantly there is the curse of other people knowing you know how.

This post resonates a lot with me. As somebody in the twilight of their coding career - I totally understand what the author means by &quot;over-responsibility&quot;<p>After 25 years - I&#x27;m over it. But the flip side of that is that I can&#x27;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 &#x2F; or fix it. Thankfully I don&#x27;t do it by trying to code replacements like the author seems to. Instead I try to come up with workarounds or find replacements.<p>Nevertheless the weight of the curse is about the same I figure.

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).<p>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.<p>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&#x27;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.<p>Another aspect the article does not tackle is that if you know to repair or build many things, people will naturally also come to you asking you to do precisely that. But that again produces maintenance work and responsibility. This is why I like working in education, you can show people how to do it and then it is their project.

I sympathize with the nihilism, but having built tools that do just work as described, I&#x27;ve found that the problem is mostly rooted in a culture obsessed with novelty. And not novelty with a point (a truly better solution comes out), but novelty for novelty&#x27;s sake (something new to talk about that&#x27;s &quot;popular&quot; in dev circles, even if it&#x27;s junk).<p>The only way to build solid things is to start with the POV that they need to exist and be stable long-term. You have to give a shit about simplicity, stability, performance, backwards compatibility, etc. You have to teach people what you know and form professional opinions around why you do or do not go with the crowd (and stand behind them, even under pressure from those who don&#x27;t &quot;know how&quot;).<p>If you commit to that (and I mean <i>commit</i> long-term, not for a year but decades), you can build things that don&#x27;t break constantly, don&#x27;t require constant maintenance, and don&#x27;t drive you insane.

&gt; 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.<p>This really got to me because I&#x27;ve been doing this without realizing it for as long as I can remember.

&gt; I believe sometimes building things is how we self-soothe.<p>&gt; I have written entire applications just to avoid thinking about why I was unhappy.<p>I think this is true too. The prefrontal cortex is inhibitory to the amygdala&#x2F;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.<p>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.<p>And whether it&#x27;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.

I don&#x27;t know why but this almost made me cry.<p>Every day I keep looking at everything that&#x27;s broken and thinking I should find a way to fix it. Then I finish my work day and have zero energy to do anything useful and it all becomes guilt over the inaction, the feeling of not being productive at all times.<p>Very well written my friend.

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&#x27;s really important. So I whole-heartedly agree with &quot;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.&quot;

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.

I resonate with some of this. Personally, I am motivated and driven by understanding “why&#x2F;how” things work. The actual implementations are rarely more valuable to me than an exercise I know is “good for me” - and one that will help me gain insight into “the next thing” more quickly and efficiently. One major drawback to this that I have a bad habit of explaining how&#x2F;why something works to the people in my life… even if they didn’t ask. Definitely something I am learning to filter.<p>Additionally, one of the most unsettling things I find about LLMs is the (now well-observed) phenomenon of hallucinations. As someone who is terrible at memorization and has gotten by life thus far in large part to mental models - I didn’t realize until their popularization that I may or may not have regularly “hallucinated” things my entire life - especially when forming opinions about things. … makes you think …<p>Great article!<p>edit: I also find that the type of abstract thinking reinforced by writing software regularly, is addictive. Once you learn how to abstract a thing in order to improve or increase efficiency of the thing, it starts a cycle of continually abstracting, then abstracting your abstractions ad infinitum. It’s also a common bug I see in young CS students - they are fantastic problem solvers, but don’t realize that most (all?) of CS isn’t a thing - it’s the thing that gets you to the thing. Which is (I believe) why we have a generation of software engineers who all want to build platforms and marketplaces with very few applications that ACTUALLY DO SOMETHING. They haven’t taken enough humanities courses, or gained the life experience or something - to find the “REAL” problem they want to solve.

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.

&gt; Knowing which problems are worth your energy.<p>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 <i>a</i> hole (or two) you&#x27;re gonna die in.

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.<p>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&#x2F;(1-p) this will tell you how much change you should &quot;expect&quot; to make to realize your desired improvement. If you have n interacting modules compute 1&#x2F;(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)<p>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.<p>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.

&gt; The trials are never complete.<p>This is not true - one day you will be dead. Hopefully that day is a long way away but it will eventually come around.<p>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.<p>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.

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&#x2F;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, &quot;hey! that doesn&#x27;t look so hard now!&quot; One of the things I picked up.along the way was, audio engineering, live and studio sound, where when it kicks in, it&#x27;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.

&gt;I’ve lost count of how many projects I have started that began with some variation of “Yeah, I could build this but better.”<p>Genuinely, I think the best antidote to this is to refuse to do this until you personally feel about 80% confident you <i>really</i> understand how to work with the thing from the inside out.<p>Don&#x27;t try to rewrite Vim until you&#x27;ve already read and annotated a copy of <i>Practical Vim</i> and drove it daily for a few years, for example. Don&#x27;t try to rewrite SQLite until you&#x27;ve started hitting up against use cases even the common advice online can&#x27;t help you with.<p>This means you will probably do very few rewrites. That&#x27;s intentional - focusing your effort on making <i>new</i> software that solves <i>new</i> problems is, for all those who trash talk it, really much more valuable. And if you ever do a rewrite in earnest you&#x27;ll walk in with intimate knowledge of what exactly you&#x27;re trying to do here.

Fractal complexity.<p>It&#x27;s not only that solutions decay, though that&#x27;s true, but also that the search for improvement itself becomes recursive.<p>When you identify something can be improved, and fix it, your <i>own</i> 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.<p>Indeed I often look back at my own solutions and judge them <i>more</i> harshly than I would ever judge anyone else&#x27;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.<p>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.<p>[0] <a href="https:&#x2F;&#x2F;davnicwil.com&#x2F;just-build-the-product&#x2F;" rel="nofollow">https:&#x2F;&#x2F;davnicwil.com&#x2F;just-build-the-product&#x2F;</a>

I think the flip side of this is at some point after looking at enough crap software, you feel free to write your own. You can actually solve your directly problems in simpler ways with a lot less code than more generic tools.<p>I&#x27;ve had great fun writing little daemons, deployment and config management systems, my own tcp networking protocols, process management, and using these tools to &quot;build my own k8s&quot; more or less. It&#x27;s more fun for me to build and understand these relatively simpler systems than pick up all the tech debt of some more established ones.<p>And, given enough time, it can be very stable, fast, and tailored to my specific needs.

&gt; Software doesn’t stay solved. Every solution you write starts to rot the moment it exists. Not now, not later, but eventually. Libraries deprecate. APIs change. Performance regressions creep in. Your once-perfect tool breaks silently because libfoo.so is now libfoo.so.2.<p>Since I started using Nix flakes to build everything and pin to specific versions this largely stopped being a problem for me. I happily run things I last touched many, many years ago without worrying about stupid stuff like this ^<p>&gt; Burnout does not just come from overwork. It comes from overresponsibility.<p>I remain unconvinced by this, and the more years I rack up, the more I recognize the pattern of burnout having a direct relationship to alienation of labor.

I was hit pretty hard by this blog post, it felt deep and targeted at me. Not because of code but from a desire to fix the current state of the world and the knowledge that even if I tried I don’t think it would make a difference.<p>The same burden of moral responsibility can be applied to any systematic dysfunction. Those that know how to fix institutions, economies or governments are feeling this pretty strongly right now.<p>And even in the places where I’m not even sure how to fix it like the radicalization or both genders, or various ethnic groups into hating each other…<p>In my downtime my brain annoyingly tries to tackle these problems until I’m overwhelmed by the conclusions I’ve arrived at - many times the inevitable result is that things will continue to get _much worse_ before they get better.<p>Maybe I should take up crosswords.

I&#x27;m seeing myself in the text, but one aspect that doesn&#x27;t seem to be covered enough is the ego.<p>I find joy in receiving praise from my colleagues when they have good experiences with my tools.

This article resonates. After coding obsessively for almost 20 years, it&#x27;s muscle memory. I don&#x27;t have to find bugs anymore, they find me.<p>I can feel their presence. Pretty much all the bugs I write now are intentional &quot;will focus on this later&quot; kind of thing. I know exactly what I&#x27;m neglecting, why I&#x27;m neglecting it and when is the right time to address. I can write bug-free code if appropriate though it takes longer to do and not always possible in a company environment where there are deadlines.<p>It is a burden to see all the issues and complexity and not being able to address it fully.

Link is down. Archive link: <a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20250506062631&#x2F;https:&#x2F;&#x2F;notashelf.dev&#x2F;posts&#x2F;curse-of-knowing" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20250506062631&#x2F;https:&#x2F;&#x2F;notashelf...</a>

This can be difficult in a work context too. Plenty of times in my career where I had to depend on the output of another party even though I could see the mistakes they were making, offered advice&#x2F;help, but ultimately had to work with what they developed regardless. One of the worst feelings is being right about these things.<p>Tons of software relies on bodges to get things to work. If you tried to &quot;fix&quot; everything you&#x27;d go mad and never be finished... and then someone else will come along and want to &quot;fix&quot; it.<p>Definitely avoid staring into the abyss.<p>But like Camus&#x27; <i>Sisyphus</i>, we often have to smile in these situations and carry on with our work. Dwelling on the absurdity of it all gets us nowhere.

Welcome to your thirties!

<i>&gt; The Illusion of Finality</i><p>One of the most important skills that I&#x27;ve learned, through writing ship software, is &quot;Knowing what &#x27;Done&#x27; looks like.&quot;<p>There&#x27;s a point, where -even though there&#x27;s still stuff that I <i>have</i> to do- I need to declare the project &quot;done,&quot; wrap it up, slap a bow on it, and push it out the door.<p>There&#x27;s always a 2.0.<p>Writing in an iterative manner (where I &quot;discover&quot; a design, as I develop the software), makes this more difficult. One thing about &quot;hard&quot; requirements, is that there&#x27;s no question about what &quot;Done&quot; looks like.

Yeah, this resonates, and not just with software. I have a “jack of all trades” attitude passed down from my father and grandfather. If I don’t know how, I learn. I do my own large tree work, electrical, plumbing, car repair, and haircuts. In many ways this is good- it’s saved me money and in the case of the zombie apocalypse I think I could last a few months at least. Sometimes I think I should pay someone else, but somehow that always feels like more trouble. So I end up feeling like I should do it all. And then get overwhelmed and in a rut with all the psychic weight of the things I need to do.<p>Similar with software. I always tell my clients “yes I can do that” because, well, I can. But then I end up juggling too much, working nights and weekends, and not having time for the tree work and haircuts I have to do at home.

The wheel of dharma - suffering as the misalignment of the self with the world - has both compressive and tension aspects (for things happening to you and things you do respectively) each with aversive&#x2F;grasping aspects (depending on your taste).<p>The post describes grasping tension, the blessing and curse of the powerful.<p>Grasping tension highlights the value of work -- the difference between the end&#x2F;telos model and the actual - or &quot;execution&quot; in business -- and the fundamental priority of time as a value: opportunity matters most. Yes, you do need skill and resources, but they&#x27;re useless without opportunity.<p>So, at a minimum, stop polishing turds.<p>But the main thing about opportunity is that it&#x27;s a value to someone else. Yes scratching your own itch might end up helping others, but that&#x27;s incidental luck.<p>So the solution to this curse might not be perfecting your own craft or impedance-matching your emotions, but really to focus on solving other people&#x27;s problems.<p>The really nice thing about this solution is that it enables you to work with a lot of other people. So long as they&#x27;re acting in good faith to solve the same problem, you&#x27;ll minimize any coordination costs and enjoy all their strengths without having to do it all yourself. And when your work is needed by others, there&#x27;s no time or need to worry.<p>Is that not happiness, to make yourself useful?

I enjoy building or fixing physical stuff. So much that when I visit family members (or even close friends) I take my tools along. People are usually happy at the results. It has become something of a pleasant joke among the visit-ees.<p>The key is to enjoy what you are doing. If anything becomes a drudge, search for something else that matches your talents and is enjoyable.

Letting go means stopping to care. That&#x27;s a slippery slope to coasting.

At least the failures were in software and not hardware. Nothing worse than having to take everything a part again after spending hours on an engine job because you forgot to plug something in or a seal wasn’t installed properly. Or you wonder why the engineers decided to put that oil filter right beside the cat so you could burn the back of your hand.

I like to take the “programming as theory building” approach. Every program is an experiment. When it stops working, you have more information about the world. At that point, you can revise the program, or you can let it go. Either way, you’ve refined your theory of the domain, and that’s much less likely to tumble back down the hill than some source code that at best represents an imperfect application of the theory.

&gt; &gt; You have power over your mind—not outside events. Realize this, and you will find strength.<p>&gt; But programming lures us into believing we can control the outside events. That is where the suffering begins.<p>Isn&#x27;t it the opposite? We&#x27;re not surprised if someone who grew up amidst criminals also does crime. I&#x27;m not sure that I can choose whether to feel attracted to men instead of women. I can&#x27;t control my mind, but I can choose what people to stay with and what media to be exposed to. I can adjust everything <i>except for</i> my mind: my hands write code, my feet take me elsewhere, I can tune into different media, I can choose to not speak agitatedly when a service rep. is following corporate policy, etc., whereas my mind moulds or reacts in response to those inputs (I&#x27;ll still feel irritated by that corporate policy and be influenced by advertising)<p>If anything, I could see an argument for that you control neither, because obviously your control of your hands is coming from a combination of your mind&#x27;s outputs and the physical laws of our environment

As a non-techie (retired M.D.) who wouldn&#x27;t know source code from Morse code, reading these comments is extremely absorbing.

I was with the author right up to the Marc Aurelius quote &quot;You have power over your mind—not outside events. Realize this, and you will find strength.&quot;<p>The funny thing is that actual engineering _requires_ being resilient in the face of unpredictable external events.<p>And his quote &quot;You run the thing, and it works. Or it _doesn’t_, and you fix it.&quot; shortly after is fundamentally the difference between coding, and engineering.<p>And maybe that is the true curse of our profession. We call ourselves engineers, but we never behave like it. Engineering isn&#x27;t &quot;scratching the itch to build&quot;. It is defining requirements well, building something that fulfills the requirements, and then leaving well enough alone.

Wow, great piece.<p>We are playing software factorio and the winning move is not to play.

So... it&#x27;s not just me that see the world as a collection of broken tech&#x2F;tools that I know how to fix but won&#x27;t have the capacity to do everything myself and it feels frustrating...! I really liked framing it as &quot;Technical Capability as a Moral Weight&quot;

&gt; This is what I’m trying to learn now. After the excitement. After the obsession. After the burnout. I’m trying to let things stay a little broken. Because I’ve realized I don’t want to fix everything. I just want to feel OK in a world that often isn’t. I can fix something, but not everything.<p>Sounds like we&#x27;re making excuses for a world left far behind. Not all of us do this for the paycheck. This world is in some deep shit.

This essay is (painfully) apt, and it reminds me of where I was when I finally switched, to my great relief, from being a Maximizer to a Satisficer*. It was all just Too Much, and I was feeling overwhelmed with responsibilities.<p>And my drive to Solve All The Problems was not making me happy. At all. It was just a way to exert control over a difficult life, and by being terminally distracted by the easily-solvables, I was avoiding the big problems I genuinely needed to confront.<p>*<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;The_Paradox_of_Choice" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;The_Paradox_of_Choice</a>

I cannot emphasize how much I relate to this<p>It’s gotten better but in the past I would :<p>- happily spend weekends exploring what possible with QMK (consistently tweaking and re-programming my keyboard; diving into the depth of QMK docs)<p>- spend hours building various neovim tools for myself and playing around with different configs<p>- building various bash scripts<p>I’ve recently quit my software dev job to pursue building online products and my friend said something that sometimes being an engineer going into business can be a detriment - because you feel that you can build anything…and you can end up building forever. Whereas a business person would leave it at a “good enough to sell” state and move on

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.

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.

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.

I see what the author is trying to do with the title, which would be correctly punctuated as: &#x27;The curse of knowing how; or, fixing everything.&#x27; (The full stop would be period-optional, but period-appropriate.)

This is solid insight. Particularly the part about letting go. For software, if one decides to solve a problem, it&#x27;s easy to transition from making a birdhouse to becoming deeply invested in the mating habits of swallows.<p>In addition, I find when I start these projects from a place of hubris (&quot;there couldn&#x27;t <i>possibly</i> be a reason we transfer 10MB before every build&quot;), I find myself consistently humbled. It&#x27;s Chesterton&#x27;s Fences built out of other, smaller Chesterton&#x27;s Fences. The shape of the system is arbitrary but not meaningless.

Why do I have 244gb of environments and beat myself up when I delete something to play a game?<p>This deep desire to affect change in a controllable way...<p>This infinite desire for self value defined by external validation.<p>It&#x27;s not sustainable. Perfection can only be obtained by observation of perfection of combined self through self and other.<p>It&#x27;s okay to discard parts of yourself to balance yourself with your counterpart. A willing violation is no longer a violation.<p>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.<p>Essentially turning a binary system quantum.

If you had to ask me years ago, I would probably say that programming was my lifeblood. Not only did it pay, but it was fulfilling. Nothing could have convinced me otherwise.<p>Some people will have to go through the burnout phase and reach rock bottom to learn this advice, I&#x27;m afraid. Only from there can they see the consequences of not leaving everything broken, and decide to do something else.

Anyone else unable to access the site? I get a connection refused.

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.<p>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.<p>I literally paused the film and did that in under 5 minutes. It was amazing.<p>So fixing a lot of small things has become easier at least.

This happens on an organizational scale as well.<p>Once a company grows beyond a certain point it no longer needs to keep a razor focus on the core business, and a disproportionate amount of effort gets redirected to creating sometimes useful but often completely pointless and gratuitous internal tools. That way every middle manager gets to justify an ever growing number of reports and make his mark in the organization.

Well, with OpenBSD:<p>- Updates often don&#x27;t break things<p>- Remind for notes<p>- Gopher as my main site<p>- Multimarkdown+git for a wiki<p>- A web&#x2F;blog without RSS is not worth your time<p>- Nvi can be good enough against vim, entr+make do magic<p>- mbsync&#x2F;msmtp&#x2F;slrnpull and so work in batch mode, fire mutt and forget<p>I don&#x27;t hack my tools any more. I don&#x27;t distrohop. CWM, XTerm, MuPDF, GV and friends like Bitlbee do everything well since years. Now I&#x27;m focusing in Forth, because in a near future low power microcontrollers and laptop will say a thing or two.

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&#x27;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.

I have spent some percentage of my life attempting to rewrite all software from first principles up.<p>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!”<p>I can sum up the results of my quest quite simply: “The rewrites continue…”<p>Is this chasing windmills? The case for that seems solid on the surface, but…<p>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.<p>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.<p>Since there must be a simplest way to do things, at least in any scoped area, we have Lyapunov conditions:<p>Continual improvement with a guaranteed destination. A casual proof there is a solution.<p>It’s a dangerous phantom to pursue!<p>——<p>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”.<p>You just don’t see as many romantic technological catastrophes like those anymore. I miss them!

&quot;You learn how to program. You learn how to fix things. But the hardest thing you’ll ever learn is when to <i>leave them broken</i>. And maybe that’s the most human skill of all.&quot;<p>Well, that&#x27;s the serenity prayer, isn&#x27;t it?<p>&quot;God grant me the serenity to accept the things I cannot change; courage to change the things I can; and wisdom to know the difference.&quot;

<i>Every piece of software becomes a TODO list.</i><p>The classic form of this is people hacking EMACS.<p>The other side of the problem is when you&#x27;re building on a base that&#x27;s broken and needs more maintenance than it is getting. Much open source is like that. With too few eyes, all bugs are deep.

The site owner has misconfigured nginx with schizophrenic options to death. Here is an archive: <a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20250506062631&#x2F;https:&#x2F;&#x2F;notashelf.dev&#x2F;posts&#x2F;curse-of-knowing" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20250506062631&#x2F;https:&#x2F;&#x2F;notashelf...</a>

This really resonated with me. After reading, I thought &quot;This person is likely from the same generation I am&quot;. I started programming in 1987. According to their About page, they&#x27;ve been programming since 2018. I wonder how they can feel that burned out after such a (relatively) short time?!

It&#x27;s the Moneymaker effect. It&#x27;s less that you became a programmer and more Linux is so broken that you have to learn to code to get anything done. Couple that with cheap student loans and &quot;learn to code&quot; and now anyone is a programmer, not just those snooty researchers.

I&#x27;m compulsively drafting ideas along these same lines, but now I don&#x27;t need to fix that. Wonderful, brilliant text, thank you raf.

It&#x27;s like you went inside my brain and heart and divulged my feelings. Well done! Now, back to feeling worthless.

There&#x27;s a... sad comparison of this article about over-responsibility, and <a href="https:&#x2F;&#x2F;www.benkuhn.net&#x2F;blub&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.benkuhn.net&#x2F;blub&#x2F;</a> 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).

Glad I&#x27;m low enough on the bell curve to not have this problem. If a tool is broken I shrug. Maybe someone will fix it

<a href="https:&#x2F;&#x2F;archive.is&#x2F;2xEGK" rel="nofollow">https:&#x2F;&#x2F;archive.is&#x2F;2xEGK</a>

The next step is burn out, then keeping everything default and just living with it. I know of no steps after this.

I really can relate with the article. Also, it doesn&#x27;t just apply to software but to lots of other things. It&#x27;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.

I&#x27;ve known how to fix things for a loonnggg time, however I&#x27;ve never felt the <i>need</i> to fix things that aren&#x27;t absolutely blocking my current goal. I&#x27;m not sure the two are that deeply linked, except that the former potentially enables the later.

Prioritization is a brilliantly simple solution to this and other resource constraint problems.<p>If you can&#x27;t do it all, you have to choose. How to choose? Come up with a way to assign value to each, and do the most valuable first.<p>The value metrics depend on the system &#x2F; outcome desired.

<a href="https:&#x2F;&#x2F;archive.is&#x2F;2xEGK" rel="nofollow">https:&#x2F;&#x2F;archive.is&#x2F;2xEGK</a>

This is definitely applicable in other areas as well.<p>Think too hard about why you are unhappy and you&#x27;ll find yourself entering politics like I did.

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.

I rarely click the <i>favorite</i> button, and this one 101% worthy of it.<p>My humble broken words to the humans who read this, &quot;You can&#x27;t control everything. The one thing you can control is your action. Master it.&quot;

I&#x27;ve been leaving things broken from the get go! I&#x27;m a frigggin master of this!

It&#x27;s good to remember it&#x27;s a marathon, not a sprint and that everything rots over time.

This article seems to be resonating with a lot of people so I guess I&#x27;m just the outlier rather than OP being wrong. But I cannot express how absolutely pedantic and melodramatic this comes off to me.

My most useful hobby project is the one i just &quot;hack and find out&quot;.<p>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.<p>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.<p>Perfect is the enemy of good.

This is precisely why RaspberryPi&#x2F;Raspbian broke every _fricken_ tutorial on the internet by moving &#x2F;boot to &#x2F;bootfs<p>ok... I mean great.<p>There&#x27;s also a chance it&#x27;s probably just fine. Leave it alone if it&#x27;s not causing problems.

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 :)

Similarly once you know how to clean every nooks and cranies in your home, your whole weekend can just become a deep cleaning festival.

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.

<p><pre><code> Slow down, you crazy child You&#x27;re so ambitious for a juvenile But then if you&#x27;re so smart Tell me why are you still so afraid? Mm Where&#x27;s the fire, what&#x27;s the hurry about? You&#x27;d better cool it off before you burn it out You&#x27;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&#x27;re gonna kick off before you even get halfway through, ooh When will you realize Vienna waits for you? Slow down, you&#x27;re doing fine You can&#x27;t be everything you wanna be before your time Although it&#x27;s so romantic on the borderline tonight, tonight Too bad, but it&#x27;s the life you lead You&#x27;re so ahead of yourself, that you forgot what you need Though you can see when you&#x27;re wrong You know you can&#x27;t always see when you&#x27;re right You&#x27;re right You&#x27;ve got your passion, you&#x27;ve got your pride But don&#x27;t you know that only fools are satisfied? Dream on, but don&#x27;t imagine they&#x27;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&#x27;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&#x27;re gonna kick off before you even get halfway through, ooh Why don&#x27;t you realize Vienna waits for you? When will you realize Vienna waits for you? </code></pre> &quot;Vienna&quot; by Billy Joel <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=3jL4S4X97sQ" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=3jL4S4X97sQ</a>

I&#x27;ve learned through the years that I can&#x27;t stop for every car with it&#x27;s hood open.<p>Sometimes you just need to use it as a reminder to maintain your own vehicle.

I think its easier to get past this when you decide to be a bit more humble and give a bit more respect to the decisions made. As long as you don&#x27;t assume your immediate reaction is gospel because you feel like you&#x27;re better than someone who actually spent time solving the problem, suddenly you can look at things as decisions they made that are different than yours.<p>Yes dumb, bad things exist. But often they are simply compromises. If you were to rewrite things you&#x27;d often just make different compromises.<p>In that light, there is no &#x27;moral imperative&#x27; or some such thing. You can start to look at _why_ decisions were made and probably find subtlety you missed at first glance.<p>You might think this is foolish optimism and you know better but think about every refactor you&#x27;ve actually taken a part of instead of theorized and how much complexity shook out.

This resonates a lot with a thought that I&#x27;ve had for a long time.. A computer is not a tool, it never was, it never will be.. It&#x27;s a workshop.

Link is broken, maybe someone has a backup archive.

I see a similar issue in 2025, but with vibe coding.<p>It all boils down to the 3 key factors: speed, quality and cost. And you can&#x27;t have it all<p>Know your trade-offs.

I was in the middle of rewriting a library and adding sensible defaults for the CLI. I feel like I wrote this for myself

been there way too many times tbh - that endless urge to fix every little thing, even when i know it&#x27;s not worth the headache. you think the constant itch to improve stuff actually helps or just burns us out in the long run?

re: Technical Work as Emotional Regulation<p>This is a lovely point, and probably why a lot of technical people like to take on tactile hobbies outside of work. Follow these woodworking steps and at the end you have a properly built cabinet. Or why doing the dishes can sometimes be soothing, etc.

<a href="https:&#x2F;&#x2F;archive.ph&#x2F;2xEGK" rel="nofollow">https:&#x2F;&#x2F;archive.ph&#x2F;2xEGK</a>

This is very close my personal struggle; summarised by “I can do anything except one thing”.

I was just journaling about this. Your post nailed the sentiment.

Aargh. As someone who went into programming at ~12 after trying toys, woodwork, mechanics, electrics, electronics, .. - and stays there for 40years - i would have blessed software if it was just the software to blame. But i also knowhow all the other things before&#x2F;besides that.. So it is, a total DIY-as-noone-will-fix-it-and-no-way-buying-it. Or it <i>was</i> but i haven&#x27;t noticed things have changed?<p>(the saying goes that every man sooner or later grows.. into buying new socks instead of darning the holed ones. That i have accepted, but my question is, Shouldn&#x27;t that apply to other things too?)<p>Handle of fridge broke? Well.. no-such-thing-as-buy. Fix it - or replace it - with a rope (from some gift-bag handle actually). Uncountable toys being fixed and overflowing the wardrobe.. No way Throwing (almost) working things.<p>Pfft. Same thing as these hudreds of Makehells^b^b^b^b^bfiles, or that <i>proper</i> rename tool [1] which after 10years has become a swiss-army-knife <i>and i still find more use cases</i> to add :&#x2F;<p>A cage looking for a bird.. vs learning when to leave things broken...<p>Maybe that last one is like learning to pick your battles. Seems the hardest life lesson that can only be self-taught, sigh.<p>Thanks for the revelation.. maybe one day i&#x27;ll write mine :&#x2F;<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;svilendobrev&#x2F;svd_bin&#x2F;blob&#x2F;master&#x2F;filedir&#x2F;rename.py">https:&#x2F;&#x2F;github.com&#x2F;svilendobrev&#x2F;svd_bin&#x2F;blob&#x2F;master&#x2F;filedir&#x2F;...</a>

A more verbose description of the practice known as &quot;yak shaving&quot; or &quot;letting the perfect get in the way of good&quot;. More storytelly, emotional.<p>It&#x27;s popular. It appeals to some profiles: The leader who doesn&#x27;t understand why the worker is taking so long. The worker who doesn&#x27;t understand why the coworker is redoing his stuff.<p>If you let a popular saying guide your life, then why live at all? You got to experience those things first hand to understand.<p>If you never went through the process of trying to make something better, you will never understand the cost.<p>That&#x27;s why managers who say this kind of stuff are often despised. They demonstrate to know the sayings but not the experience of living through it. When they do, they are respected.<p>That is also why the product manager and the technical lead are often two distinct roles. The product manager can&#x27;t make those calls, it only cares about whether the final product matches expectations. The technical lead can make those calls about technical investment cost, but no calls about the project direction. It keeps a good social dynamic that prevents automatic popular sayings and &quot;I heard that...&quot; stuff to override human behavior.

This resonates so much. It&#x27;s always nice to see I&#x27;m not alone.<p>I believe computer programming is the closest humanity has ever come to godhood. We&#x27;re creating entire universes out of unstructured bits. It&#x27;s addicting. I feel this deep need to remake everything in my own image, to have the entire system reflect my own understanding.<p>I often feel like I&#x27;m insane for thinking there&#x27;s a better way. Surely someone much smarter than me would have thought of it, right? I must be stupid and missing some crucial fact that proves me wrong. Then I do it and it actually fucking works. What a rush.<p>I only regret the fact I&#x27;m a mere mortal with just one lifetime and whose days have just 24 hours which must be carefully allocated. Real gods have infinite time and are capable of infinite effort. Just look at the universe. It&#x27;s a deep religious realization.<p>&gt; Your once-perfect tool breaks silently because libfoo.so is now libfoo.so.2.<p>... Solution: get rid of libfoo and do it yourself. Now when it breaks you only have yourself to blame.<p>Yeah, I know... At some point it becomes pathological. It can still be an immensely fun activity if you&#x27;re curious and have way too much free time on your hands.<p>&gt; Sometimes, it’s OK to just <i>use</i> the thing.<p>Also okay to just complain. No, you don&#x27;t actually need to send in the damn pull request. It&#x27;s alright.

Fantastic post, definitely could relate to quite a bit of that.

Oh man, the shelf is famous! Awesome article my man.

The corollary, ignorance&#x2F;management is bliss.

Wow, this post hit just too close to me. I came to same conclusion quite a while back (the author also mentions that we most probably always know this); BUT never able to get out of that mindset. I think fixing boundary issues is a hard problem, but still solvable. Dealing with Your Things (or atleast the ones you think are yours), i.e stuff that you have marked as your boundary, seems much much harder to deal with.<p>My mind has argued, and won to some extent, the opposite, but within a boundary: if you are responsible, why not do it better, if you are not doing it better, what is the point of it all?

This was beautifully written. Thank you for sharing

&quot;Ideas are more important than code.&quot;<p>-- Unknown

It&#x27;s funny how it&#x27;s returning a 503 :(

we wont fix things by adding but deleting

I expected this to be about the curse of competence. Still an interesting write, appreciate the sharing.<p>I find the key is to have a purpose that would be less pursued if time is spent poorly. Combined with getting exceedingly honest with your estimates and internalizing <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;1205&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;1205&#x2F;</a> you can avoid throwing the baby out with the bathwater.

This resonates

Can&#x27;t disagree with any of that

I&#x27;m getting a 404.

The site is down

It&#x27;s funny that you can&#x27;t get HN commenters to unanimously agree on much of anything concrete, but we are all united in our belief that we know better.

this is realy good, great writing

&#x2F;.ed :(

Facts.

nice

&quot;SSL error&quot;...

this could be dunning-kruger in action

I suspect the reason for increasing frequency of this kind of topic - in particularly the reflective commentary here, is in large part due to the average age of HN poster going up. The self-congratulatory tone is on the verge of the (now outdated) self-fellation, held back by a sense of poignancy and nostalgia.<p>In other words, y’all got way too soft at shitposting.