Live data from Hacker News

The curse of knowing how, or; fixing everything

notashelf.dev

191–200 of 458 posts

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

#191

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.

The sheer amount is zero with an ad blocker enabled. I consider UBO basically mandatory for browsing the web in 2025, too many sites are unusable and infuriating without it.

I had two popups visiting that medium link with uBlock Origin. Perhaps it is possible to get zero with UBO, but default settings don't seem to be enough.

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

#192
This happens on an organizational scale as well.

Once a company grows beyond a certain point it no longer needs to keep a razor focus on the core business, and a disproportionate amount of effort gets redirected to creating sometimes useful but often completely pointless and gratuitous internal tools. That way every middle manager gets to justify an ever growing number of reports and make his mark in the organization.

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

#193
re: Technical Work as Emotional Regulation

This is a lovely point, and probably why a lot of technical people like to take on tactile hobbies outside of work. Follow these woodworking steps and at the end you have a properly built cabinet. Or why doing the dishes can sometimes be soothing, etc.

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

#194
post #89

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

I think another important view is to consider how much you've already covered. As a young developer, I recommend spreading a bit wide. Try many technologies. Play with a new language every year. Focus on things you haven't done before, like, don't go from Python to Ruby, go from Python to C# or C++ or something.

But as you get older you want to shift from exploration to exploitation. It is hard to make progress on anything, both professionally and personally, if it first comes with another couple of person-weeks of learning something new, let alone person-months. Even though I find learning new things easier than ever because of the breadth of things I have covered, I find myself having to be ever more skeptical of what I will invest in in that way, because unlike a fresh developer with no skills who has little better to do than learn their toolset, I have skills that can be exploited to good effect. As a mature developer, I need to trade off not so much "what might this be useful for in the future versus the effort of learning now" but "what could I be doing right now with the skills I have rather than learning something new".

Particularly when the "something new" is a variant of a skill I've already picked up. It'd be great if I never again had to learn a devops deployment system. I've already had to learn three. Unfortunately I doubt I'm going to get away with that. It'd be great if I didn't have to learn another scripting language to do something, but I doubt I'll get away with that either. Your mileage will absolutely vary but it'll be something.

I know there's a memeset of the "old fogey who doesn't want to learn", but I really do see the learning costs now as the opportunity cost of using that time to exploit the ones I already have, rather than just grumbling about learning in general. At the moment the things I can't escape even if I try have been plenty to keep my learning skills well-honed.

So bear in mind that as you round out your skills, as you cover "scripting" and "static language" and "database" and "HTML" and "devops deploy" and "shell scripting" and "functional programming" and all the other categories you may pick up over time, it is natural and desirable to pivot to exploitation being more of your time than learning.

After all... what is all this learning for, if not to exploit the skills to do something, not just learn the next skill, then the next, then the next?

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

#195
post #148
post #129

Earlier quoted context omitted.

How do you validate an idea with 1000 paying customers if you don't have a product?

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

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

#196

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

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

#197

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…

Try vibe coding, I'm serious. Codex and Claude Code this past week have allowed me to:

- Build a local storage web app that can track my responses to the Sino-Nasal Outcome Test over time to journal my ongoing issues with chronic sinusitis.

- Build a web app that grabs Northern Colorado houses for sale, presents them on a map, and lets you search and browse them, with everything being cached for use offline in local storage. The existing site, coloproperty.com, has severe issues if you are out looking at houses and have spotty Internet connectivity, it's effectively useless.

I've been developing software for 40 years, but I'm not really a frontend guy. The first one Claude Code was able to basically one-shot, and then I asked for 3-4 refinements. The second one took me probably 40 back-and-forths to get going, but eventually was a fully working prototype using Codex.

It's the difference between using hand saws and chisels and planes, and using power tools. Hand tool woodworking is an amazing craft, but the right power tools can let you build nice things quickly.

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

#200
post #42

Software engineers, I love yall. To see the light at the end of the tunnel. To see some glorious perfect paradigm that maybe could be. I envy you. I grew up in a datacenter. Leaky air conditioners and diesel generators. Open the big doors if it gets too hot. Now let’s go back. Back to when we didn’t know better. Software doesn’t stay solved. Every solution you write starts to rot the moment it exists. Everything, eve…

your comment made me think of a passage in Italo Calvino's Invisible Cities:

Kublai Khan does not necessarily believe everything Marco Polo says when he describes the cities visited on his expeditions, but the emperor of the Tartars does continue listening to the young Venetian with greater attention and curiosity than he shows any other messenger or explorer of his. In the lives of emperors there is a moment which follows pride in the boundless extension of the territories we have conquered, and the melancholy and relief of knowing we shall soon give up any thought of knowing and understanding them. There is a sense of emptiness that comes over us at evening, with the odor of the elephants after the rain and the sandalwood ashes growing cold in the braziers, a dizziness that makes rivers and mountains tremble on the fallow curves of lhe planispheres where they are portrayed, and rolls up, one after the other, the despatches announcing to us the collapse of the last enemy troops, from defeat to defeat, and flakes the wax of the seals of obscure kings who beseech our armies' protection, offering in exchange annual tributes of precious metals, tanned hides, and tortoise shell. It is the desperate moment when we discover that this empire, which had seemed to us the sum of all wonders, is an endless, formless ruin, that corruption's gangrene has spread too far to be healed by our scepter, that the triumph over enemy sovereigns has made us the heirs of their long undoing. Only in Marco Polo's accounts was Kublai Khan able to discern, through the walls and towers destined to crumble, the tracery of a pattern so subtle it could escape the termites' gnawing.

Post reply on HN