The curse of knowing how, or; fixing everything

> 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 why 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).

I've come to a less pleasant way of putting a similar workflow. If something hurts(in the sense that you dread doing it, even though it needs to be done), make it hurt as much as possible and keep doing it until it doesn't. Along the way you'll find the ways to make it easier, faster, more efficient, etc but if you put it off every time until you can find the fortitude to embrace the suck then it's never going to get noticeably better.

Most of the time this is business process related, especially when inheriting legacy systems. Ideal outcome is that you understand it enough after really digging into it to cut out or replace entire swathes of the processes without losing confidence that it will continue to operate smoothly.

Agreed on this view! Sharing some similar thoughts

Paraphrasing a virtuous music band reflecting on their discography: "the first album was about what we could; the second one was about what we should"

It also aligns with Gell's philosophy of art. Here's a wikipedia exerpt:

> Gell argues that art in general acts on its users, i.e. achieves agency, through a sort of technical virtuosity. Art can enchant the viewer, who is always a blind viewer, because "the technology of enchantment is founded on the enchantment of technology"

In less poetic terms, the progression I talk about is "copy, choose, create". First, we learn to copy a solution. Later, we know enough solutions that we can choose the best for the situation and copy that one. Finally, we know enough to create our own solutions that are well adapted to the problem.

That quote is meaningful.

In a similar context, Bruce Lee said about martial arts that "martial" is to discover the dangerous animal within us, and the "art" is to be able to tame that animal.

> 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 why 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).

Also known as "Make it work, make it right, make it fast"

https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

That was a beautiful quote, I can see some examples in my life where this applies.

"Kneel down and you will believe."

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.

Yes, 1,000%.

The one I don't quite know how to solve is when I'm tapping a device to connect to -- whether a WiFi router or an AirPlay speaker or whatever -- and I swear to god, half the time my intended device slides out from under me a newly discovered device enters above and pushes it down. Or sometimes devices disappear and pull it up. Maybe it's because I live in an apartment building with lots of devices.

I've seen this solved in prototypes by always adding new devices at the bottom, and graying out when one disappears, with a floating "resort" button so you can find what you're looking for alphabetically. But it's so clunky -- nobody wants a resort button. And you can't use a UX delay on every update or you'd never be able to tap anything at all for the first five seconds.

Maybe ensuring there's always 3 seconds of no changes, then gray out everything for 0.5 seconds while sliding in all new devices discovered from the past 3.5 seconds, then re-enabling? I've never seen anything like that attempted.

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.

Oh man. This makes me want to throw my phone against the nearest brick wall sometimes. The UI is loading, I reach for the button I want to hit, but it moves and a different button takes its place because the app/page is still loading, or worse, an ad has taken the place of the button.

This also happens where sometimes the hotbar has three buttons, and sometimes four, and the worst apps are when buttons switch ordinal positions depending on if there are three or four buttons in there.

It feels very strange to get so agitated by these small behaviors, but here we are.

If a user is interacting, DO NOT UPDATE the list / models / etc.

If an update is required, rather than just desired, freeze all input so the user knows it's about to update, this might be accompanied by a quick 'fade' or other color shift to indicate an update is about to be pushed and they should release and re-plan actions.

It's not just a touch issue. Desktop environments have toast notifications and dialogs that can pop up unexpectedly (neither of which are remotely new problems). You can be trying to click something at the corner of your screen and have it intercepted by a notification or you can be pressing enter and have it activate the default action on a dialog that just popped up. Especially in the dialog case you often just have to hope that it wasn't actually something you needed to see or select a different option on.

> In short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering

I was a console game developer working on UI for many years so I am deeply familiar with the problem when a UI should be responsive to input while the visuals are changing and when it should not.

You might be surprised, but it turns out that blocking input for a while until the UI settles down is not what you want.

Yes, in cases where the UI is transitioning to an unfamiliar state, the input has a good chance to be useless or incorrect and would be better dropped on the floor. It's annoying when you think you're going to click X but the UI changes to stick Y under your finger instead.

