Jak zostać specjalistą, który zna się na wszystkim

Źródło: https://unsplash.com/@cbyoung

Długość wpisu: 14 min

Gdy jeszcze studiowałem, po naszym wydziale krążyła legenda o jednym z kolegów. Według tej legendy, przeczytał on książkę o programowaniu od dechy do dechy i dało mu to takiego kopa wiedzy, że bez problemu przyjęli go do pracy. Jako prawdziwego programistę 😱.

Wtedy coś takiego było dla mnie nieosiągalne. Nie czułem się na siłach pracować w “prawdziwej” firmie, mimo że od roku pracowałem jako freelancer.

Zacząłem więc, jak najszybciej się uczyć, żeby dostać jakąś sensowną pracę.

Zastosowałem strategię z legend - czytałem książki od dechy do dechy. Najpierw o C# i .NET, a potem MVC.

Okazało się, że samo przeczytanie książki nie wystarcza, bo nie umiałem napisać linijki sensownego kodu, ale w końcu nauczyłem się też kodzić.

Potem poszedłem na praktyki, a następnie zacząłem pracować. Tak samo, jak mój kolega.

I naprawdę ogarnialem C# oraz MVC, więc wychodzi na to, że w każdej legendzie jest trochę prawdy 🤷‍♂️.

Gdy tak pochłaniałem te wszystkie książki, to liczyłem, że w połączeniu z doświadczeniem zdobytym w pracy szybko zostanę cenionym specjalistą. Że kasa skoczy do góry itd.

W pracy okazało się, że faktycznie wiedza książkowa coś daje.

Co 2 tygodnie mieliśmy spotkania developerów, gdzie różne osoby pokazywały coś ciekawego. Coś, nad czym pracowali albo jakieś fajne nowinki techniczne.

Dość szybko zorientowałem się (i bardzo mnie to zaskoczyło), że wiem o MVC więcej niż wszyscy.

Niby fajnie.

Szkoda, że w ogóle nie miało to znaczenia.

Smutna historia niedoszłego “specjalisty”

Po pierwsze, używaliśmy innych technologii w projekcie 😂.

Ja znałem C# w wersji 5, ASP.NET MVC 4.5, i myślałem, że cały świat już się na to przerzucił (wtedy to był zajebisty kawałek technologii, trust me).

Jednak w projekcie używaliśmy .NET, ale w starej wersji (chyba 2 albo 3), zamiast C# był VB.NET (żadnych klamerek i średników ;(), a MVC używane było tylko w jednym podprojekcie.

Większość stacku technologicznego była przestarzała i pod warstwą przedpotopowego ASP Web Forms kryła się kupa gruzu w postaci legacy kodu, obok którego dobre praktyki tworzenia oprogramowania nawet nie stały.

No i ta moja specjalizacja przestała mieć wartość dla pracodawcy. Bo co z tego, że znałem wszystkie najnowsze ficzery C#, skoro nie miałem gdzie ich wykorzystać?

Jako Junior Dev często jesteśmy wrzucani w takie bagno. Nie mamy jeszcze zbyt wiele do zaoferowania światu, dopiero trzeba się wykazać żeby dostać lepsze projekty i taski.

Trochę podobnie miałem później z projektami Reactowymi, do ktorych trafiałem. Znałem Reacta na wylot i umiałem używać wiele zajebistych bibliotek. Problem w tym, że w praktyce, czysty React i odrobina Reduxa wystarczały, żeby poradzić sobie ze wszystkimi problemami, jakie stawiał przed nami projekt.

Jak w takich wypadkach udowadniać, że jesteśmy specjalistami, mimo że nie mamy jak udowodnić, że się na czymś znamy?

W jaki sposób rozwijać umiejętności?

Jest na to sposób, który zawsze działa.

Nie bądź jak nóż do masła

Wyobraź sobie, że masz plastikowy nóż do masła. Jego zadaniem jest smarować i wychodzi mu to dość dobrze.

Problem zaczyna się, gdy masło jest twarde.

Warto wtedy zrobić upgrade na taki ze stali nierdzewnej, czy czego tam się teraz używa. Można by go pewnie też bardziej naostrzyć, ale nie za bardzo jest po co.

Kończy się nam lista usprawnień do naszego noża.

To teraz wyobraź sobie, że wymieniasz ten nóż na scyzoryk.

