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

141–150 of 458 posts

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

#141

Post by Philpax »

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…

A visual depiction: https://youtu.be/AbSehcT19u0

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

#142

Post by aleph_minus_one »

piva00 wrote: post #35
figassis wrote: post #25

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.

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 hou…

> Or just have another hobby not involving programming.

This can actually make things (much) worse:

Since you have now another topic you are insanely passionate about, you see a lot of additional things in the world that are broken and need fixing (though of course typically not via programming).

Thus, while having a very different additionally hobby (not or barely involving programming) clearly broadens your horizon a lot, it also very likely doubles the curse/pain/problem that the original article discusses.

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

#144

Post by chamomeal »

XCSme wrote: post #137
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…

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

That sorta supports the point the article was making though:

> ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be.

Is, to me, almost the same sentence as

> Every solution you write starts to rot the moment it exists

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

#145

Post by throwanem »

1dom wrote: post #128
throwanem wrote: post #18

Earlier quoted context omitted.

What would it mean to be finished with life? Where are you going in such an all-fired hurry?

Trying to get to the world that all the people unlike us live: a world where a brain can power down for a bit because everything is fine for now.

You think that's where "people unlike us" live? My God, have you met any?

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

#147

Post by hanselot »

Why do I have 244gb of environments and beat myself up when I delete something to play a game?

This deep desire to affect change in a controllable way...

This infinite desire for self value defined by external validation.

It's not sustainable. Perfection can only be obtained by observation of perfection of combined self through self and other.

It's okay to discard parts of yourself to balance yourself with your counterpart. A willing violation is no longer a violation.

Not observation of one or the other on a pedestal, but accepting that both are vital parts to the system and observing the perfection that comes from co-iteration.

Essentially turning a binary system quantum.

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

#148

Post by totaa »

rcfox wrote: post #129
speedupmate wrote: post #119

Earlier quoted context omitted.

Don't code, validate your ideas first (to first 1000 paying customers if monetization motivates) and 99% is not even worth to be started with, life is just too short for that. With AI there's nothing to be ashamed of as it is "what you can dream of, you can get today". There's not much left in programming in most of the projects (that are just repeated code, output, what not over and over) after AI , tools are just t…

How do you validate an idea with 1000 paying customers if you don't have a product?

landing page / waitlist / speaking with customers

you shouldn't write code until you know someone is willing to buy

i'd say somewhere between 20 < n < 100 for B2B makes sense, rather than 1000

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

#149

Post by XCSme »

chamomeal wrote: post #144
XCSme wrote: post #137

Earlier quoted context omitted.

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

That sorta supports the point the article was making though: > ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be. Is, to me, almost the same sentence as > Every solution you write starts to rot the moment it exists

I mentioned updating is only necessary if you plan to keep developing the software.

If you build it once, and the existing functionality is enough (no plans to add extra features ever again), then you can remove all external dependencies and make it self-contained, in which case it will be very unlikely to break in any way.

As for the security aspects of not updating, with the proper setup, firewall rules and data sanitization, it should be as secure 10 years later as any recently developed software.

Post reply on HN