Leer de defaults: waarom portabiliteit belangrijker is dan customization

Zo werken veel van ons in 2026: een dotfiles repo met jaren aan commits, een vim config die dertig plugins binnentrekt, een tmux prefix omgezet naar iets dat lekkerder voelt, een shell prompt waar een weekend in is gaan zitten. De setup is van jou, tot aan de laatste keybinding. Op je eigen laptop ben je snel. Spiergeheugen doet het werk en je denkt nauwelijks nog na over de tools zelf. Dat is de droom die we onszelf verkopen, en meestal klopt hij prima.

Ik leefde jaren in die setup. Ik was er trots op. Tot ik op een avond naar een productieserver SSH’de om iets te debuggen, en compleet nutteloos was.

Geen custom mappings. Geen plugins. Geen aliassen. Gewoon vanilla vim met de standaard keybindings die ik door jaren van overschrijven stilletjes vergeten was. Ik zat te struikelen over basis navigatie, voelde me een beginner, terwijl een echt probleem op me wachtte. De tools waar ik zo lang aan had zitten poetsen stonden op een machine drie honderd kilometer verderop, en ze konden me niet helpen.

Die avond kwam ik erachter dat ik voor het verkeerde had geoptimaliseerd.

Wat portabiliteit je echt oplevert

Stel je de andere versie van jezelf voor. Zelfde skills, zelfde brein, maar je leerde vim zoals hij standaard komt voordat je ooit een plugin aanraakte. Je SSH’t naar diezelfde server, opent hetzelfde bestand, en niks voelt vreemd. De keybindings zijn degene die je al kent, want het zijn degene die er vanaf het begin waren.

Die persoon kan achter elke machine met vim gaan zitten en aan de slag. De laptop van een collega tijdens een pairing sessie. Een afgesloten device van een klant. Een minimale Docker container. Een verse VM die nu gedebugd moet worden. De tooling hoeft niet mee, want de vaardigheid zit in z’n handen, niet in een repo die hij eerst moet clonen.

Dit is het idee van portabiliteit boven personalisatie toegepast op je eigen workflow. Je infrastructuur bezitten betekent dat je hem overal kunt bedienen, niet dat je hulpeloos bent zodra je je zorgvuldig gebouwde nest verlaat. Een vaardigheid die alleen op één machine werkt is een dependency, en dependency op systemen die je niet kunt reproduceren is een stille kwetsbaarheid.

De customization valkuil

Het is makkelijk om in het customization konijnenhol te vallen. Je leest over iemands geweldige vim config op Reddit. Je vindt een dotfiles repo met 3000 sterren op GitHub. Je denkt: als ik deze ene plugin toevoeg, word ik zoveel productiever. En dat word je ook. Op jouw machine. Met jouw config.

De kosten zijn verborgen, en dat maakt ze gevaarlijk. Elke default die je remapt zonder hem eerst te leren is een stuk portable kennis dat je inruilt voor een lokaal gemak. Je voelt het verlies niet op je eigen laptop. Je voelt het die ene keer dat het ertoe doet, op het slechtst denkbare moment, met een deadline in je nek.

Er zit een echt verschil tussen twee soorten mensen. De een kent de defaults en kiest ervoor om ze te overschrijven. De ander leerde de defaults nooit en kent alleen z’n custom setup. Ze zien er identiek uit zolang alles werkt. Ze lijken in niks op elkaar zodra je ze op een vanilla systeem dropt.

De defaults zijn beter dan je je herinnert

Stel je nu voor dat je op de machine van een onbekende werkt en je er prima bij voelt. Niet trager, niet rondtastend, gewoon aan het werk. Dat is wat de defaults je geven zodra je ze echt leert, en ze hebben een eigenschap die geen enkele plugin kan evenaren: ze zijn overal, en dat zijn ze al decennia.

Vim: leer voordat je remapt

Vim’s standaard keybindings zijn raar. Daar valt niet over te discussiëren. Ze zijn ook goed doordacht en consistent op elke vim installatie op elk Unix systeem sinds de jaren ‘70. Die consistentie is het hele punt.

