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

241–250 of 458 posts

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

#241

Post by Aeolun »

DavidPiper wrote: post #180
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.…

Totally agree, standardisation makes everything so much more legible, even if there are problems with the standard. I also think there is a profoundly non-linear relationship (I don't want to say negative-exponential, but it could be), between: - The number of lines of code, or distinct configuration changes, you make to the defaults of an off-the-shelf tool - The cognitive and practical load maintaining that persona…

While I have experienced both sides of the equation here, I find it much more pleasant to have things specialized instead of standardized. Yes, you spend a bit of time maintaining the functionality, but all that functionality (and maintenance) is there in support of your goal.

Using standardized software often leads to spending half a day just trying to find a way to work around the limitation you face. The next level there is that you realize you can just fix it, spend half a day crafting the perfect PR, and then submit it into the void, leaving it hanging for half a year before someone gets to it.

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

#242

Post by aidenn0 »

pmarreck wrote: post #229
alias_neo wrote: post #175

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…

The fact that Android even has a notification history is huge. iOS does not!

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

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

#243

Post by pmarreck »

VladVladikoff wrote: post #196
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…

This has a name, it’s called CLS (cumulative layout shift) and Google actually penalizes SERP rankings for pages with bad CLS. More info on it on lighthouse.dev (if I recall the domain correctly).

that domain doesn't work :(

I did find this though, and I think I will add it to my medium post: https://web.dev/articles/cls

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

#244

Post by pmarreck »

robofanatic wrote: post #189
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…

For me the most annoying one is the cookie consent banner. Very few sites have clearly defined buttons like “Allow all” “Deny all” etc. but majority of them have a (intentionally) convoluted UI so that a lot of users just accept all.

I frankly wish the web standards group had released an API for these so they could be handled at the browser level.

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

#245

Post by Aeolun »

gbuk2013 wrote: post #154

> The trials are never complete. This is not true - one day you will be dead. Hopefully that day is a long way away but it will eventually come around. It is good to keep this in mind and spend some time coming to terms with this. If you do, the problem this article talks about will naturally fall away. Realise and acknowledge the limitations to your ability to act. Then consciously make a choice as to what you spend…

> This is not true - one day you will be dead.

Bold of you to assume that being dead also means the trials are complete. I imagine it as the beginning on the next set of trials.

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

#246

Post by matheusmoreira »

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

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

#247

Post by Aeolun »

aleph_minus_one wrote: post #85
Cthulhu_ wrote: post #48

Earlier quoted context omitted.

Family members asking you to fix their printers.

> Family members asking you to fix their printers. My honest, brutal answer is: "Your problem is very likely self-inflicted. Buy a decent Brother laser printer." This attitude resolves you of nearly all such requests. :-)

I don't think you even need to qualify that? Any Brother laser printer is a decent one. They don't have all that many models.

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

#248

Post by XCSme »

ajuc wrote: post #227
XCSme wrote: post #209

Earlier quoted context omitted.

Yes, if you change hardware, the software can break (a lot less often now than before though, as hardware changes are a negligible and they usually think about backwards compatibility).

I'm not sure if it's more or less often now, but over decades almost everything breaks one way or another. Even if your code, OS and hardware had no bugs and was designed perfectly and you keep the same hardware to run you code forever - there's layers under the hardware - the reality outside the computer. You have written perfectly secure website. Then quantum computers happen. Countries are created and fall apart.…

That's most probable to happen, but there are still example of hardrware/devices created many years ago that function exactly the same.

If you take a Tamagotchi device from 30 years ago, it will likely still work as well as it did when it was released.

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

#249

Post by pmarreck »

asoneth wrote: post #212
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 you're curious to learn more, this is often referred to as "layout shift". There are black-hat designers who deliberately use it as a dark pattern -- you might notice a suspicious number of cases where the most common click target is replaced by a click target (or late-arriving popup) for submitting an email address or entering the sales funnel. But typically it's just bad design. In the latter case, you could qui…

I just found that URL independently! I just added it to my medium post.

Why do we even show interactable elements when the final layout isn't completed yet?

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

#250

Post by sanderjd »

shoemakersteve wrote: post #195
totaa wrote: post #148

Earlier quoted context omitted.

landing page / waitlist / speaking with customers you shouldn't write code until you know someone is willing to buy i'd say somewhere between 20 < n < 100 for B2B makes sense, rather than 1000

> you shouldn't write code until you know someone is willing to buy This is kind of a weird line to see in a thread where people are talking about coding for the joy of the craft. Also makes me think about where we would be if everyone who contributed to OSS projects over the years thought this way. And to be clear, I'm not shunning or criticizing, having this mindset is totally fine and I'm sure it does well for you…

Yeah it's just a totally different thing than what the thread starter was talking about.

This may be good advice for bootstrapping a business (though personally I feel like people who do this are being pretty hostile to their customers by pretending something exists when it doesn't at all, which is not to say it isn't effective) but it is just irrelevant to someone wanting to build something for themselves.

Post reply on HN