Mniej znaczy więcej

Najtrudniejsze w tworzeniu oprogramowania jest wiedza o tym, co pominąć.

Każdy system zaczyna się prosto. Potem przychodzą wymagania, pojawiają się edge case’y, interesariusze proszą o funkcje i zanim się obejrzysz, masz coś, co technicznie działa, ale czego nikt do końca nie rozumie - włącznie z ludźmi, którzy to zbudowali.

Złożoność narasta po cichu

Podstępność złożoności polega na tym, że rzadko pojawia się nagle. Kumuluje się w małych decyzjach: dodatkowy parametr tu, warunek tam, flaga konfiguracyjna, która “może kiedyś się przyda”. Każdy dodatek z osobna wydaje się niegroźny. Problem stanowi ich suma.

W erze generatywnego AI to jeszcze bardziej niebezpieczne. Vibe-coding - pozwalanie LLM-owi generować kod, podczas gdy ty sterujesz z fotela pasażera - jest kuszący. Działasz szybko. Funkcje pojawiają się same. Ale jeśli nie rozumiesz, co jest pod spodem, to nie budujesz. Akumulujesz. A w momencie, gdy coś się popsuje, jesteś zagubiony w kodzie, którego tak naprawdę nigdy nie napisałeś.

Szybkość bez zrozumienia to tylko dług z odroczonym terminem płatności.

Zasada, której się trzymam

Zanim cokolwiek dodam - funkcję, opcję konfiguracji, element UI - pytam: co się zepsuje, jeśli tego nie będzie? Jeśli odpowiedź brzmi “na razie nic”, nie dodaję.

Brzmi banalnie. Zaskakująco trudno to stosować, kiedy jesteś w środku budowania czegoś i twój mózg generuje pomysły szybciej niż ręce nadążają pisać. Jeszcze trudniej, kiedy to AI generuje te pomysły za ciebie.

Zasada minimalizmu

Tę samą zasadę widzę u autorów narzędzi, które podziwiam. Te, które przetrwają, to te, które mają odwagę być niekompletne - wolą robić jedną rzecz dobrze niż pięć rzeczy jako tako.

To właśnie próbuję budować. Kawałek po kawałku.

— Adrian