Live data from Hacker News

The curse of knowing how, or; fixing everything

notashelf.dev

391–400 of 458 posts

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

#391

Earlier quoted context omitted.

I feel like Open Source is the perfect place to apply that sort of effort. Also hobbies. You don't owe anyone anything, so you can chew on a problem just as long as you like.

Open source just means you're being taken advantage of. You're working for free to make the lives of people who look down on you easier. They won't do it themselves, their time is too valuable for this worthless nonsense. Better to leave things as is until some unpaid perfectionist can't stand it anymore and fixes it free of charge. Never forget the words of Zed. https://web.archive.org/web/20120620103603/http://zeds…

I really disagree with what reads like a snide shot at the original post. I'm not saying wait around for some perfectionist to do it, I'm talking about practical considerations in a fast paced and resource constrained environment, something probably many people run into all the time. I'm also not talking about poaching some single maintainer-in-a-garage's pet project and using it for my own needs. I'm talking terraform providers, which are often contributed to by very, very large companies with deep pockets and resources to do so, which is in their interest, because they want it to be easier to use their products.

I also contribute to OpenTofu whenever possible. I work for myself and don't have the resources as the companies that contribute to these projects.

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

#392

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…

> an interface should not be interactable until a few milliseconds after it has finished (re)rendering

And should an interface be interactable for a few milliseconds longer, after it has disappeared?

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

#393

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…

> I feel uncomfortable having gaps in my knowledge Understanding why I feel this, when I have, has always proven enlightening. I find it never has to do with the gap or what would fill it.

Same. For me, I think the discomfort comes from perfectionism, and anxiety about job-hunting ("I need to fill in all my weaknesses"), and fear of missing out on some cool niche.

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

#394

Earlier quoted context omitted.

I've had this a few times, particularly on mobile, where you're doing something and some pop-up will steal focus, but of course you were tapping or swiping or something the exact instance it popped; it stayed just long enough for the after-image on your retinas to catch a single word and you realise it might have been important, but it's gone now, with no sign. This happened to my just the other day; I was purchasing…

I believe it's an INTENTIONAL BEHAVIOR in Facebook. Particularly the mobile web interface...want to show someone a video, but you're on the can, and really, it's going to be a minute while you wash up (or similar example lasting 40 seconds) You're not going to be able to do it. They're not on facebook, you can't just link to the video, you're going to hold the phone carefully but the bared fraction of their palm will…

That’s ridiculous!

I end every iMessage with a(n) n

Hahaha

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

#395
post #363

Earlier quoted context omitted.

> 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 a ‘mis-tap’). Yeah, notifications are an interesting corner case where by their nature you can probably assume a user isn't anticipating one and it might be worth ignoring input for a bit. > Also, I’d argue a ‘failed tap’ in a power user workflow is not actually something that…

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.

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

#396
This article resonates. After coding obsessively for almost 20 years, it's muscle memory. I don't have to find bugs anymore, they find me.

I can feel their presence. Pretty much all the bugs I write now are intentional "will focus on this later" kind of thing. I know exactly what I'm neglecting, why I'm neglecting it and when is the right time to address. I can write bug-free code if appropriate though it takes longer to do and not always possible in a company environment where there are deadlines.

It is a burden to see all the issues and complexity and not being able to address it fully.

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

#397

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…

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

> However, there are times where you're tapping on a familiar app whose flow you know intimately and you know exactly where Y is about to appear and you want to tap on it as fast as you can. In those cases, it is absolutely infuriating if the app simply ignores your input and forces you to tap again.

This is very true, but the app has to be explicitly designed around this e.g. by not injecting random UI elements that can affect the layout.

Unfortunately this seems to be regressing in modern app UX, and not just on mobile. For example, for a very long time, the taskbar in Windows was predictable in this sense because e.g. the Start button is always in the corner, followed by the apps that you've pinned always being in the same locations. And then Win11 comes and changes taskbar layout to be centered by default instead of left-adjusted - which means that, as new apps get launched and their icons added to taskbar, the existing icons shift around to keep the whole thing centered. Who thought this was a good idea? What metric are they using to measure how good their UX is?

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

#398
I think the flip side of this is at some point after looking at enough crap software, you feel free to write your own. You can actually solve your directly problems in simpler ways with a lot less code than more generic tools.

I've had great fun writing little daemons, deployment and config management systems, my own tcp networking protocols, process management, and using these tools to "build my own k8s" more or less. It's more fun for me to build and understand these relatively simpler systems than pick up all the tech debt of some more established ones.

And, given enough time, it can be very stable, fast, and tailored to my specific needs.

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

#399
post #202
post #137

Earlier quoted context omitted.

> Software doesn’t stay solved. Every solution you write starts to rot the moment it exists. I don't really agree with this. Yes, it gets outdated quickly and breaks often if you build it in such a way that it relies on many external services. Stuff like relying on "number-is-odd" NPM package instead of copy-pasting the code or implementing it yourself. The more dependencies you have, the more likely it will break. I…

I remember when Turbo Pascal 7.0 programs started failing with Division by 0 error cause Turbo Pascal runtime does calibration loop at the start to calculate how many no-ops to sleep for 1 millisecond. So - your HelloWorld written 10 years ago suddenly stopped working after CPU you run it on got too fast.

I remember that bug. I also remember that there were generic patchers that could fix any random .exe compiled with Turbo Pascal without even having to recompile it.

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

#400
post #349

Earlier quoted context omitted.

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.

Confirmation before calling would be nice. I've accidentally made calls when trying to get more information about a missed call. (I've also had Siri pocket dial, but I e got that disabled now.)

That too! 99% of the time I tap a missed call, it's because I want to see more info about the call or the contact or if there was a voice mail. My phone should never make a call unless I explicitly tap a big ol' "CALL" button. It should never be the default action for tapping on a contact or a missed call.
Post reply on HN