The curse of knowing how, or; fixing everything • Hacker News Board

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

#231

Post by pmarreck » Tue, May 06, 2025, 2:14 PM UTC

riggsdk wrote: post #219

crazygringo wrote: post #214

Earlier quoted context omitted.

Yes, 1,000%. The one I don't quite know how to solve is when I'm tapping a device to connect to -- whether a WiFi router or an AirPlay speaker or whatever -- and I swear to god, half the time my intended device slides out from under me a newly discovered device enters above and pushes it down. Or sometimes devices disappear and pull it up. Maybe it's because I live in an apartment building with lots of devices. I've…

To me the BIGGEST annoyance is the iOS “End call” button. Just as I’m about to tap it, the other person ends the call and what I’m actually tapping is some other person on my call list that it then immediately calls. Even if I end the call quickly they often call back confused “You called, what did you want?” Apple: PLEASE add a delay to touch input after the call screen closes.

My solution would account for this as well.

The solution needs to be global. Literally, if any part of the screen just changed (except for watching videos, which would make them impossible to interact with), add a small interaction delay where taps are no-op'd.

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

#232

Post by monkeyelite » Tue, May 06, 2025, 2:14 PM UTC

majewsky wrote: post #171

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…

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.

Sometimes you see reductionist comments about websites just being for displaying text - but for medium it’s true.

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

#233

Post by exabrial » Tue, May 06, 2025, 2:15 PM UTC

This is precisely why RaspberryPi/Raspbian broke every _fricken_ tutorial on the internet by moving /boot to /bootfs

ok... I mean great.

There's also a chance it's probably just fine. Leave it alone if it's not causing problems.

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

#234

Post by sanderjd » Tue, May 06, 2025, 2:15 PM UTC

PixelForg wrote: post #105

maxbond wrote: post #89

Earlier quoted context omitted.

I like to say programming is about knowing which rabbit holes to plunge down and which to step over. There's too much to know to go depth-first down every rabbit hole. Go breadth first and accept gaps in your knowledge - everyone has them. If something never comes up and never causes an issue you need to look into, and the project gets done, it doesn't matter. There's always an improvement that could have been made,…

Thank you for your comment, especially for this > I've written a lot of Rust. I've read less than half of the Rust book. Just knowing that there's someone out there who has worked like this or has been in the same situation gives me enough confidence to go through it!(the just write code part) I've gone through so many resources (including the book) and I never managed to finish any of them. But I think now I need to…

By the way, I fear I'm harping on "AI tools can be really useful" here, but I really find that learning new things is my favorite way to use these tools.

You said that you don't want to use them to generate code and just be a reviewer. I definitely feel that! But you can instead use them like a tutor helping you learn to the code yourself. "I'm trying to do xyz in Rust, can you show me a few techniques for that?" Then you can conversationally ask more questions about what's going on. Maybe eventually you can go read relevant sections in the book, but with the concepts better motivated.

I do this all the time when learning new things. It's not a canonical source of information, but it can be a useful guide.

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

#235

Post by pmarreck » Tue, May 06, 2025, 2:15 PM UTC

majewsky wrote: post #171

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…

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

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

#236

Post by ChrisMarshallNY » Tue, May 06, 2025, 2:16 PM UTC

> The Illusion of Finality

One of the most important skills that I've learned, through writing ship software, is "Knowing what 'Done' looks like."

There's a point, where -even though there's still stuff that I have to do- I need to declare the project "done," wrap it up, slap a bow on it, and push it out the door.

There's always a 2.0.

Writing in an iterative manner (where I "discover" a design, as I develop the software), makes this more difficult. One thing about "hard" requirements, is that there's no question about what "Done" looks like.

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

#237

Post by monkeyelite » Tue, May 06, 2025, 2:16 PM UTC

PixelForg wrote: post #52

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

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

#238

Post by pmarreck » Tue, May 06, 2025, 2:17 PM UTC

mjevans wrote: post #207

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…

If a user is interacting, DO NOT UPDATE the list / models / etc. If an update is required, rather than just desired, freeze all input so the user knows it's about to update, this might be accompanied by a quick 'fade' or other color shift to indicate an update is about to be pushed and they should release and re-plan actions.

It seems related to "debouncing", where you delay a lookup (to autocomplete, etc.) until a certain delay after a user stops typing

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

#239

Post by sanderjd » Tue, May 06, 2025, 2:17 PM UTC

speleding wrote: post #136

PixelForg wrote: post #105

Earlier quoted context omitted.

Thank you for your comment, especially for this > I've written a lot of Rust. I've read less than half of the Rust book. Just knowing that there's someone out there who has worked like this or has been in the same situation gives me enough confidence to go through it!(the just write code part) I've gone through so many resources (including the book) and I never managed to finish any of them. But I think now I need to…

Another approach that may help you, that worked for me. I was not familiar with rust so I wrote an initial proof of concept in another language (Go in my case). Then I asked Claude AI to translate it to Rust. It compiled on the first try, the only bugs being problems in the source file I gave it. Then I iterated a bunch of times by saying "please make this more rustacean style". I only tend to use AI for assistance,…

Yes! No tool has ever helped me more with the blank page problem.

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

#240

Post by rocqua » Tue, May 06, 2025, 2:17 PM UTC

d4rkn0d3z wrote: post #122

rocqua wrote: post #30

Earlier quoted context omitted.

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

I think it says 1/(1-np).

That's what it says in the original post. It is also non-sensical. If the probability is 10% (p=0.1), and the number of systems is 11 (n=11), then you get 1/(1 - 11*0.1) which is -10.