Po co właściwie robimy sobie pod górkę?
Często wybieramy trudniejsze rozwiązania nie dlatego, że są lepsze, tylko dlatego, że wydają się bardziej wartościowe, dają poczucie kontroli albo są wytwarzane przez społeczność, z którą się identyfikujemy.
Łatwiejsze nie znaczy gorsze
Nie znaczy gorsze, a nawet często jest lepsze.
Prostsze rozwiązania są szerzej znane, łatwiejsze do zrozumienia i szybsze do wdrożenia. Złożone rozwiązania mogą być imponujące, ale często są trudniejsze do utrzymania i bardziej podatne na błędy.
Na przykład Next.js do dashboardu to overkill, wystarczy prosty serwer Express i frontend React. Nie potrzebujesz Nexta, jeśli nie potrzebujesz SEO, BFF, SSR.
Iluzja kontroli i strach przed uproszczeniem
Ręczne robienie wszystkiego daje poczucie kontroli, ale często jest to iluzoryczne. Automatyzacja i uproszczenie tworzą przewidywalne, powtarzalne procesy, które są bardziej niezawodne i mniej podatne na błędy.
Przykład z życia: skrypty środowiskowe, które automatyzują konfigurację, są często postrzegane jako “magia”, ale w rzeczywistości są po prostu narzędziami, które oszczędzają czas i redukują błędy.
Bare minimum zależy od bańki
To, co jest standardem w jednej grupie, w innej może być armatą na muchy. Problem zaczyna się, gdy traktujesz normy środowiska jako obiektywną prawdę.
Przykładowo, środowisko redditowych Linuxiarzy: Bardzo zmodyfikowany system, mnóstwo narzędzi, Arch, tmux, nvim, i3, custom prompt. Dla nich to minimum, ale dla większości ludzi to już przesada.
Zastanów się, czy wybierasz narzędzia dla efektu, czy dla efektywności. Używasz nvim + tmux, bo w poprzedniej firmie usłyszałeś, że tak robią “prawdziwi devowie”, mimo że szybciej pracowałbyś w VS Code. Wybór nie wynika z efektywności, tylko z tego, jak chcesz być postrzegany.
Te narzędzia nie są złe same w sobie, ale złe jest bezkrytyczne kopiowanie rozwiązań, które są skomplikowane i niepotrzebne dla Twojego przypadku.
Pułapka czasu i bezpieczeństwa
Upraszczanie to nie tylko kwestia wygody, ale też oszczędności czasu i redukcji ryzyka. Im bardziej skomplikowane rozwiązanie, tym więcej czasu spędzasz na jego konfiguracji, utrzymaniu i rozwiązywaniu problemów. To czas, który mógłbyś poświęcić na rozwijanie umiejętności, budowanie projektów czy odpoczynek.
1. Prawo Parkinsona
„Praca rozszerza się tak, aby wypełnić czas dostępny na jej wykonanie.”
Im więcej czasu poświęcasz na skomplikowane rozwiązania, tym więcej czasu one zajmują, nawet jeśli nie są bardziej efektywne.
Przykład: Zamiast postawić prosty backend w Expressie w jeden dzień, rozbijasz projekt na mikroserwisy, konfigurujesz Docker, CI/CD i monitoring, mimo że projekt tego nie wymaga.
2. Prawo Murphy’ego
„Jeśli coś może pójść źle, pójdzie źle.”
Im bardziej skomplikowane rozwiązanie, tym większe ryzyko, że coś pójdzie nie tak. Prostsze rozwiązania są mniej podatne na błędy i łatwiejsze do naprawienia.
Przykład: Projekt oparty o mało popularne narzędzia bez dokumentacji. Kiedy coś przestaje działać, spędzasz godziny na debugowaniu, bo nikt wcześniej nie miał tego problemu.
3. Bus Factor
Bus Factor to wskaźnik, który mierzy, ile osób musi “odejść”, aby projekt przestał być funkcjonalny. Im bardziej skomplikowane rozwiązanie, tym większy bus factor, ponieważ mniej osób będzie w stanie je zrozumieć i utrzymać.
Przykład: Jeden developer stworzył customowy system builda i deploya. Działa świetnie, dopóki ta osoba jest w projekcie. Kiedy znika, nikt nie wie, jak to utrzymać.
Uniwersalna prostota
Jeśli konfiguracja prostego projektu zajmuje nowej osobie 4 godziny, to nie jest to proste rozwiązanie. Prostota powinna być obiektywna. Jeśli Twój proces jest skomplikowany, uprość go dla innych poprzez:
- Jasną dokumentację,
- Skrypty
one-click, - Gotowe obrazy Dockerowe (tam, gdzie to ma sens).
Wybieram to, co działa
Kiedyś myślałem, że muszę używać „edgy” narzędzi, by być traktowanym poważnie. Dziś stawiam na standardy:
- Przeglądarka: Zamiast niszowych forków Firefoxa - Chrome. Popularność to nie wada; to ekosystem i wsparcie.
- System: Zamiast dual-boota z Linuxem - Windows + WSL2. Mniej „cool”, ale o 100% mniej problemów z konfiguracją sprzętu. Używam Linuksa do serwerów, ale nie potrzebuję go na desktopie.
- Zasada YAGNI (You Aren’t Gonna Need It): Nie dodawaj funkcji, dopóki nie są niezbędne.
Zastosowałem kiedyś Dockera do developmentu prostej apki w Node.js tylko dlatego, że wydawało się to „profesjonalne”. Efekt? Wolniejsze przeładowywanie kodu i problemy z uprawnieniami. Wystarczył Docker na produkcji, a lokalnie - zwykły npm run dev.
Morał: Wybieraj nudne, ale sprawdzone rozwiązania. To one działają, mają dokumentację i tysiące ludzi, którzy już rozwiązali Twoje problemy. “Ciekawe” rozwiązania często oznaczają, że będziesz rozwiązywał je sam.
Czy łatwiejsze rozwiązanie nie zemści się później?
Warto zastanowić się, czy łatwiejsze rozwiązanie nie będzie miało negatywnych konsekwencji w przyszłości. Czasami proste rozwiązania mogą być mniej skalowalne, mniej elastyczne lub mniej bezpieczne. Jednak często te obawy są przesadzone i wynikają z lęku przed zmianą lub z przywiązania do skomplikowanych rozwiązań.
Gdzie warto iść pod górkę
Są sytuacje, w których warto iść pod górkę, np. gdy uczysz się nowej technologii, gdy chcesz zrozumieć, jak coś działa od podstaw, lub gdy chcesz mieć pełną kontrolę nad swoim środowiskiem. Nawet w tych sytuacjach warto zachować zdrowy rozsądek i nie przesadzać z komplikowaniem rzeczy.
Podsumowanie
Na końcu dnia nie chodzi o to, żeby robić rzeczy najprościej.
Chodzi o to, żeby nie robić ich trudniej, niż to konieczne.
To właśnie jest sztuka upraszczania sobie życia.
Łatwiejsze życie = więcej czasu na to, co naprawdę ważne.