However, there are times where you're tapping on a familiar app whose flow you know intimately and you know exactly where Y is about to appear and you want to tap on it as fast as you can. In those cases, it is absolutely infuriating if the app simply ignores your input and forces you to tap again.

I've watched users use software that temporarily disables input like this and what you see is that they either get trained to learn the input delay and time their tap as tightly as possible, or they just get annoying and hammer inputs until it gets processed.

And, in practice, it turns out these latter times where a user is interacting with a familiar UI are 100x more common than when they misclick on an unfamiliar UI. So while the latter case is super annoying, it's a better experience in aggregate if the app is as responsive as it can be, as quickly as it can be.

Perhaps there is a third way where an app makes a distinction between flows to static context versus dynamically generated content and only puts an input block in for the latter, but I expect the line between "static" and "dynamic" is too fuzzy. People certainly learn to rely on familiar auto-complete suggestions.

UI is hard. A box of silicon to a great ape is not an easy connection to engineer.

This has a name, it’s called CLS (cumulative layout shift) and Google actually penalizes SERP rankings for pages with bad CLS. More info on it on lighthouse.dev (if I recall the domain correctly).

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

[1] https://news.ycombinator.com/item?id=38020654

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.

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.

> 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.

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.

Hey! I relate to this! And thank you for sharing.

This happened to me when I was going through a similar transition as the OP is highlighting. At first, creating software was difficult and novel. Then after getting over that first learning hump, I spent a pretty long time feeling drunk on the power of being able to get computers to do exactly what I want. But familiarity breeds contempt, and eventually it felt more like "this is it?" and the pure act of creation for creation's sake lost a lot of its appeal.

I think this is a pretty common transition! For me, the path out of the doldrums is two fold: 1. I have a lot more going on in my life now that has nothing to do with computing (mostly family, but also other interests), and 2. I'm a lot more focused on what I'm creating and why it's useful than in the act of creation itself.

This almost certainly not what you want to hear, but this is why the quickly developing gen AI tools are increasingly exciting to me. I believe they open up the world of what can be created within a given time constraint. They also definitely (at least for me) make the act of creation itself less enjoyable, and I lament that. I'll probably always feel nostalgia for how I felt about the craft of programming a decade or two ago. But my perspective has just shifted from the "how" to the "what".

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.

[0] https://iep.utm.edu/fallibil/

> 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?

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...

> 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.

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.

your comment made me think of a passage in Italo Calvino's Invisible Cities:

Kublai Khan does not necessarily believe everything Marco Polo says when he describes the cities visited on his expeditions, but the emperor of the Tartars does continue listening to the young Venetian with greater attention and curiosity than he shows any other messenger or explorer of his. In the lives of emperors there is a moment which follows pride in the boundless extension of the territories we have conquered, and the melancholy and relief of knowing we shall soon give up any thought of knowing and understanding them. There is a sense of emptiness that comes over us at evening, with the odor of the elephants after the rain and the sandalwood ashes growing cold in the braziers, a dizziness that makes rivers and mountains tremble on the fallow curves of lhe planispheres where they are portrayed, and rolls up, one after the other, the despatches announcing to us the collapse of the last enemy troops, from defeat to defeat, and flakes the wax of the seals of obscure kings who beseech our armies' protection, offering in exchange annual tributes of precious metals, tanned hides, and tortoise shell. It is the desperate moment when we discover that this empire, which had seemed to us the sum of all wonders, is an endless, formless ruin, that corruption's gangrene has spread too far to be healed by our scepter, that the triumph over enemy sovereigns has made us the heirs of their long undoing. Only in Marco Polo's accounts was Kublai Khan able to discern, through the walls and towers destined to crumble, the tracery of a pattern so subtle it could escape the termites' gnawing.

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

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.

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"

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.

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...

I'm far from ready for being a parent yet, but this is honestly one factor I've noticed over and over again as a difference between my childless peers and the parents I encounter in work situations. Parents are just much better at prioritizing their time and energy and avoid perfectionism and trying to fix everything.

Indeed. Marriage alone led to a complete reevaluation of my priorities in life. I still want to make cool stuff but my hobbies are so far down my list of priorities right now I would have to be actually getting paid in order to justify spending time on stuff.

Perfectionist here. I'm on my third child. Can confirm - this person speaks the truth.

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

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.

Becoming comfortable with a stock computing environment is a powerful ability.

What I always find comedic, is that the rate I can do work is rarely gated by how fast I can interface with a computer. Even if I had a perfect brain/computer interface I think my productivity would maybe increase by 5-10%.

What is a real force multiplier is working on the RIGHT THING, not tweaking your vimrc config for the 50th time or creating your own build system because you are tired of Makefiles.

Like most things in life, there's a balance to be struck. If you always accept "good enough" and move on, things will be low-key crappy forever and never get to the point where they are actually good. If you never accept "good enough" and move on, you will never get anything useful done because you're going to always find some "one last thing" to polish. The best path is to pursue excellence when you can, but accept that sometimes you have to let things go.

There's a difference between picking up on some esoteric detail.in your company's product and making it your only mission to solve it, ok the detriment of everything else vs taking Friday afternoons for a month to fix a Terraform provider for the world. There are two kinds of lazy. The kind that makes us good programmers and the kind that makes us bad programmers. If you're gonna be the second kind of lazy and just wait for someone else to do it for you, you might as well become a manager at work and take credit for their work while you're at it.

> I hate working with teammates like this.

> They'll spin their wheels solving some insane problem no one asked them to do because it's "better" while ignoring the larger scope and goals of the project.

> But why? This is "good enough," and IME, if you sit on things like this long enough, eventually someone else comes along and does it.

Can't think of a bigger reason to avoid volunteer work on free and open source software than what you just said. Being a "wheel spinner" who cares too much about stuff is foolishness. People hate you and simultaneously take you for granted.

I submitted a patch for an annoying terraform provider once. It took about a week to fix and almost 3 years for them to merge it upstream. I got to learn Go and gained a much more solid understanding of how terraform works. I gained more from undertaking the project than from the actual fix.

> Consider the way you think it should be done is not the only "right" way and you'll open more doors for yourself.

Absolutely.

Most people automate things just barely enough to work. The thing is, having a barely working script or process can save someone thousands of hours. It's actually hugely valuable. Trying to make it more robust/productionized/whatever may have diminishing returns.

> submit a patch for it to fix my annoyance. But why?

To not be annoyed? How is that not a worthy goal in itself?

i really agree with this

"The reasonable man adapts himself to the world. The unreasonable man persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." (George Bernard Shaw)

But are those really different classes of people? Isn't everyone a maximizer up to a point where they think "good enough"? Where that limit changes between people, and for each person probably depending on area of interest, area of expertise, and so on?

As someone who sometimes thinks of themselves as an "optimizer", I feel the opposite take away. I spend too much time "polishing" trying to make something perfect, at the cost of actually getting things done.

> 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".

I suspect that if you dig deeper, the underlying cause of burnout being forced to spend a lot of effort over time and not being able to feel that you are living up to your values in return. You are running a marathon but never reach the finish line of the satisfaction of living according to your own moral code.

* That can come from overresponsibility if you have a value that says you should fix things that you see are broken.

* It can come from meaningless bullshit jobs if you have a value (which almost everyone does) that says your effort is meaningful.

* It can come from isolation if you have a value that it's important to be connected to others.

It can probably arise from any other value you might hold as long as you're forced to strive and yet can never reach it.

Honestly, I feel like values are deeply underconsidered in our current culture's thinking around psychology.

> parental burnout is a _very_ real thing

Doesn't often come from a lack of meaning though? Or maybe the meaning is more micro in this instance, and you wonder what the point is of telling them to pick up their dirty socks for the... 327th time.

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

A parody of the Serenity Prayer

https://en.wikipedia.org/wiki/Serenity_Prayer

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.