Marc Palau

Algunes coses simplement necessiten temps

Traducció de l’article https://lucumr.pocoo.org/2026/3/20/some-things-just-take-time/ de Armin Ronacher’s Thoughts and Writings

TL;DR

L’article defensa que hi ha coses que només es poden aconseguir amb anys de constància i no amb velocitat ni eines d’IA. Critica l’obsessió actual per eliminar friccions i “anar ràpid”, especialment en start‑ups, compliment normatiu i projectes open source que neixen i moren en setmanes, perquè això erosiona la confiança i la responsabilitat amb usuaris i clients. També qüestiona la promesa d’estalviar temps amb tecnologia, ja que el temps alliberat s’omple immediatament amb més feina i competència, i no es converteix en descans ni en profunditat. L’autor reivindica la tenacitat i el fet de “seguir-hi sent” durant anys com a condició per crear qualitat, comunitat i confiança, igual que passa amb un roure que triga dècades a créixer.

Algunes coses simplement necessiten temps

escrit el 20 de març de 2026

Els arbres triguen força temps a créixer. Si algú fa 50 anys va plantar una filera de roures o un castanyer al teu terreny, tens alguna cosa que cap quantitat de diners o esforç pot replicar. L’única manera és esperar. Camins arbrats, jardins antics, cases protegides per dècades de capçades: si vols començar de zero en un terreny buit, això no ho podràs aconseguir.

Perquè hi ha coses que simplement necessiten temps.

Això ho sabem de manera intuïtiva. Paguem primes per rellotges suïssos, bosses Hermès i propietats antigues precisament pel temps que hi ha incrustat. O bé pel temps que ha calgut per construir-les o bé per la seva edat. Exigim edats mínimes per conduir, votar i beure perquè creiem que la maduresa només arriba a través de l’experiència viscuda.

Tanmateix, ara també vivim en una època de gratificació instantània, i això entra en la manera com fem programari i empreses. Per molt que puguem accelerar la generació de codi, l’element realment definitori d’una empresa exitosa o d’un projecte de codi obert continuarà sent la tenacitat. La capacitat de la direcció o de les persones mantenidores de mantenir-se amb un problema durant anys, de construir relacions, de treballar a través de reptes fonamentalment definits per escales de temps humanes.

La fricció és bona

La generació actual de fundadors de startups i programadors està obsessionada amb la velocitat. Iteració ràpida, desplegament ràpid, fer-ho tot tan de pressa com sigui possible. Per moltes coses, això està bé. Pots anar ràpid, deixar una mica de qualitat pel camí i aprendre alguna cosa pel trajecte.

Però hi ha coses on la velocitat és activament perjudicial, on la fricció existeix per algun motiu. El compliment normatiu n’és un d’aquests casos. Hi ha un desig molt fort d’eliminar tot allò que processen com SOC2 requereixen, i ha sorgit tota una indústria de solucions “claus en mà” per ajudar-hi — Delve n’és només un exemple, n’hi ha més.

Hi ha la sensació que totes les coses que creen fricció a la teva vida s’haurien d’automatitzar. Que la intervenció humana hauria de ser substituïda per presa de decisions basada en IA. Perquè el problema és la fricció del procés. Quan, de fet, moltes vegades la fricció, o el fet que les coses simplement necessitin temps, és precisament el quid de la qüestió.

Hi ha una raó per la qual tenim períodes de reflexió obligatòria per a algunes decisions importants en la vida. Reconeixem que la gent necessita temps per pensar sobre què està fent, i que fer alguna cosa bé un cop no vol dir gaire perquè has de ser capaç de fer-la bé durant un període de temps més llarg.

Vibe slop a velocitat d’inferència

La IA escriu codi ràpid, cosa que ja no és cap notícia. El que és interessant és que estem empenyent aquesta força aigües avall: aparentment tenim aquest desig d’entregar més ràpid que mai, de fer més experiments, i això crea un nou desig, el d’eliminar tota la fricció que queda en les revisions, el disseny i la configuració d’infraestructura, qualsevol cosa que alentisca el pipeline. Si les màquines són tan fantàstiques, per què necessitem llistes de comprovació o sistemes de permisos? Expressa el desig, gaudeix del resultat.

Perquè ara creiem que és important simplement fer-ho tot més ràpid. Però, cada cop més, també tinc la sensació que això significa que la vida útil de bona part del programari que es crea avui —programari del qual persones i negocis s’haurien de poder fiar— es pot mesurar només en mesos en lloc de dècades, i igualment les relacions que l’envolten.

En una de les tandes primerenques de YC de l’any passat ja hi havia uns quants projectes que senzillament van desaparèixer sense ni tan sols dir què havien après o acomiadar-se dels seus clients. Simplement van tancar la seva presència pública i van passar a altres coses. I per a mi això no és un senyal d’una iteració saludable. És un senyal que es trenca la confiança bàsica que necessites per construir una relació amb els clients. Tancar bé una empresa requereix temps i esforç, i el nostre entorn actual tracta aquest temps com a mal invertit. Millor simplement passar a la següent cosa.

