Live data from Hacker News

The curse of knowing how, or; fixing everything

notashelf.dev

21–30 of 458 posts

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

#21
Great article. I know it's not the main subject, but I really liked this part:

> Technical Work as Emotional Regulation

Men are taught to do that in most societies. You are unhappy - don't bother talking about it (men don't cry), do sth for the society - you'll receive praise in return and your pain will go away for a while. Even if nobody'll praise you - you'll think better of yourself. Same thing that makes our fathers obsessively fix any minor inconveniences around the house instead of going to the doctor with their big health problem.

Men often laugh at women talking for hours instead of fixing the damn problem (and it is frustrating to observe). But we often do not fix THE damn problem either - we fix other unrelated problems to feel better about the one we fear thinking about.

What's more tech-specific IMO is the degree to which our egos are propped by our code. Code is the one thing many programmers had going for them when they grew up. It's what made them special. It's what was supposed to pay for all the bullying in school. It's what paid their bills and made them respected. It's very hard not to make code your main source of value.

People praise "ego-less" programming, and most programmers adhere to the rules (don't get overly defensive, take criticism, allow others to change "your" code, etc.) But that's not actually ego-less programming, it's just hidding your ego in the closet and suffering in silence.

If you procrastinate when programming - it's because you feel your code reflects on your worth as a human being. It's all ego. Changing what you do won't change that. You need to change what you think.

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

#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 another change, or track this probability empirically, then compute 1/(1-p) this will tell you how much change you should "expect" to make to realize your desired improvement. If you have n interacting modules compute 1/(1-np). This will quantify whether or not to embark on the refactor. (The values computed are the sum of the geometric series in the probability which represents the expectation value)

So this is about how we manage change in a complex system in order to align its functionality with a changing environment. I suggest that we can do so by considering the smallest, seemingly innocuous change that you could make and how that change propagates through to the end product.

In the end, a solution may be to make systems that are easy and painless to change, then you can change them often for the better without the long tail effects that drag you down.

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

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

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

#26
post #22

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.

I went down this road and it doesn't free up time, you just get to fix many many more problems.

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

#29

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

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

#30

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…

The N systems case equation has to be wrong. I think you need either 1/(1-p)^n or 1/(1-p^n)
Post reply on HN