the computer i learned on, and why it still explains how i think about tools

tech · 2025-12-18 · 6 min

the commodore 64 my parents bought in 1985 is still the computer i think about when i evaluate new tools. not because it was good — it was slow, loud, and had 64 kilobytes of memory — but because its limitations taught me things no modern interface ever could.

what the c64 taught me

the c64 booted to a blinking cursor and a prompt. there was no start menu, no tutorial, no onboarding. if you wanted to do anything, you typed a command and found out whether it worked. that single fact shaped everything: i learned early that software is something you talk to, not something that talks at you.

budget was a daily constraint. the c64 had 64 kilobytes of ram. every program i wrote had to fit in it. every sprite, every sound, every line of text cost something. i learned to build small before i learned to build big, and small building is the skill that survives every technology shift.

there was no internet to copy from. if i wanted a program to do something, i had to figure it out or leave it undone. the gap between what i wanted and what i could make was the whole education.

why that still matters at 35

every new tool i evaluate gets the same questions, inherited from a machine that could not have answered them: does it let me talk to it directly, or does it mediate everything through menus and wizards. does it stay small when i need small, or does it balloon to justify its own existence. does it respect the time i give it, or does it demand i learn a system around it.

the answers are why i still reach for text editors over visual builders for real work, why i prefer tools that expose their internals over tools that hide them, and why i get suspicious of software that needs a fifteen-minute onboarding video before i can do the thing i opened it to do.

the c64 is not a superior machine to anything i use now. it is a better teacher. it taught me that constraints are not the enemy of good work — they are the only thing that makes good work possible.

the habit that survived every platform

before i add a tool, a framework, a library, a platform, i ask what it removes. every tool adds something. the good ones also remove something — friction, repetition, the need to think about something that should be automatic. the bad ones add a layer and call it a feature.

i check that before i check features. it is the same question i asked at twelve, facing a blinking cursor and 64 kilobytes: what does this let me stop doing. everything else is marketing.

for tools that respect that principle on the web side: quanto costa un sito web. for the difference between building a product and building something someone wants: my first real product.