Això s’estén també als projectes de codi obert. De sobte, tot és un projecte de codi obert, però molts només tenen commits durant una setmana o així, i després desapareixen perquè la motivació del creador ja s’ha extingit. I en nom de l’experimentació, tot això està bé, però el que fa que un projecte de codi obert sigui bo és que pensis i creguis de debò que la persona que l’ha creat o bé s’hi quedarà durant un període de temps molt llarg, o bé serà capaç d’establir una estratègia de successió, o bé haurà creat prou comunitat perquè aquests projectes superin la prova del temps d’una manera o una altra.

El meu temps

Relacionat amb això, també cada cop soc més escèptic de qualsevol que em vengui alguna cosa que se suposa que m’ha d’estalviar temps. Quan tot el que veig és que tothom que és com jo, totalment incorporat a eines d’IA i agents, aparentment té cada cop menys temps disponible perquè caiem en la trampa d’omplir immediatament aquest temps amb més coses.

Tots ens venem els uns als altres la idea que estalviarem temps, però això no és el que passa. Qualsevol temps estalviat és capturat immediatament per la competència. Algú que realment fa una pausa és superat per algú que omple cada hora alliberada amb nova producció. No hi ha una manera fàcil de “guardar” aquest temps i senzillament desapareix.

Jo ho noto de manera molt aguda. Estic molt a prop del centre roent on té lloc l’activitat econòmica al voltant de la IA, i més que res, tinc cada cop menys temps, fins i tot quan intento reduir a propòsit i crear espai. Per a mi això és un problema. És un problema perquè, fins i tot amb les millors intencions, em costa molt crear qualitat quan estem convertint ràpidament el programari en una commodity, i les màquines ho fan tan temptador.

No puc deixar de tornar als arbres. Fa gairebé dues dècades que mantinc projectes de codi obert. A l’última startup on vaig treballar, hi vaig passar 10 anys. Això no és perquè sigui particularment disciplinat o virtuós. És perquè jo, o algú altre, va plantar alguna cosa, i després vaig continuar presentant-m’hi, i eventualment aquella cosa va arrelar més profundament que el meu entusiasme en qualsevol dia concret. Això és el que fa el temps! Converteix una idea o un pla en un compromís, i un compromís en una cosa que pot aixoplugar i fer créixer altres persones.

Ningú no fabricarà en massa un roure de 50 anys. I ningú no conjurarà confiança, o qualitat, o comunitat a partir d’un sprint de cap de setmana. Les coses que més valoro —els projectes, les relacions, les comunitats— són totes coses que van trigar anys a ser el que són. Cap eina, per ràpida que sigui, no les hi hauria pogut portar abans.

Recentment hem plantat un arbre nou amb en Colin. Vull que creixi i es converteixi en un arbre gran. Sé que això portarà temps, i no tinc cap pressa.

Marc Palau

WolfStack

WolfStack és un tauler únic per gestionar tota la teva infraestructura. contenidors Docker i LXC, VMs, xarxa, discs, còpies de seguretat i monitoratge en temps real, tot des d’una sola interfície. Està fet en Rust, és open source i apunta fort a homelabs, clusters i entorns multi-servidor.

https://wolfstack.org

Marc Palau

Control d’errors en comandes d’una sola línia

in bash/shell when you have a command that had failed you can know it:

A Bash/Shell, quan tens una comanda que ha fallat, pots controlar el que passa a continuació mitjançant els operadors logics || o &&.

Executa en un terminal les següents comandes:

true && echo "TRUE" || echo "FALSE"
#or
false && echo "TRUE" || echo "FALSE"

O mitjançant una comanda mes explicita:

false || false || false || echo "tot l'anterior ha fallat"
Marc Palau

El principi de conservació de la complexitat

Aquest principi va ser popularitzat per Larry Tesler, un informàtic que va treballar en la interfície d’usuari i la usabilitat.

La llei estableix que, en qualsevol sistema, hi ha una quantitat inherent de complexitat que no pot ser eliminada, només redistribuïda. Això significa que quan simplifiques una part del sistema per als usuaris o desenvolupadors, la complexitat es trasllada a una altra part del sistema.

Per exemple:

  • Si fas una interfície d’usuari més senzilla, la complexitat pot traslladar-se al codi subjacent.
  • Si utilitzes eines d’alt nivell (com frameworks o llibreries), la complexitat es trasllada a l’aprenentatge i manteniment d’aquestes eines.

La Llei de Tesler diu que “una complexitat inherent en un sistema no es pot eliminar, només es pot redistribuir“, té una clara analogia amb la primera llei de la termodinàmica, que estableix que “l’energia no es crea ni es destrueix, només es transforma“.

En ambdós casos, hi ha una quantitat conservada: la complexitat en el disseny de sistemes digitals i l’energia en els processos físics. Si en un sistema tecnològic intentem simplificar la interfície d’usuari, la complexitat no desapareix sinó que es trasllada al backend o a l’equip de desenvolupament, de la mateixa manera que l’energia es converteix en diferents formes però mai es perd.