Trzy razy NIE, czyli co ci daje doświadczenie

Trzy razy NIE, czyli co ci daje doświadczenie

Każdego dnia staram się obserwować cały nasz świat programowania i wyciągać wnioski dotyczące tego, o co tak naprawdę tutaj chodzi. Po kilku latach w branży rozumiem, że to, co kiedyś wydawało mi się prawdą absolutną, w rzeczywistości wygląda zupełnie inaczej. Dzisiaj chciałbym wam przedstawić, jakimi błędnymi przekonaniami dotyczącymi programistów może się kierować każdy z nas bez dostatecznego doświadczenia.

NIE musisz wiedzieć wszystkiego

“Wiedza absolutna” to jeden z mitów na którym łapie się wielu początkujących programistów. Patrząc na całe sterty książek i podręczników związanych np. z językami programowania kiedyś wydawało mi się, że najlepsi programiści pochłonęli wszystkie te tytuły do poduszki. Kierując się takim myśleniem łatwo dojść do wniosku, że najlepsi programiści wiedzą wszystko. Są ekspertami w kilku językach programowania jednocześnie, realizowali projekty małego, średniego i dużego rozmiaru i potrafią się wypowiedzieć na każdy temat.

Pomimo tego, że pracowałem już w kilku firmach i realizowałem rozmaite projekty w wielu technologiach, to szczerze mówiąc nie pamiętam nikogo kto pasowałby do powyższego opisu. W żadnym wypadku nie mogę jednak powiedzieć, że nie spotkałem na swojej drodze prawdziwych ekspertów. Spotkałem ich wiele razy. Muszę powiedzieć, że charakterystyka ich pracy różni się znacząco od kogoś, kto “wie wszystko”. Jak to wygląda w rzeczywistości? W ogromnej większości przypadków eksperci których spotykałem do tej pory pasują do modelu “T-shaped”, czyli umiejętności w kształcie litery T. Z jednej strony posiadają oni jedną specjalizację, w której czują się bardzo mocno i na której zjedli zęby (belka pionowa w literze T), ale z drugiej posiadają szeroką, ogólną wiedzę na temat tego co dzieje się aktualnie w świecie programowania (belka pozioma).

Przykład – osoba której umiejętności przypominają literę “T” jest ekspertem w świecie Javy, rozumie jak to wszystko działa pod maską i wykorzystuje tę wiedzę w praktyce, a poprzez liczne projekty które zrealizowała zna mocne i słabe strony tego języka programowania. Nie zapomina jednak, że na Javie świat się nie kończy – może swobodnie rozmawiać o technologiach front-endowych, w wystarczającym stopniu rozumie zagadnienia związane z bazami danych czy administracją serwerów. Z jednej strony jest specjalistą, ale z drugiej, poprzez szeroką wiedzę ogólną może się lepiej komunikować z innymi członkami zespołu albo np. wie kogo zapytać o pomoc jeśli dany problem wykracza poza jej obszar specjalizacji. Jeśli taka osoba będzie kiedyś zmuszona do zmiany specjalizacji to zrobi to zdecydowanie szybciej, niż ktoś kto pracował “z klapkami na oczach”.

Jeśli obawiasz się, żę “nie wiedząc wszystkiego” nie osiągniesz sukcesu, to możesz być spokojny – rozsądni szefowie firm i tak wiedzą, że nie mogą uzależnić sukcesu firmy czy projektu od jednej osoby.

NIE wszystko musisz rozwiązać samemu

Filmy akcji i historie o superbohaterach nauczyły nas, że do rozwiązywania problemów najlepiej nadają się wybitne jednostki które zajmą się wszystkim od A do Z. Superman nokautując w powietrzu kolejnych przeciwników ratuje świat, a zwykli ludzie mogą co najwyżej obserwować wszystko z poziomu ulicy i robić zdjęcia. Pod wpływem m.in. takich historii niedoświadczonym programistom może się wydawać, że od ich sukcesu zależy liczba problemów które załatwią w pojedynkę i będą takimi właśnie Supermanami i Batmanami.

