sshine

Joined 12 years ago

Karma
6,547
Submissions
2,655
Member since
Jan 13
https://simonshine.dk
View on Hacker News

Recent submissions

Comment · 17 hours ago
I think perhaps my use of the word skill atrophy here is wrong.

Skill atrophy is when you're good at something, and because you don't practice it regularly, it gradually wanes over years, like when my former CEO said "I used to be good at programming" because he made a tiny chess computer and sold millions of copies, and now he... just doesn't code, and hasn't for decades.

Skill atrophy would be if I opened my text editor and I wasn't able to code after two years. Being a polyglot, there's always some language that feels rusty. And now they all do. But it hasn't been long enough to feel the atrophy.

What I'm describing is laziness to understand a problem domain.

> I couldn't imagine submitting a PR for code that I didn't understand and couldn't explain.

I could. I do it constantly for projects where that premise is acceptable. And I've worked on projects where many people merge to main once an established set of steps has completed. "How does it work?" and "Show me the thing working." are good gates. Understanding (or even reading) the code is not a mandated prerequisite.

As an Open Source contributor? No way. Exactly because I'm contributing to projects where people don't share basic premises. Some people code by hand, others use coding agents. If I were compiling stuff and everyone else was hand-writing their assembly, I'd read and tidy up my generated assembly, too.

> AI provides a great opportunity to learn at an even faster rate by using AI to help explain complex topics.

Totally. Better solutions come through those explainer sessions.

Comment · 1 day ago
> skill atrophy is real

It is also both a choice and avoidable.

Atrophy happens when you trade understanding for productivity. Productivity benefits your employer and your KPIs, but not your understanding and your opportunities going forward.

Understanding used to be an unavoidable of the exploration process, and writing documentation used to be the thing that never got done. Now, writing documentation is automatic, but reading it still isn't.

I've been managing a team of interns at my last job, and as they were all equipped with coding agents, they'd deliver complete solutions to problems once or several times per day that would normally take days, or weeks if you factor in necessary learning.

As review of their understanding, and for the sake of my own cognitive debt, I would first ask them the question "How does it work?" and they usually couldn't answer. After a handful of tasks, they started preparing answers. This forth-and-back is still more shallow than getting the deep knowledge chiseled through hours of trial and error, debugging and wrong directions. Spending two hours to find a problem to realize you forgot to save or upload a file, or had an x instead of a y. I look back with nostalgia, and I wonder if there weren't always better ways, and we just get to pick them now. I can literally convert any task, solved or not, into a quiz that brings me towards understanding, in rainbow-colored pig latin.

Comment · 1 day ago
quantify poor and shelter
Comment · 1 day ago
> > America's poor have a higher standard of living than medieval kings.

> False Equivalence, Red Herring, Chronological Snobbery, Fallacy of Relative Deprivation, Contextomy.

There's a lot of reasonable arguments to unpack here.

But no, it's not that Louis XIV didn't have an iPhone, it's that the vast middle class in developed countries has central heating and access to penicillin and don't die from giving birth as much.

Also, America's poor are definitely worse off than medieval kings. They don't have access to those basic things that keep most modern people wealthier than medieval kings, like food, shelter and health care.

Some of the older (pre-medieval) king's ruins in Denmark are (by our standards) small stone houses with a moat, and what makes them remarkable is that they're made of stone, and the moat is rather big, so it keeps people out. Like metal doors in apartment buildings, sort of. (Correction for the historians: The oldest king's ruins are of course just holes in the ground where wooden beams used to stand.)

s/America's poor/Europe's lower middle class/ and you're there.

Comment · 2 days ago
API vs. Subscriptions

I don’t know if there’s any openly available statistics on how API costs divide between Claude Code, Claude SDK, raw API, and via OpenRouter.

Comment · 2 days ago
I think it comes from early exposure to phones and tablets and getting used to it. My 2 year old tried to swipe on my computer screen.

And I agree, watching kids swipe feels, to me, like passive consumer induced computer illiteracy.

As long as you can’t fundamentally reprogram the device with your input method, you are at the mercy of other people. (And yeah, sometimes a keyboard is not enough, either.)

Comment · 7 days ago
How did you train your style guide, though?

I have a somewhat expansive style guide, and it still reeks of Claude.

My cleanup is much closer to 40%, which still makes it worth the effort, but sometimes when speed matters, I'll apologize for the slop.

Comment · 7 days ago
What do you mean by your custom models? Do you mean custom prompting?
Comment · 14 days ago
AI won't replace old tech that works, is the point.

Paper is one such.

I'm less sure keyboards will stay to the same degree. My thinking was always the bottleneck while programming, so even though I can talk faster than I type, I couldn't solve problems faster than I type. But I can now.

So I'm opting for speech-to-text when the office space allows it, and looking into steno (stenography) keyboards, or perhaps building a steno overlay on my custom split keyboard to go from 80-100WPM to 200+WPM.

Comment · 16 days ago
> I would simply lie about whether or not a treatment plan was put into place.

Prompt engineering!

Sadly, you learn that honesty is not the best choice always. And an honest answer is best given without too many priors.

Comment · 16 days ago
The general "don't wait" line through much of this advice is recognisable as a trait I apply at work when I want to make sure things get done. "Fail fast, discover unknowns early," etc.

I can't imagine how important it is to practice this when you deal with a terminal illness that grows over time. And how easy it might be to forget this, because you're exhausted.

Comment · 18 days ago
Ferrocene
Comment · 20 days ago
Nix.

I know, I know: It's complicated. But have you heard of AI agents?

But I just onboarded 4 interns on a project where all they had to do was

  1. Install the Nix package manager
  2. Install direnv, enter the project repo, and `direnv allow`
  3. Toolchain, git hooks, MCP servers, in-repo issue tracker, everything is available
Our project manager requested information that was available in the issue tracker. I told her, she could get all her answers by asking our agent, and it'd automatically reference the issue tracker. I figured I'd just need to show her how to install the Nix package manager. But no, she already had it because another project by another team depended on it.

Putting wrong information is README is so outdated when you have programmatic setup of your entire toolchain.

Comment · 25 days ago
Why, you are right on all of these. I used Rust a lot before AI, and I use it a lot after. But I recognise the shortcoming of long compilation: it doesn't just shorten how many times I can have feedback in one day, it is also difficult to fit compilation into constrained environments. Like when an ultra secure Kubernetes cluster doesn't let me compile source code anywhere near it, and I have to compile inside of it; my colleagues insistence on using Go here because "Rust is difficult" (it surely is 100% longer to type when prompting an LLM) really has the main benefit that this code compiles fast and easily within the cluster.

So picking languages for their compilation and especially runtime properties is key.

What I've learned, though, is that languages with reckless error handling produce more errors at runtime. My Rust programs just don't crash because I don't need it to be explicit about reaching a "total" approach.

If you're in a C# environment, I see a case for F#. And if you want fast but more solid than Python, why not Mojo? Although who reads code.

This article convinces me. But I suspect like my lack of domain knowledge of Lisp makes me spend time learning the runtime: how and when can I switch to JIT, what's the async story, how does the harness become part of the Lisp program, etc.

Comment · 1 month ago
I anticipate the day where saying you did a web search is looked weirdly upon.

You did... what? You mean you asked AI?

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton