Live data from Hacker News

The curse of knowing how, or; fixing everything

notashelf.dev

401–410 of 458 posts

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

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

Some people will have to go through the burnout phase and reach rock bottom to learn this advice, I'm afraid. Only from there can they see the consequences of not leaving everything broken, and decide to do something else.

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

#403
post #363

Earlier quoted context omitted.

I don't view notifications as a corner case. I think two factors are key: 1. Can the user predict the UI change? This is close to the static vs dynamic idea, but doesn't matter if the UI changes. If the user can learn to predict how the UI changes, processing the tap makes more sense. This allows (power) users to be fast. You usually don't know that a notification is about to be displayed, so this doesn't apply. 2. I…

> Often even better is to offer undo (if possible). 100%. Any user operation should either be undoable (ideally) or require a level of confirmation if not undoable. Accidentally dismissing a notification is neither, which makes it a real UX pitfall.

For that reason, it's wonderful when games provide a log of actions and/or recent dialogue, so you can easily see what you missed. That kind of functionality seems less common outside games.

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

#404
I was with the author right up to the Marc Aurelius quote "You have power over your mind—not outside events. Realize this, and you will find strength."

The funny thing is that actual engineering _requires_ being resilient in the face of unpredictable external events.

And his quote "You run the thing, and it works. Or it _doesn’t_, and you fix it." shortly after is fundamentally the difference between coding, and engineering.

And maybe that is the true curse of our profession. We call ourselves engineers, but we never behave like it. Engineering isn't "scratching the itch to build". It is defining requirements well, building something that fulfills the requirements, and then leaving well enough alone.

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

#406

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.

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

Sometimes kids do make one feel that the house is on fire though I think I won't be looking forward to be hugged every evening by a burning house excited to see me.

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

#408
post #367
post #283

There's a quote I learned when doing theatre, which I've seen attributed to either the stage magician Doug Henning or possibly Stanislavski, describing the process of art as taking something that's difficult and making it habit , then taking something that's habitual and making it easy , and then taking something that's easy and making it beautiful . For example, as an actor, you learn your lines by rote (they become…

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, wh…

> "the first album was about what we could; the second one was about what we should"

Funny enough, when you apply this to software it becomes the pejorative "second system syndrome" (Brooks, 1975)

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

#409

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…

To me this doesn’t sound like you find programming very fun - but as a chore to get to something else. That’s not a bad thing - just find out which part you actually want to do

Responding to this as someone who has struggled with similar inner conflicts, the "chore to get to something else" rings true for me.

In my case, being good at programming was my means to feeling valued and valuable, and the sense of "I should" came from feeling useless and not needed, specifically after being forced into early retirement. (but the same pattern has been with me since childhood)

Not having a family or passion project (which fills those gaps for many people as far as I can tell) made all of this feel very urgent and threatening.

> which part you actually want to do

Which sounds like such a simple question, but I found it hard to answer. For me, it quickly turns into "what is worth doing", which is a bit of a monstrous question. I'm still trying to figure out whether this is a result of being mostly estranged from myself and the question of "what do I want" due to being so overwhelmed with trying to succeed with the external constraints and demands the world places on us.

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

#410

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…

There was a recent study that suggested that some people are good at solo projects and some at team projects. And not so many that are good at both.
Post reply on HN