W programowaniu zdecydowanie częściej przydaje się coś innego – myślę w tym momencie o umiejętności mówienia “nie wiem”. Umiejętność ta przydaje się na każdym stopniu zaawansowania:

  • nie wiem jak rozwiązać ten problem, ponieważ jestem początkującym – potrzebuję wsparcia
  • mam duże doświadczenie ale akurat w tej kwestii nie wiem, czy to wystarczy – lepiej gdybyśmy mogli się nad tym zastanowić wspólnie
  • mam dobry pomysł, ale nie wiem czy nie pominąłem przypadku szczególnego – co mógłbym poprawić?

Jeśli jesteś początkującym, to nie ma sensu zamykać się na pomoc innych żeby tylko pokazać, że “dasz radę”. Za kilka miesięcy pewnie dasz radę, ale teraz, dla dobra projektu zaproś do współpracy bardziej doświadczonych od siebie. Taką decyzją możesz zapunktować bardziej niż po wielu wybitnych pomysłach.

Jeśli pomimo doświadczenia masz wątpliwości czy twoje rozwiązanie danego problemu jest wystarczające, to zaproszenie innych osób do współpracy może zdecydowanie podnieść jakość tego co robisz.

Jeśli szukanie rozwiązania danego problemu było gładkie i przyjemne, to prawdopodobnie nie przyszedł ci na myśl żaden przypadek szczególny. Prawie każdy z nas po kilku godzinach zastanawiania się jak rozwiązać jeden konkretny problem traci szersze spojrzenie na to co właśnie robi. W tym momencie może pomóc jedynie zakomunikowanie tego innym osobom, które mogą obiektywnie spojrzeć na to co robisz.

Wielokrotnie w swojej pracy przekonywałem się, że rozwiązywanie wszystkiego samemu nie przynosi takich efektów, jak dobrze wykonana praca zespołowa. W programowaniu jest miejsce dla wybitnych jednostek, ale na pewno nie jest to sport indywidualny. Doświadczenie które zyskasz realizując kolejne projekty pomoże ci zrozumieć, że nie wszystko musisz rozwiązywać samemu.

NIE wszystko jest warte rozwiązywania

Nie wszystko musisz rozwiązać samemu, ale uważaj – czasami dany problem nie jest w ogóle wart rozwiązywania. Dziwne… przecież im więcej dzisiaj zrobię, tym lepszym programistą się okażę, prawda?

Jeśli bardziej liczy się dla ciebie ilość pracy, a nie jakość, to ten punkt jest dla ciebie.

Problemy z którymi mierzymy się w programowaniu prawie zawsze można rozbić na mniejsze składowe. Rozwiązanie tych składowych pomaga nam w rozwiązaniu głównego problemu. Z projektami które realizujemy jest podobnie. Na dany projekt składa się zazwyczaj kilka modułów, które zrealizowane w całości mogą nam przynieść określony rezultat. No właśnie, czy na pewno w całości?

O tym, jak poszczególne składowe wpływają na końcowy rezultat możemy się dowiedzieć np. z Zasady Pareto. Co prawda nie można jej traktować w kontekście programowania w sposób dosłowny, ale dobrze oddaje ona sens tego o czym chcę napisać. W skrócie – zasada ta mówi, że wiele zjawisk, np. z obszaru ekonomii czy zarządzania charakteryzuje się tym, że 20% nakładu przyniesie 80% rezultatu. Rzadko kiedy wszystko jest równie ważne i ma taki sam priorytet. W programowaniu możemy to doskonale zobaczyć.

Projektów nie realizujemy w świecie z zatrzymanym czasem, przy nieograniczonym budżecie i z nieograniczonymi zasobami. Zespół projektowy to kilka, czasami kilkanaście osób, sam projekt musimy dowieźć w określonym czasie, a do tego wypadałoby jeszcze coś na tym zarobić. Czas leci, spalamy pieniądze, a do współpracy nie możemy zapraszać nieskończonej liczby osób. To właśnie dlatego bardzo ważnym jest ustalanie priorytetów i zastanawianie się nad tym, czy problem który chciałbym dzisiaj rozwiązać jest w ogóle wart rozwiązywania.