Bez problemu może on służyć jako nóż do masła. Co więcej, otworzy jeszcze wino i browara, a gdy odkręci Ci się śrubka w samochodzie, to sobie dokręcisz. Tak po prostu.

Zamiast pakować energię w jeden ficzer, dodaliśmy kolejne.

W taki sam sposób można myśleć o swoich umiejętnościach - zamiast ulepszać tylko jedną umiejętność, można skupić się na innych i tym samym znacznie podnieść swoją wartość.

W IT ma to nawet swoją nazwę: programista T-shape.

Programista T-shape

Z Wikipedii:

The concept of T-shaped skills, or T-shaped persons is a metaphor used in job recruitment to describe the abilities of persons in the workforce.

The vertical bar on the letter T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one’s own.

Łatwiej pokazać to na obrazku:

Górna belka litery T to wszystkie umiejętności podstawowe, które posiadasz.

“Noga” litery T oznacza głębię, specjalizację.

Programista T-shape to taki, który jest spejcalistą w jednej technologii (lub zestawie technologii), a przy okazji ma wiele umiejętności supportujących, które pomagają mu w pracy.

Przykładowo, możemy mieć frontend deva, który zna się na JSie i Reakcie, jest to jego podstawa. Przy okazji liznął też trochę Node.js, trochę relacyjnych baz danych, wie jak skonfigurować continous integration i potrafi pisać czytelną dokumentację.

Gdyby litera T miała dwie nogi to byłaby czymś na kształt “π”. Programista π-shaped to taki, który ma dwie specjalizacje i wiele umiejętności supportujących.

Zalety programisty T-shape

Aplikacje nie są pisane w izolacji

Najbardziej oczywista zaleta to umiejętność prowadzenia sensownej rozmowy na inne tematy niż obszar Twojej ekspertyzy.

Aplikacji nie budujemy w izolacji. Projekt to praca zespołowa i znacznie efektywniej się pracuje, gdy każdy w zespole jest w stanie efektywnie porozmawiać o każdej warstwie w stacku technologicznym.

Przykład: baza danych często wpływa na to, w jaki sposób projektujemy UI. Warto więc rozumieć przynajmniej podstawy baz danych, możliwości i ograniczenia, bo dzięki nim będziemy wiedzieć jak praca innych osób wpływa na naszą.

Dzięki zajomości innych obszarów zaczynasz też dostrzegać uniwersalne wzorce i praktyki. Dzięki temu jest Ci znacznie łatwiej uczyć się nowych technologii i ocenić czy ta nowa fancy libka, która wchodzi na rynek, jest czymś sensownym, czy może majaczeniem szaleńca, który uznał, że za mało jest libek JSowych na GH i chciał po prostu napisać kolejną. (Just kidding, warto pisać swoje frameworki, kiedyś o tym napiszę.)

Osoby, które mają oczy skierowane tylko i wyłącznie na fronted i JavaScript często myślą, że Dan Abramov, który stworzył Reduxa jest swego rodzaju Jezusem programowania i wielbią go jak boga.

Ci, którzy mają szerszą wiedzę, widzą, że zastosował on patterny znane w programowaniu od wielu lat (część nieświadomie) i bardzo fajnie zmixował je ze sobą. Dlatego tak dobrze to działa. Gdy takie osoby używają Reduxa, to wiedzą, co jest dobrą praktyką, a co złą. Wiedzą, które dobre praktyki sugerowane w dokumentacji trzeba traktować ostrożnie i dlaczego.

Rozmowy techniczne

Taka wiedza pozwala Ci brać czynny udział w rozmowach technicznych i rozwijać się jeszcze szybciej.

Pamiętam z jakim podziwem zawsze patrzyłem na liderów technicznych, z którymi pracowałem, gdy rozmawiali o architekturze aplikacji i dobierali rozwiązania.

Musiałem wyglądać jak Baby Yoda wpatrzony w Mandaloriana:

Potrafili oni rozmawiać na temat architektury, bo po prostu znali się na każdej z tych warstw i technologii. I wcale nie byli w nich specjalistami.

Samo przysłuchiwanie się takim rozmowom jest dobrym sposobem na zdobywanie nowych umiejętności.

Jednym z największych błędów, które widzę wśród świeżych programistów, jest olewanie takich technicznych dyskusji.

