Live data from Hacker News

The curse of knowing how, or; fixing everything

notashelf.dev

371–380 of 458 posts

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

#371

Earlier quoted context omitted.

TIL Android has a notification history. I've been using Android phones for over a decade and never new.

You can use this fact to see deleted messages on whatsapp. Just enable the notificaion history and Now whenver someones sends you somethign regrettable and deletes it you can still see it in notif history. The reason you need the notif history is whatsapp actually live wipes the notifictions for deleted messages.

This is curiously specific, does this happen a lot?

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

#372
post #305

Earlier quoted context omitted.

> In short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering I was a console game developer working on UI for many years so I am deeply familiar with the problem when a UI should be responsive to input while the visuals are changing and when it should not. You might be surprised, but it turns out that blocking input for a while until the UI settles down is not what…

These are great points. But I would debate the 100x point a little. And I think there are some cases where ignoring fast taps is clearly preferable. I’m specifically thinking about phone notifications that slide in from the top – ie, from an app other than the one you’re using. So we have two options: ignore taps on these notification banners for ~200ms after the slide-down (risking a ‘failed tap’) or don’t (risking…

I am 99% sure the NY Times Games app on Android is blocking input until fully rendered on its 'home' screen where all the games are listed, and it drives me nuts. I tap on the element I want and nothing happens, I have to tap again. Maybe some kind of overlay or spinner would help signal that it's not accepting input would help? Arg.

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

#373
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…

In less poetic terms, the progression I talk about is "copy, choose, create". First, we learn to copy a solution. Later, we know enough solutions that we can choose the best for the situation and copy that one. Finally, we know enough to create our own solutions that are well adapted to the problem.

For people wanting to dig into this idea some more, I'd recommend the book by Austin Kleon called "Steal Like An Artist." Also, there is some nuance in the book about copying and stealing, without being a thief.

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

#374
It's the Moneymaker effect. It's less that you became a programmer and more Linux is so broken that you have to learn to code to get anything done. Couple that with cheap student loans and "learn to code" and now anyone is a programmer, not just those snooty researchers.

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

#375

This just sounds like perfectionism. I believe it is a curse, because I hate working with teammates like this. They'll spin their wheels solving some insane problem no one asked them to do because it's "better" while ignoring the larger scope and goals of the project. I've tried to coach people out of this mindset, because I used to have it very early in my career, til I realized the sheer impracticality of it. I use…

Most people automate things just barely enough to work. The thing is, having a barely working script or process can save someone thousands of hours. It's actually hugely valuable. Trying to make it more robust/productionized/whatever may have diminishing returns.

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

#376

Earlier quoted context omitted.

I wish this meme would die already. You're just writing some mumbo jumbo that you've learned (at least most of it) in a couple of years, chill out.

The tools we use shape us. Habits have inertia. The parent may be hyperbolic but it's not wrong. But it didn't start with computers or programming, this tendency has been a long time developing.

For most programmers is that shape round?

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

#377
post #354
post #281

Earlier quoted context omitted.

Maybe substack?

Or Ghost. The reading experience was so good on Medium a couple of years ago.

Analogy to Dilbert’s/Peter’s law: saas will be enshittified until the marginal revenue gain of next enshittification level is 0.

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

#379

This just sounds like perfectionism. I believe it is a curse, because I hate working with teammates like this. They'll spin their wheels solving some insane problem no one asked them to do because it's "better" while ignoring the larger scope and goals of the project. I've tried to coach people out of this mindset, because I used to have it very early in my career, til I realized the sheer impracticality of it. I use…

I submitted a patch for an annoying terraform provider once. It took about a week to fix and almost 3 years for them to merge it upstream. I got to learn Go and gained a much more solid understanding of how terraform works. I gained more from undertaking the project than from the actual fix.

> Consider the way you think it should be done is not the only "right" way and you'll open more doors for yourself.

Absolutely.

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

#380

This just sounds like perfectionism. I believe it is a curse, because I hate working with teammates like this. They'll spin their wheels solving some insane problem no one asked them to do because it's "better" while ignoring the larger scope and goals of the project. I've tried to coach people out of this mindset, because I used to have it very early in my career, til I realized the sheer impracticality of it. I use…

I submitted a patch for an annoying terraform provider once. It took about a week to fix and almost 3 years for them to merge it upstream. I got to learn Go and gained a much more solid understanding of how terraform works. I gained more from undertaking the project than from the actual fix. > Consider the way you think it should be done is not the only "right" way and you'll open more doors for yourself. Absolutely.

Had this exact experience and why I don't bother anymore and fork if it's absolutely necessary.
Post reply on HN