Postawmy obok siebie dwa problemy. Po pierwsze chcielibyśmy zoptymalizować działanie jednej ze stron w naszej aplikacji co do której kilku klientów zgłaszało uwagi, a po drugie chcielibyśmy poprawić formularz rejestracyjny. Czym powinniśmy się zająć w pierwszej kolejności? Jeśli problemy ze stroną zgłosiło trzech “drobnych” klientów, a na skomplikowanym formularzu tracimy 90% potencjalnych użytkowników, to odpowiedź jest jasna – większy wpływ na kondycję naszej firmy/projektu w dłuższej perspektywie będzie miał właśnie formularz. Czy to znaczy, że optymalizacja strony nie jest warta naszego czasu? To zależy – być może możemy się nią zająć nieco później, a być może należy sprawdzić, czy to kod naszej aplikacji na pewno jest problemem, zamiast np. niedostatecznej jakości szkoleń naszych użytkowników?

Każdy problem który chcemy rozwiązać wymaga czegoś w rodzaju rachunku zysków i strat, co doskonale wyjaśnia w swojej prezentacji Greg Young:

Doświadczenie, czyli aktualizacja spojrzenia na świat

Czytałem ostatnio artykuł przedstawiający sylwetkę CEO firmy Google. Szczególnie zaciekawiło mnie tam jedno spostrzeżenie głównego bohatera tego materiału. Sundar Pichai, o którym mowa, zastanawia się, czy tempo zmian jakie obecnie obserwujemy w świecie IT na pewno pasuje do tempa w jakim naturalnie zmienialiśmy się do tej pory my wszyscy jako ludzkość. Nie można zaprzeczyć, że kolejne iteracje procesorów, smartfonów czy kart graficznych pojawiają się zanim jeszcze w pełni wykorzystamy potencjał aktualnych generacji.

Czy my, programiści, aktualizujemy swoje przekonania w takim samym tempie jak zmienia się świat wokół nas? Czy na pewno korzystamy z tego co daje nam doświadczenie w zawodzie?

Droga od praktykanta do tzw. “seniora” jest w wielu firmach na tyle krótka (porównując ją do innych branż), że programista w dzisiejszych czasach musi być w stanie aktualizować swoje przekonania w bardzo szybkim tempie. Dopiero co zaczynałeś, a mija kilkanaście miesięcy i prowadzisz swój pierwszy projekt. Jakiś czas później być może zarządzasz zespołem, wchodzisz w większą interakcję z klientami i użytkownikami, i wciąż zmieniasz zakres swoich obowiązków.

Doświadczenie które zdobywamy realizując kolejne projekty pokazuje bardzo często, że praktycznie niemożliwym jest trzymanie się tych samych przekonań co do innych ludzi i sposobu pracy co na początku drogi. Ważne jest, żeby trenować w sobie tę “zwinność” o której tak często słyszymy w świecie programowania. Punkty które wymieniłem w dzisiejszym poście, takiej jak chociażby otwartość na współpracę, mogą być dla wielu szczególnie ciężkie do zaakceptowania z powodu tego jak zostaliśmy wychowani w młodości. Nieważne jednak w co wierzyliśmy nie posiadając dostatecznego doświadczenia – jeśli po czasie widzimy, że powinniśmy zdecydowanie zmienić nasz sposób myślenia, to po prostu powinniśmy to robić!

Jestem ciekaw jak to wygląda u was – jakie przekonania co do zawodu programisty i naszej branży zmieniały się wraz z tym, jak zdobywaliście więcej doświadczenia?

  • Radosław Maziarka

    Szaczunek za podlinkowanie prezentacji Grega Younga – jedna z lepszych jego prezentacji. Ile razy robiliśmy soft, który ostatecznie nie był nikomu potrzebny? Ile razy robiliśmy bo nam się wydawało że to będzie potrzebne, bez żadnych konsultacji? Ile rzeczy dało się prościej zrobić skupiając się na tym co jest naprawdę istotne?

    • Przemek Smyrdek

      “People as a service” 😉

    • Adrian Bystrek

      Trzeba przyznać, że ta prezentacja mu wyszła 😛 Najlepszy jest komentarz na youtube (pierwszy z góry od John Doe) – polecam się zapoznać 😛