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

411–420 of 458 posts

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

#411

Post by strangegecko »

matheusmoreira wrote: post #246
codelikeawolf wrote: post #101

> We write a new tool because we are overwhelmed. Refactor it, not because the code is messy, but your life is. We chase the perfect system because it gives us something to hold onto when everything else is spinning. This really got to me because I've been doing this without realizing it for as long as I can remember.

Same. Low tolerance for frustration. Starting something is easy. 20% of the work gets 80% of the results. It's beautiful to see. Then you gotta do the last 20% and you see the 80% of the job ahead of you. Seeing it through quickly gets frustrating. It turns into a job. How to get away from this? Just start a new project...

Does that cycle connect to the question of why you're starting those projects in the first place? If it's "play" and experiencing joy, then quitting after the fun part would seem to do its job.

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

#412

Post by slt2021 »

foobarchu wrote: post #408
talos_ wrote: post #367

Earlier quoted context omitted.

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)

in the world of music known as Sophomore slump:

  In the world of music, there is a common phenomenon known as the sophomore album curse/syndrome, where newly popular artists often struggle to replicate their initial success with their second album, which is often characterized by struggles in changing musical style
https://en.wikipedia.org/wiki/Sophomore_slump

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

#413

Post by slt2021 »

pmarreck wrote: post #235
majewsky wrote: post #171

Earlier quoted context omitted.

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.

Reader mode is a thing, but if you can suggest a better (ahem) medium to repost it to, I'd be happy to! (Honestly, I'm sort of with you on the medium thing, but I posted this years ago now...)

github pages + markdown/jekyll ?

every single medium.com blog could be just github pages in my opinion

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

#414

Post by strangegecko »

bookofjoe wrote: post #152

As a non-techie (retired M.D.) who wouldn't know source code from Morse code, reading these comments is extremely absorbing.

HN is really unique in that regard for me.

I don't come here that often, but when I do, I usually end up getting stuck in what is often a borderline off-topic discussion of life challenges I'm dealing with.

This morning, I started out trying to use NotebookLM to solve my "what would a meaningful life look like for me" problem and ended up spending over an hour on this thread (mostly reading/thinking). I only came here as a symptom of procrastination when the friction I encountered with that main goal became too much.

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

#415

Post by owebmaster »

dpifke wrote: 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…

> 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

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

#416

Post by CommenterPerson »

I enjoy building or fixing physical stuff. So much that when I visit family members (or even close friends) I take my tools along. People are usually happy at the results. It has become something of a pleasant joke among the visit-ees.

The key is to enjoy what you are doing. If anything becomes a drudge, search for something else that matches your talents and is enjoyable.

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

#418

Post by __turbobrew__ »

throw_away_0613 wrote: post #59

As I'm getting older, I want things to be as standardized as possible, and just don't worry about the details. I have learned from my mistakes The script I made for deployment, because existing solutions didn't "feel" right, required a lot of work and maintenance when we later had to add features and bug fixes. Another script I made for building and deploying Java applications, because I didn't like Maven and Puppet.…

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.

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

#419

Post by ppipada »

Wow, this post hit just too close to me. I came to same conclusion quite a while back (the author also mentions that we most probably always know this); BUT never able to get out of that mindset. I think fixing boundary issues is a hard problem, but still solvable. Dealing with Your Things (or atleast the ones you think are yours), i.e stuff that you have marked as your boundary, seems much much harder to deal with.

My mind has argued, and won to some extent, the opposite, but within a boundary: if you are responsible, why not do it better, if you are not doing it better, what is the point of it all?

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

#420

Post by mgoetzke »

ziml77 wrote: post #253
pmarreck wrote: post #159

Oh wow. This hits hard in the feels. Here's my personal submission for "UI problem that has existed for years on touch interfaces, plus a possible solution, but at this point I'm just shouting into the void": https://medium.com/@pmarreck/the-most-annoying-ui-problem-r3... In short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering, or especially, while it is still in…

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

Or apps like Skype which popup a dialog while you are typing, and when you where in the middle of pressing space while that happens, then you auto-answer a call you didn't know existed a second earlier.
Post reply on HN