Hacker News new | ask | show | jobs
by Kon5ole 6 days ago
Good writeup, and certainly food for thought.

I wonder if this key point actually holds though:

>The skills to do so, however, are a function of someone who has experienced the friction and challenges over time that culminate in "good taste".

It's certainly sometimes true, but I don't think it's a general rule. Sometimes friction is just friction and sometimes you spend 1000 hours learning something that disappears and becomes obsolete or at least irrelevant to the goal.

Programmers used to need to know the instruction set of the CPU, assembly language and so on. Some still do but for most developers today that's not useful. Everything you know about 6800 assembly will not make your note-taking app any better.

I think we are in a state where AI tools so easily mimic what we used to do by hand that we think the friction is gone, but that's because we haven't raised the bar yet. One day we'll look at the Fable one-shot that's better than anything we ever made by hand ourselves and say "It could be even better".

And then the friction is back, just on a new level.

2 comments

> Everything you know about 6800 assembly will not make your note-taking app any better.

It could. It could make a simple note-taking app not take gigabytes of memory and take visible delay on each click. Most people don't bother of course because simple note-taking app is not worth the effort. It's possible to do better, it's just often not practical.

>It could. It could make a simple note-taking app not take gigabytes of memory and take visible delay on each click.

But the taste that tells you a note taking app should be fast doesn't come from your knowledge of assembly. It comes from using the app.

Being able to have an AI generate 8 variants of an UI and 5 variants of a storage mechanism is more helpful to reach the goal of a good note-taker. Trying out those prototypes and tweaking them to perfection is also friction, only it happens closer to your actual goal than doing quicksort in assembly.

There are of course examples where the friction does help, and where the "aid" of the tool deteriorates useful skills, but I think that will sort itself out over time. Useful skills will remain, useless ones will disappear, as they always have.

Question from the peanut gallery here. Why not just train an LLM to write in Assembly? Or bare metal? Validate by compiling. Or binary, no compilation needed. Can't a frontier LLM find the bugs better than we? As long as the program is built from small, verifiable subunits, the pragmatic problem of creating an efficient program is in every careful planner's reach. Seems the friction is nearly gone. I have no skin in the game here, but this is a developing (no pun intended) expectation for me.
> Everything you know about 6800 assembly will not make your note-taking app any better.

For most apps, it makes sense to profile your app for expected use cases. Put even minimal thought into making the hot codepaths faster by moving unnecessary operations out of it.