To, że jesteś frontendem nie oznacza, że możesz olewać rozmowy na temat baz danych. I to samo w drugą stronę.

Bus factor

Budując górną belkę litery T stajesz się bardziej odporny na bus factor.

To znaczy, jeśli Twojego kolegę lub koleżankę potrąci w drodze do pracy autobus to nie będziesz czekał aż zatrudnią nowego bazodanowca, żeby założył Ci indexy i żebyś mógł dokończyć swojego taska. Sam sobie stworzysz tabelki, założysz indexy i wyseedujesz bazę.

Nie będzie to idealne, ale będzie działać, a Ty dowieziesz to, co masz dowieźć. Dostarczysz wartość, którą masz dostarczyć.

Dwie lewe ręce przestają być w modzie. Just sayin’.

Niezależność i mindset

Taki rodzaj niezależności jest bardzo mocno ceniony przez pracodawców.

Powód jest prosty - im więcej masz takich ogólnych skilli, tym bardziej jesteś niezależny i tym bardziej jesteś w stanie dowozić projekty.

Wyobraź sobie typa, który jest specjalistą od Reacta. Nie używał każdej możliwej libki, ale jak będzie trzeba, to sobie doczyta i ogarnie.

W dodatku potrafi sobie postawić bezpieczne API, postawić Postgresa, zdeployować apkę, podpiąć CI i dogadać z klientem wszystkie wątpliwości, a na końcu zrobić mu demo i na podstawie otrzymanego feedbacku wrzucić taski do Jiry. Nie jest w tym specjalistą, ale wszystko zrobi.

I teraz wyobraź sobie typa, który tylko kodzi fronty. Nie za bardzo chce się uczyć baz danych, bo go brzydzi SQL, a rozmowami z klientem powinien zajmować się jakiś QA lub BA.

Zgadnij, kogo bardziej ceni pracodawca? Kto potrafi bardziej pomagać swoim kolegom? Kto będzie dostawał ciekawsze projekty i taski do zrobienia?

Który z nich ma lepsze szanse na rynku pracy?

Który z nich lepiej zarabia?

Nie umniejszam tutaj osobom, które chcą się specjalizować w jednej rzeczy, bo specjalizacja jest ważna. Równie ważne jest niezamykanie się na inne technologie i umiejętności.

Wiele osób pewnie dostanie tutaj drgawek i zacznie szukać sekcji z komentarzami, żeby nawrzucać mi, że przecież nie można się na wszystko godzić, nie można się wszystkiego nauczyć i że “jak ktoś jest od wszystkiego to jest do niczego”.

Bardzo ładna rymowanka i za chwilę ją zaadresuję.

Teraz chcę tylko powiedzieć, że wszystkiego da się nauczyć naprawdę szybko, jeśli przestanie się marnować czas i energię na bzdury.

Gdy pracowałem w projekcie, który opisywałem we wstępie to ciągle marnowałem czas i energię na:

”Powinniśmy używać nowego MVC, kto jeszcze pisze w Web Formsach?”

“Softu nie powinno się tak pisać…”

“Ten gościu nawet nie zna wzorców projektowych, dlaczego w ogóle tu pracuje? Może nie powinien?”

“Tak duży klient powinien przywiązywać większą uwagę do jakości oprogramowania.”

”Powinniśmy dostać na to więcej czasu.”

Podkreśliłem słowa “powinno” i “nie powinno”, bo są to typowe objawy mindsetu ofiary, czyli po noszymu bóldupiarstwa oraz marnowania energii i czasu.

Sam kiedyś byłem ofiarą, więc wiem coś o tym.

Ogólnie, są dwa rodzaje mindsetu:

1. mindset ofiary - “to powinno/nie powinno (tu wstaw wybrany #bóldupy)”
2. mindset zwycięzcy - “jest z dupy, ale ogarnę”

Nie ma znaczenia co być “powinno”, znaczenie ma to, co “jest”.

Więc jeśli chcesz powiedzieć, że “powinniśmy” dostać na to więcej czasu, to idź i załatw więcej czasu, albo wykombinuj jak się zmieścić w tym czasie, który masz, bo marudzenie tylko zabiera ten czas i energię.

W moim przypadku, gdy traciłem energię na narzekanie, to inni uczyli się i kombinowali, a potem dostawali podwyżki (mimo że nie powinni ;)) za rozwiązywanie problemów. Skupili się na tym, co jest i robili to, co było do zrobienia.