Voordat je jk naar escape remapt, leer Ctrl+[. Het werkt in vim, in bash, in elke readline-gebaseerde tool. Voordat je een fuzzy finder installeert, leer :find en :edit **/*. Voordat je custom text objects toevoegt, beheers de ingebouwde. Al dat remappen kun je later nog doen. Doe het wetend wat je opgeeft.

Ik draai nog steeds plugins. Ik heb nog steeds een paar custom mappings. Maar ik kan achter elke machine met vim gaan zitten en direct productief zijn, omdat ik weet wat vim me gratis geeft.

Tmux: de prefix maakt minder uit dan je denkt

Ieders eerste tmux aanpassing is de prefix remappen van Ctrl+b naar Ctrl+a. Ik deed het ook. Ctrl+b is onhandig, zeggen we. Screen gebruikte Ctrl+a, vertellen we onszelf.

Kijk eens naar wat de prefix eigenlijk is. Je drukt hem één keer, dan tik je een andere toets. De onhandigheid van Ctrl+b is één toetsaanslag die je duizenden keren doet tot je vingers het niet meer merken. Ondertussen botst Ctrl+a met “ga naar begin van regel” in bash, een binding waar ik constant naar grijp. En elke server met tmux geïnstalleerd gebruikt Ctrl+b. Train jezelf op Ctrl+a en je vecht tegen de verkeerde prefix elke keer dat je van huis bent.

Die laatste, Ctrl+b ?, is je reddingslijn op elke tmux installatie. Je hoeft niet elke binding te onthouden als je de hele lijst in één toetsaanslag kunt oproepen.

Shell tools: kennis die meereist

Dezelfde logica geldt voor grep, awk, sed, find, en de rest van de Unix toolkit. Ik zie mensen ripgrep installeren en vergeten dat grep bestaat. Ze grijpen naar fd en kunnen zich de find syntax niet meer herinneren. Ze aliassen alles naar de moderne vervanger tot het origineel een vreemde is.

De moderne tools zijn echt goed en ik gebruik ze elke dag. Maar grep staat op elk Unix systeem. Find is overal. Awk en sed zijn voorgeïnstalleerd op elke server die je ooit aanraakt. Om 3 uur ’s nachts, midden in een incident, heb je geen tijd om ripgrep te installeren. Je werkt met wat er is of je werkt niet.

# grep basics die overal werken
grep -r "pattern" .           # recursief zoeken
grep -l "pattern" *.log       # bestanden met pattern
grep -v "exclude"             # inverse match
grep -E "regex|pattern"       # extended regex

# find basics
find . -name "*.py"           # vind op naam
find . -mtime -1              # gewijzigd in laatste dag
find . -type f -exec cmd {} \; # voer uit op resultaten

# awk one-liners
awk '{print $2}' file         # print tweede kolom
awk -F: '{print $1}' /etc/passwd  # custom delimiter
awk 'NR==5' file              # print regel 5

Ripgrep is sneller. Fd heeft mooiere syntax. Grep en find zijn er altijd. Op een server die je niet beheert wint altijd er.

De drempel: defaults voelen als een stap terug

Waarom doet bijna niemand dit dan? Omdat de defaults leren voelt alsof je expres trager gaat. Je hebt al een config die werkt. Gaan zitten om vim op de saaie manier opnieuw te leren, op je eigen machine, voor een opbrengst die alleen op die van iemand anders opduikt, is een lastige verkoop aan een brein dat nu resultaat wil.

Er zit ook een sunk-cost trekkracht in. Je stak echte uren in die dotfiles. Toegeven dat een deel van die uren je een fragiel lokaal optimum opleverde, doet een beetje pijn. Ik snap het. Mijn dotfiles repo heeft commits die jaren teruggaan en ik ben gesteld op elke commit.

En eerlijk, de meeste dagen zit je op je eigen machine. Het hele punt van een comfortabele setup bouwen is dat je erin woont. De portabiliteitsbelasting valt maar af en toe, en dat maakt het makkelijk om hem te blijven negeren.

De kloof dichten

Je hoeft je setup niet af te breken om dit op te lossen. De brug is smaller dan hij lijkt.

Begin met toevoegingen te scheiden van vervangingen. Mijn customizations zitten bovenop de defaults in plaats van ze te wissen. Ik remap Ctrl+b niet. Ik voeg misschien bindings toe, maar de originelen werken nog. Kleurenschema’s, een nette prompt, een paar mappings die met niks ingebouwds botsen: hou het allemaal. De lijn die je trekt is dat niks wat je toevoegt je hulpeloos mag maken op een vanilla bak. Telkens als je een default wilt overschrijven, stel eerst één vraag: laat dit me stranden op een vers systeem? Zo ja, denk twee keer na.

Test daarna jezelf, want de gaten verstoppen zich tot je ze gaat zoeken:

1. SSH naar een server en edit een config bestand in vim. Geen plugins, geen vimrc. Kun je navigeren, zoeken, vervangen en opslaan?
2. Start een vanilla tmux sessie. Maak splits, beweeg ertussen, open nieuwe windows, allemaal met standaard bindings.
3. Debug iets met alleen grep en find. Geen ripgrep, geen fd, geen aliassen. Kun je vinden wat je nodig hebt?
4. Schrijf een snelle awk one-liner die een kolom uit een logbestand trekt, zonder te googlen.

Worstel je met een van deze, dan heb je net de defaults gevonden die het waard zijn om te leren. Die worsteling is het signaal, en het is goedkoop om er nu iets mee te doen vergeleken met het live ontdekken tijdens een incident.

Een paar uitzonderingen verdienen het om eerlijk benoemd te worden. Heb je RSI of een andere fysieke beperking, remap dan wat je nodig hebt; je gezondheid gaat elke keer boven portabiliteit. Standaardiseert je hele team op één config, dan wordt die config praktisch gezien je default. En als je echt nooit je eigen machine verlaat, nooit pair programmed, nergens naartoe SSH’t, customize dan naar hartenlust. De meesten van ons hebben die luxe niet.

Je dotfiles zijn een persoonlijke expressie van hoe je graag werkt, en daar is niks mis mee. Eronder wil je echter een fundament van default kennis dat met je meereist. Want op een nacht zit je ge-SSH’d in een minimale container met niks dan vanilla vim en een deadline, en de versie van jou die de defaults eerst leerde is degene die die nacht prima uit komt. Leer de defaults, customize daar bovenop. Het andersom doen laat je je eigen vaardigheid huren van een repo die je misschien niet kunt bereiken.

Gerelateerd: Ik schreef over mijn dotfile management setup met chezmoi en mise. Merk op dat zelfs daar mijn customizations minimaal zijn en het standaard gedrag niet kapot maken.