Nie myl mapy z terenem
Nie myl mapy z terenem
Ostatnio połączyły mi się w głowie dwa pozornie niezwiązane tematy: sposób, w jaki ludzie postrzegają świat, oraz to, czym naprawdę zajmuje się programista.
Życie codzienne i subiektywna percepcja
Zacznijmy od ludzi. Często słyszę różne opinie wypowiadane z ogromną pewnością siebie. Szczególnie wśród starszych osób, choć oczywiście nie jest to reguła związana z wiekiem. Wiele osób mówi o świecie tak, jakby przedstawiało fakty, podczas gdy w rzeczywistości opisuje własne doświadczenia, przekonania i interpretacje. To, co dla jednej osoby jest oczywiste, dla innej może wyglądać zupełnie inaczej.
Nie wynika to ze złej woli. Każdy z nas buduje swój obraz rzeczywistości na podstawie tego, co przeżył, czego się nauczył i z jakimi ludźmi miał kontakt. Problem pojawia się wtedy, gdy zaczynamy traktować własny punkt widzenia jako jedyną prawdę i przestajemy dopuszczać możliwość, że świat może być bardziej skomplikowany, niż nam się wydaje.
Klasyczny przykład z rodzinnych spotkań: „Idź do wojska, bo tam szukają informatyków, nauczą cię dyscypliny i odpowiedzialności, dużo płacą i zatrudniają wszystkich, tylko wyślij CV, tak słyszałem”.
A potem przychodzi zderzenie z terenem: 6000 brutto na start, zero realnego rozwoju, betonowa hierarchia i frustracja, bo rzeczywistość nijak ma się do opowieści wujka z lat 90. Podobnie jest w internetowych dyskusjach, gdzie argument „ja tak miałem, więc świat tak działa” jest koronnym dowodem w sprawie. Po drugie, kto to jest informatyk? W pracy w służbie publicznej, informatyk to prawdopodobnie osoba od wszystkiego, od drukarek przez excela po serwery.
Podobnie jest w programowaniu
Przez długi czas myślałem, że programista istnieje po to, aby pisać kod. W końcu właśnie tego się uczymy. Poznajemy języki programowania, frameworki, wzorce projektowe i coraz bardziej zaawansowane rozwiązania techniczne. Łatwo dojść do wniosku, że im więcej kodu potrafimy napisać i im bardziej jest on dopracowany, tym lepiej wykonujemy swoją pracę.
Dopiero później zrozumiałem, że z perspektywy klienta kod często nie ma większego znaczenia. Klient nie kupuje Reacta, Javy, Pythona czy najnowszej architektury systemu. Kupuje rozwiązanie problemu. Chce zwiększyć sprzedaż, zaoszczędzić czas, ograniczyć liczbę błędów albo zautomatyzować procesy. Jeśli jego problem zostanie rozwiązany, cel został osiągnięty.
W tym sensie kod jest tylko narzędziem. Tak samo jak młotek jest narzędziem dla stolarza. Nikt nie zatrudnia stolarza dlatego, że świetnie trzyma młotek. Zatrudnia go dlatego, że chce mieć gotowy mebel.
Co więcej, każda linijka kodu to tak naprawdę odpowiedzialność i dług technologiczny. Kod trzeba utrzymać, testować i aktualizować, z czasem staje się on obciążeniem, a nie zyskiem. Najlepszy kod to często ten, którego w ogóle nie trzeba było pisać, bo problem dało się rozwiązać prościej.
Im dłużej o tym myślę, tym bardziej widzę podobieństwo między tymi dwoma tematami. Zarówno w życiu, jak i w programowaniu łatwo pomylić środek z celem. Ludzie często przywiązują się do własnych przekonań i zapominają, że są one jedynie interpretacją rzeczywistości. Programiści przywiązują się do technologii i zapominają, że kod jest jedynie sposobem na dostarczenie wartości.
Być może jedną z najważniejszych umiejętności jest zdolność spojrzenia poza własną perspektywę. Zamiast pytać „czy mam rację?”, warto czasem zapytać „czy na pewno widzę cały obraz?”. Zamiast pytać „jakiego frameworka użyć?”, warto najpierw zapytać „jaki problem próbujemy rozwiązać?”.
Wymaga to jednak sporej elastyczności. Dobra mapa jest użyteczna tylko wtedy, gdy na bieżąco ją aktualizujemy. W życiu oznacza to gotowość do zmiany poglądów, kiedy zmieniają się fakty, a w pracy programisty, odwagę do porzucenia ulubionej technologii, jeśli biznes potrzebuje czegoś prostszego.
W obu przypadkach odpowiedź często okazuje się znacznie ciekawsza, niż początkowo zakładaliśmy.