Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The curse of knowing how, or; fixing everything

notashelf.dev

Post reply on HN
Print view View original

71–80 of 458 posts

Re: The curse of knowing how, or; fixing everything

#71

Post by WJW »

TeMPOraL wrote: post #40
d4rkn0d3z wrote: post #24

I think about this from the perpective of change management. Every defect I hope to fix entails a change, which has a certain probability of creating another irksome deficiency or incompatibility. When building complex systems I try to design them with the end state, that you describe very well, in mind. Each time you set about to make a single change ask what is the probability (p) that this change results in anothe…

Does this help explain why any simple household activity has a frustrating ~50% chance of turning into a string of dependencies and dependents that make you spend 10x the time you expected on it all? E.g. you figure it'll take a minute to take the trash out and wash your hands. But on the way you discover you run out of trash bags, and while washing your hands you run out of soap, then as you pick the refill bottle f…

When reality doesn't match your expectations, why do you blame reality instead of your expectations? Especially for thing like running out of soap, trash bags or towels that should be at least 90% in your own control.

Re: The curse of knowing how, or; fixing everything

#72

Post by davnicwil »

Fractal complexity.

It's not only that solutions decay, though that's true, but also that the search for improvement itself becomes recursive.

When you identify something can be improved, and fix it, your own fix and every individual step of it now become the new thing that can be improved. After the most fleeting of pauses to step back and appreciate your work, this becomes your new default.

Indeed I often look back at my own solutions and judge them more harshly than I would ever judge anyone else's. Why? Because as the article says, I know much more about how it works. Cracks increase surface area by a lot. I know about a lot of the cracks.

I wrote a blog post [0] about this mindset getting in the way of what you care about in product development which you might enjoy, if you enjoyed this article.

[0] https://davnicwil.com/just-build-the-product/

Re: The curse of knowing how, or; fixing everything

#73

Post by GardenLetter27 »

urig wrote: post #62
GardenLetter27 wrote: post #61

This is well-written. I think LLMs can help a bit here too - the other day I was watching a rare, old film with my wife and the subtitles kept de-syncing. I.e. the frame-rate was slightly different as well as a fixed offset. So I explained it to Claude and made it write a Python script where I could manually set a few fixed times and it would adjust the SRT file, and it worked perfectly. I literally paused the film a…

My takeaway from this post is not to find better ways to do, but to find a way not to.

Yeah, but the main thing is I didn't publish the script, or try to develop it into a more generic tool with more features (automatic synchronisation, etc.) - that is where things become overwhelming.

Like I have published a FOSS tool from some scripts I had for managing VPNs, and there I get constant issues around new providers / updates and it not working in people's specific environments (which I can't test).

The LLMs make it viable to write quick throw-away scripts with almost no time investment, and as such you feel no pressure to share or improve them.

Re: The curse of knowing how, or; fixing everything

#74

Post by alexisread »

Melkaz wrote: post #15

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

Playing devil's advocate here, but is that simply validation that stuff you've written is actually useful? This could be seen as a proxy for self worth, which if something is useful, helps stave off that nagging anxiety in the back of your head? The question here is, is that a useful driver to build new things, or do we let things go? That's kinda similar to the article's premise.

(takes one to know one here)

Re: The curse of knowing how, or; fixing everything

#75

Post by pjc50 »

moffkalast wrote: post #67
galbar wrote: post #51

Earlier quoted context omitted.

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.

I'm sure some mathematicians would disagree.

I think applied mathematicians started to encounter this reality of the impure world the first time someone taped a dead moth into the logbook of the Harvard Mark II.

Re: The curse of knowing how, or; fixing everything

#76

Post by bonoboTP »

erulabs wrote: post #42

Software engineers, I love yall. To see the light at the end of the tunnel. To see some glorious perfect paradigm that maybe could be. I envy you. I grew up in a datacenter. Leaky air conditioners and diesel generators. Open the big doors if it gets too hot. Now let’s go back. Back to when we didn’t know better. Software doesn’t stay solved. Every solution you write starts to rot the moment it exists. Everything, eve…

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

Re: The curse of knowing how, or; fixing everything

#77

Post by lelanthran »

PixelForg wrote: post #52

Hopefully the future me is able to relate to this, because I really feel like I'm in a rut when it comes to working on personal projects. I have many ideas that I want to build, but I'd have to learn new languages, yet I just can't sit and go through the documentation every day like I should. Still haven't finished the rust book. The other way is start building already, and if you come across a block, then learn abou…

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

Re: The curse of knowing how, or; fixing everything

#79

Post by bonoboTP »

moffkalast wrote: post #67
galbar wrote: post #51

Earlier quoted context omitted.

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.

I'm sure some mathematicians would disagree.

Math can be greasy and messy. Definitions can be clumsy in a way that makes stating theorems cumbersome, the axioms may be unintuitive, proofs can be ugly, they can even contain bugs in published form. There can be annoying inconsistencies like optional constant factors in Fourier, or JPL quaternions.

Yes, prototypical school stuff like Pythagoras are "eternal" but a lot of math is designed, and can be ergonomic or not. Better notation can suggest solutions to unsolved problems. Clumsy axioms can hide elegant structure.

Re: The curse of knowing how, or; fixing everything

#80

Post by A_Stefan »

Thank you for sharing your personal journey. I too have (too) many ideas floating around, getting ready to fix everything I see broken, ignoring what's really important. So I whole-heartedly agree with "You learn how to program. You learn how to fix things. But the hardest thing you’ll ever learn is when to leave them broken."
Post reply on HN