“Jak coś jest do wszystkiego to jest do niczego”

Gdy kupujemy lodówko-pralko-żelazko, które poza chłodzeniem potrafi jeszcze prać i prasować to najprawdopodobniej nie jest dobra w żadnej z tych rzeczy i szybko się popsuje. Chyba że jest z Japonii. Wtedy spoko 👍.

Lodówko-pralko-żelazko skupia się na wszystkim po trochu, ale w niczym się nie specjalizuje. Tak jak w tej rymowance.

Programista T-shape to przede wszystkim specjalista. Jednej lub wielu specjalizacji.

Jest jak wspomniany scyzoryk, którego specjalizacją jest bycie nożem i przecinanie, ale przy okazji naprawdę dobrze otwiera te browary.

Wszystkie skille, które zdobwa programista T-shape wspierają w jakiś sposób jego specjalizację. Dlatego rymowanka w tym wypadku się nie aplikuje.

Jak zostać specjalistą, który zna się na wszystkim

“Specjalista, który zna się na wszystkim” to taki trochę clickbait.

Chodzi o to, żeby zostać specjalistą w jednej lub kilku rzeczach, ale jednocześnie mieć też wiedzę z innych obszarów, które będą wspierać tę specjalizację.

Znać się na “wszystkim” po trochu i na jednej lub kilku rzeczach bardzo dobrze.

Z moich obserwacji wynika, że im szybciej zaczynamy uczyć się “wszerz”, tym szybciej zwiekszamy swoją wartość.

Mój sposób na budowanie specjalizacji (liczba mnoga) i zdobywanie innych umiejętności supportujących:

1. Wybieram specjalizację
2. Uczę się (przez czytanie i praktykę), dopóki nie zacznę się nią biegle* posługiwać
3. Zawsze zostawiam coś do nauki na potem, nauczę się, gdy będzie mi to potrzebne
4. Znajduję najbardziej przydatne “umiejętności supportujące”, które nie są bezpośrednio związane ze specjalizacją
5. Wybieram jedną
6. Uczę się (przez czytanie i praktykę), dopóki nie zacznę się nią biegle posługiwać
7. Szlifuje specjalizację i umiejętności supportujące
8. Wracam do punktu 4, a czasem do 1, gdy chce zdobyć nową specjalizację

Przykład z mojego obecnego projektu

Każda nowa osoba, która dołącza musi specjalizować się w JSie, Reakcie i Reduxie.

Skille supportujące to budowanie API w Expresie, obsługa Oracle’a, zadawanie pytań, komunikacja z klientem, analiza biznesowa.

Nie mamy w zespole uber ekspertów z żadnej z tych umiejętności, ale wszyscy sobie radzą.

Z racji tego, że każdy rozwija się wszerz, jesteśmy w stanie sobie pomagać. Jednocześnie, gdy kogoś wywieje na L4, to jesteśmy w stanie pociągnąć dalej wiszące taski.

Które umiejętności supportujące warto zdobyć

To, jakich umiejętności będziesz się uczył, mocno zależy od Twojego otoczenia. Nie ma gotowej listy.

Z moich obserwacji wynika, że najlepiej skupić się na tym, co najbardziej ceni Twój pracodawca, a najbardziej wartościowe umiejętności, poza wybraną specjalizacją, to umiejętności miękkie.

Nie bez powodu komunikacja to jedna z najważniejszych umiejętności w IT.

Najbardziej poważne problemy w projekcie są powodowane głównie przez słabą komunikację, nie przez słabo napisany kodzik. Słabo napisany kodzik jest powodowany przez słabą komunikację. Serio.

Jest to bardzo dobry skill do nauki na początek. Większość programistów myśli, że potrafi się dobrze komunikować, a tak naprawdę większość z nas to pozbawieni empatii troglodyci. Poniżesz masz nagranie, które udowodni Ci, że nie kłamię i że nie masz pojęcia o komunikacji.

Szczególnie polecam zainteresować się non-violent communication. Mega pomaga w komunikacji z problematycznymi kolegami, sprawdziłem.

🔗 Bonusowy link: świetna lista “soft skilli od mistrza marketingu Setha Godina”.

