Wprowadzenie
Jedną z najciekawszych rzeczy w branży IT jest to, że ten sam problem często można rozwiązać na wiele zupełnie różnych sposobów.
I jeszcze ciekawsze — wiele z tych rozwiązań może faktycznie działać.
Na pierwszy rzut oka może to wydawać się oczywiste.
Ale gdy spojrzymy głębiej, ta obserwacja zmienia sposób, w jaki komunikujemy się, współpracujemy i myślimy o cudzych pomysłach.
Zwłaszcza podczas:
• code review,
• dyskusji architektonicznych,
• planowania produktu,
• albo debat technicznych.
Czasem ludzie nieświadomie zakładają, że istnieje tylko jedno „poprawne” rozwiązanie.
Ale software development rzadko działa jak matematyka.
Bardzo często wybieramy między kompromisami, a nie absolutnymi prawdami.
Idealne rozwiązanie nie istnieje
Myślę, że wielu inżynierów doświadcza tej obserwacji po kilku latach w branży.
Na początku drogi często szukamy:
• najlepszego frameworka,
• najlepszej architektury,
• najlepszej metodologii,
• best practices,
• najlepszych wzorców.
I oczywiście — doświadczenie i standardy są niezwykle cenne.
Ale z czasem zaczynamy zauważać coś fascynującego.
„Najlepsze” rozwiązanie zwykle zależy od kontekstu.
Na przykład:
• startup i enterprise mogą potrzebować innej architektury,
• narzędzie wewnętrzne i publiczna platforma mogą wymagać innych priorytetów,
• doświadczony zespół i juniorowy zespół mogą potrzebować innego poziomu złożoności,
• szybki MVP i długoterminowy produkt mogą wymagać innych kompromisów.
Dlatego dojrzałe myślenie inżynierskie z czasem staje się mniej ideologiczne.
I szczerze — myślę, że to dotyczy też życia poza pracą.
Poprawność techniczna vs praktyczna użyteczność
Kolejna ważna rzecz to zrozumienie różnicy między technicznie idealnym rozwiązaniem a praktycznie użytecznym.
Czasem inżynierowie tworzą niezwykle eleganckie systemy, które:
• są trudne w utrzymaniu,
• nadmiernie komplikują proste problemy,
• spowalniają delivery,
• albo dezorientują mniej doświadczonych członków zespołu.
Tymczasem prostsze rozwiązanie może dać:
• szybszy onboarding,
• łatwiejszą współpracę,
• niższy koszt utrzymania,
• i zdrowszy proces developmentu.
To nie znaczy, że prostota zawsze jest lepsza.
Ale znaczy, że złożoność sama w sobie nie jest automatycznie inteligencją.
Czasem prawdziwa dojrzałość to redukowanie niepotrzebnej złożoności, a nie dodawanie kolejnej.
Emocjonalne przywiązanie do rozwiązań
Myślę, że to jeden z największych ukrytych problemów w dyskusjach technicznych.
Ludzie często stają się emocjonalnie przywiązani do swoich rozwiązań.
Dlaczego?
Bo praca kreatywna i techniczna jest osobista.
Inwestujemy:
• czas,
• uwagę,
• energię,
• tożsamość,
• i emocje w to, co budujemy.
Gdy ktoś krytykuje nasze rozwiązanie, może to nieświadomie czuć się jak krytyka nas samych.
To tworzy defensywną komunikację.
Zamiast:
"„Znajdźmy razem najlepsze rozwiązanie”"
dyskusja powoli staje się:
"„Pozwól, że obronię mój pomysł.”"
I to całkowicie zmienia współpracę.
Perspektywa — znowu
Jedną z najzdrowszych rzeczy, które zespoły mogą zrozumieć, jest to, że różni ludzie optymalizują pod różne rzeczy.
Developer może optymalizować pod:
• skalowalność,
• utrzymywalność,
• jakość kodu.
Business stakeholder pod:
• szybkość delivery,
• budżet,
• timing rynkowy.
Designer pod:
• customer experience,
• użyteczność,
• dostępność.
QA engineer pod:
• stabilność,
• edge case'y,
• przewidywalność.
Żadna z tych perspektyw nie jest automatycznie błędna.
Po prostu obserwują rzeczywistość przez różne priorytety.
A może wiele konfliktów w branży IT naprawdę nie dotyczy samych rozwiązań.
Może chodzi o to, że ludzie nie rozumieją nawzajem swoich priorytetów.
Zawsze są kompromisy
Myślę, że jedną z najważniejszych lekcji w software development jest zrozumienie trade-offów.
Na przykład:
• elastyczność może zwiększać złożoność,
• szybkość może redukować jakość,
• optymalizacja może obniżać czytelność,
• skalowalność może spowalniać delivery,
• abstrakcja może poprawiać reużywalność, ale redukować jasność.
Każde rozwiązanie tworzy konsekwencje.
Dlatego emocjonalnie dojrzałe zespoły unikają myślenia czarno-białego.
Zamiast:
"„To jest złe.”"
pytają:
"„Co optymalizujemy?”"
Ta mała zmiana dramatycznie poprawia jakość dyskusji.
Seniority i elastyczność
Ciekawe, że doświadczeni inżynierowie często stają się bardziej elastyczni z czasem.
Nie dlatego, że przestają im zależeć.
Ale dlatego, że już widzieli:
• trendy znikające,
• „idealne” architektury padające,
• overengineering tworzący chaos,
• i proste rozwiązania przetrwające lata.
Doświadczenie często redukuje niepotrzebną pewność.
I szczerze — myślę, że to zdrowe.
Sztywne myślenie może wydawać się intelektualnie silne, ale elastyczne myślenie zwykle lepiej adaptuje się do rzeczywistości.
Rozwiązania i komunikacja
Kolejna rzecz warta wspomnienia: sposób prezentacji rozwiązania ma prawie takie samo znaczenie jak samo rozwiązanie.
Dwie osoby mogą zaproponować bardzo podobny pomysł.
Jedna tworzy napięcie emocjonalne.
Druga współpracę.
Dlaczego?
Bo styl komunikacji wpływa na to, jak pomysły są odbierane.
Na przykład:
"„Twoje podejście jest błędne.”"
tworzy zupełnie inną atmosferę niż:
"„Co myślisz o zbadaniu innego kierunku?”"
Nawet technicznie genialni ludzie mogą mieć trudności zawodowo, jeśli nie potrafią komunikować rozwiązań w emocjonalnie inteligentny sposób.
Prostota jest trudna
Myślę, że prostota to jedna z najtrudniejszych rzeczy w inżynierii.
Skomplikowane rozwiązania czasem wydają się imponujące.
Proste często wymagają:
• głębszego zrozumienia,
• dystansu emocjonalnego,
• cierpliwości,
• i jasności myślenia.
Usuwanie niepotrzebnych rzeczy jest zaskakująco trudne.
I ciekawe — wiele dojrzałych systemów odnosi sukces nie dlatego, że zawierają wszystko.
Ale dlatego, że usuwają to, co niepotrzebne.
Podsumowanie
Myślę, że zrozumienie, iż może istnieć wiele sensownych rozwiązań, to jedna z największych zmian mindsetu w branży IT.
Poprawia:
• współpracę,
• komunikację,
• inteligencję emocjonalną,
• podejmowanie decyzji,
• i teamwork.
Bo gdy przestajemy traktować dyskusje jak bitwy, tworzymy przestrzeń na prawdziwą kooperację.
Celem zwykle nie jest udowodnienie, kto jest najmądrzejszy.
Celem jest znalezienie najzdrowszej równowagi między:
• potrzebami biznesowymi,
• jakością techniczną,
• ludzkimi ograniczeniami,
• i długoterminową stabilnością.
A może dojrzałość w inżynierii to nie zawsze znajdowanie idealnego rozwiązania.
Może chodzi o zrozumienie kompromisów na tyle jasno, by wybrać rozwiązanie najbardziej odpowiednie dla obecnego kontekstu.
Bo kontekst ciągle się zmienia.
A może naprawdę silne zespoły to nie te, które unikają niezgodności.
Może to te, które potrafią omawiać różne rozwiązania bez zamieniania współpracy w rywalizację ego.
Dzięki!
Seria Soft Skills
Część 7 z 32. Więcej na blogu Empatalk lub ankieta DNA komunikacji: empatalk.app/survey.
Źródła i dalsza lektura
• Sweller, J. (1988). Cognitive load during problem solving. Cognitive Science. https://doi.org/10.1207/s15516709cog1202_4