Inna strategia to uczenie się czegoś, co przylega bezpośrednio do Twojej specjalizacji.

Jeśli umiesz frontend to naucz się budować API. Jeśli umiesz budować API to naucz się frontendu.

Naucz się podstaw devopsowania, baz danych i security.

Naucz się pisać testy, bo to integralna część pracy nad kodem.

Polecam też pisanie dokumentacji i analizę biznesową. Są to rzeczy, które bezpośrednio przylegają do każdej specjalizacji i nie muszą być nudne, jeśli wiesz jak to robić.

Do czego to wszystko prowadzi?

Zastosowanie mindsetu zwycięzcy i uczenie się w stylu T-shaped może bardzo mocno podnieść Twoją wartość na rynku pracy.

Niejednokrotnie widziałem osoby, które zaczynały jako programiści jednej technologii, ale budowały skille wszerz tak, że w końcu znali kilka języków programowania, technologie backednowe, frontendowe, bazy danych, potrafili zbudować architekturę, potem to wszystko spinali narzędziami devopsowymi jak magicy, przy okazji dogadywali wszystko od początku do końca z klientem i testowali tak, że QA nie było potrzebne.

Potem zakładali swoje firmy, bo zaczynało brakować rzeczy, których mogliby się nauczyć.

Wartość takich osób na rynku jest ogromna.

Nie wszystko da się zrobić od razu. Jest mnóstwo rzeczy, których można lub trzeba się teraz nauczyć.

Najważniejsze to zbudować proces, identyfikować rzeczy, które przynoszą wartość w Twoim miejscu pracy i metodycznie uczyć się nowych rzeczy.

No i nie narzekać na to, co być powinno, a co nie powinno.

Nigdy nie przestawaj

Proces ten będzie najprawdopodobniej trwać w nieskończoność, bo taką mamy branżę.

Na szczęście większość obecnych technologii opiera się na sprawdzonych wzorcach wymyślonych dawno temu. Są to po prostu kolejne reinkarnacje.

W pewnym momencie zaczniesz dostrzegać te wzorce i przestanie być dla Ciebie problemem nauka nowych rzeczy.

Ja miałem tak z Reactem. Gdy czytałem pierwszy raz dokumentację, to oczy mi się świeciły, bo rozpoznawałem w nim wzorce, które znałem wcześniej i które działały. Już podczas czytania dokumentacji wiedziałem, że będzie mi się z nim dobrze pracowało. I miałem rację.

Zacznij zbierać profity

W miare rozwoju umiejętności najprawdopodobniej ktoś zacznie dostrzegać, że szybko levelujesz. Z racji tego, że rośniesz wszerz, a nie tylko wgłąb, będzie to przyspieszony proces i będziesz mógł zbierać owoce swoich prac szybciej.

Jeśli nie, to warto, abyś upomniał się o swoje przy następnej rozmowie okresowej. O ile takie się u Ciebie praktykuje. W przeciwnym wypadku, pewnie znajdziesz kogoś z kim możesz pogadać.

Warto wtedy zapytać o feedback, czy te nowo zdobyte skille przynoszą wartość. Jeśli tak, to spytaj co jeszcze możesz zrobić i co możesz dostać w zamian. Just like that.

A jeśli chcesz mieć pewność, że zostaniesz dostrzeżony, to zacznij dzielić się wiedzą, którą zdobywasz.

Załóż bloga, zacznij robić wewnątrzfirmowe prezentacje, promuj firmę przez dzielenie się wiedzą na meetupach itd.

Nie dość, że utrwalisz zdobytą wiedzę, to wyjdziesz z cienia i inne osoby zaczną dostrzegać to, co masz im do zaoferowania.

Podsumowanie

Pokazałem Ci, w jaki sposób możesz rozwijać się jako programista T-shape i dlaczego warto.

Najlepsi specjaliści jakich znam, rozwijają się w ten sposób.

Przyspieszysz swój rozwój, poradzisz sobie w większej ilości sytuacji i będziesz podejmować lepsze decyzje.

Przyniesiesz większą wartość pracodawcy, a tym samym zwiększysz swoje szanse na lepszą kasę. Polecam spróbować.

Jeśli są jakieś szczególne umiejętności, które pominąłem i które warto rozwijać poza specjalizacją, to daj mi znać.

🖖