Czego od juniora oczekuje architekt oprogramowania

Transkrypcja

Dziś moim gościem jest Radek Madecki. Radek opowie nam o zawodzie architekta oprogramowania i jego roli w karierze junior developera. Radku, dziękuję, że przyjąłeś moje zaproszenie na rozmowę.

Siemanko, Mateusz, mnie jest również bardzo miło, że mnie zaprosiłeś. To jest mój pierwszy raz, więc… jaram się.

Czy możesz się przedstawić i powiedzieć, co łączy Cię z branżą IT?

Branża IT to było takie moje marzenie od dziecka. Pamiętam, że jak byłem mały, to z klocków Lego zamiast jakichś zamków, składałem repliki sprzętu RTV i AGD, typu dekodery. Wycinałem z gazet reklamy telefonów i je pogrubiałem. Zawsze gdzieś mnie to jarało, ale w pewnym momencie myślałem, że pójdę w ogóle w inną stronę. Też było to związane z IT – grafika. W końcu skończyłem w sprzedaży. Gotowałem za granicą i robiłem różne inne takie rzeczy, ale zawsze z tyłu głowy miałem to, że chciałbym być stricte programistą. Jakoś bardzo podobała mi się ta wizja, że piszesz tekst i potem tworzy się z tego „żywy organizm”. Tak naprawdę właśnie wracając z tego wyjazdu, gdzie skończyłem na kuchni (to jest długa historia, może nie na dzisiaj), stwierdziłem, że odłożę trochę kasy (wróciłem na chwilę do sprzedaży), poświęcę potem dwa miesiące, będę żył z tych oszczędności, ale będę się uczył osiem godzin dziennie i może w końcu mi się uda.

Wcześniej zajmowałem się freelancingiem, robiłem jakieś stronki, nieraz tak naprawdę za darmo. Raz dla siłowni robiłem program do zarządzania zapisami na zajęcia i w zamian za to miałem roczny karnet. Potem zaczęły się takie mniejsze zlecenia za kasę. Pierwszą swoją stronę, taki fun fact, zrobiłem w gimnazjum za siedemdziesiąt złotych. Robiłem ją chyba miesiąc (taką bardzo prostą stronkę). To była stronka piekarni-ciastkarni i tak strasznie się napatrzyłem na te ciastka, że byłem skłonny zrobić to za to ciasto.

Z końcówką 2016 roku skończyłem już pracę w sprzedaży, miałem te dwa miesiące za sobą, wysyłałem CV – od tego czasu wysłałem chyba ze sto. Większość rozmów wyszła fatalnie, aż w końcu trafiłem na Clearcode. Tam rozmowa wyszła już w miarę dobrze. Dostałem wiadomość, która zaczynała się: „Dziękujemy za Twoją kandydaturę, Radku, ALE…” i już wiedziałem, co będzie dalej, ale dalej było tak naprawdę: „mimo że jeszcze nie wpisujesz się w te wymagania, to chcielibyśmy dać Ci szansę, bo widzimy jakiś potencjał”. No i dali mi tę szansę, ja tę szansę wykorzystałem i od tego czasu gdzieś tam się realizuję – głównie we front endzie, ale też back endzie (Node’owym oczywiście, bo mnie jako front-endowcowi w to najłatwiej było przeskoczyć). Ta pasja do grafiki i UX-u dalej we mnie gdzieś jest, uczę się tego i pracuję blisko z design teamem. Teraz moja rola coraz bardziej polega na ustalaniu architektury na froncie, ale dalej tak samo programuję, piszę kod. W skrócie to tyle. Trochę też miałem wspólnego ze Scrumem – teraz akurat wchodzę w rolę Product Ownera.

No właśnie. Wspomniałeś o tym architekcie. Czy możesz nam powiedzieć, co to jest architektura oprogramowania?

Jasne. Myślę, że architektura programowania w każdej firmie będzie wyglądała trochę inaczej, natomiast takim stałym filarem jest tu ustalenie jakichś połączeń między elementami oprogramowania. W tej chwili aplikacje – przynajmniej te aplikacje, z którymi ja pracowałem – już nie składają się na przykład tylko z front endu i back endu, ale z wielu mikroserwisów back-endowych z jakimiś integracjami z zewnętrznymi serwisami, na przykład do płatności czy jakichkolwiek inny rzeczy.

Po stronie frontu też pojawia się już bardziej rozproszona architektura – mikrofrontendów, czyli takich pomniejszych aplikacji z kompletnie odizolowanym back endem, bazą danych. Architekt to taka osoba, która sprawia, że to wszystko się ze sobą spina; która pomaga teamom tworzącym te rozwiązania dobierać technologie, które na przykład dobrze ze sobą współpracują. Musi to widzieć z lotu ptaka, być świadoma tego, jakie stoją za tym potrzeby biznesowe, by móc przekazywać zespołom, co jest ważne, na czym się powinny teraz skupić – być dla nich drogowskazem.

Czym na co dzień zajmuje się architekt oprogramowania i czy ma kontakt z junior developerami?

Tak na co dzień praca architekta, myślę, to w dużej mierze spotkania. Jak wspomniałem: musi mieć on pogląd na biznes. Nie znaczy to, że jest on zupełnie odcięty od zespołu. To zależy. Są takie firmy, w których architekt jest w teamie i dba o architekturę pomniejszego projektu, ale czasami taki architekt sprawuje pieczę nad wieloma projekcikami. Czyli zależy to od tego, z jakim architektem mamy do czynienia, bo ten, który ma cały ekosystem firmowy do ogarnięcia, często nie będzie wchodził w interakcje z ludźmi z zespołu, natomiast taki, który już w tym zespole jest, to jak najbardziej całkiem sporo z juniorem może mieć wspólnego.

Wydaje mi się, żę tak naprawdę architekt – jako że jest tym stykiem biznesu z developerami, z inżynierami – musi mieć jasny feedback ze strony zespołu: co się da zrobić, a czego się nie da zrobić. Może więc on tak naprawdę po pierwsze wiedzieć, co jest potrzebne biznesowi, powiedzieć juniorowi, na przykład czego się powinien uczyć. Jeżeli jakieś potrzeby muszą być zaadresowane, a junior tego nie potrafi, to architekt może być drogowskazem: uczyć osobiście lub wskazywać materiały, z których korzystać. Ale z drugiej strony architekt potrzebuje mieć od juniora informację, co na dany moment da się zrobić – bo nie da się nauczyć wszystkiego z dnia na dzień. Junior ma prawo nie wiedzieć wielu rzeczy. Klient potrzebuje dostać konkretny feedback – bez kolorowania trawy na zielono. Jeśli mamy jakieś wąskie gardło, czegoś nie umiemy, brakuje nam w zespole jakichś kompetencji, to musimy powiedzieć klientowi, że na przykład potrwa to dłużej, a nie składać obietnice nie do zrealizowania.

Z perspektywy architekta oprogramowania: jakie umiejętności techniczne i miękkie są u juniora najważniejsze?

Jeżeli chodzi o umiejętności techniczne, to nie jestem w stanie tego powiedzieć, bo zależy to od technologii, o której byśmy mówili. Ja mogę oczywiście powiedzieć, co taka osoba powinna umieć, ale z perspektywy architekta frontowego. Zauważam, że to jest bardzo, bardzo różnie. Czasami oczekuje się od takiej osoby, że będzie typowym web-devem, czyli na przykład od juniora będzie się oczekiwać znajomości zasad SEO, jakichś add managerów, rzeczy związanych z trackingiem czy może HTML-a i CSS-a. Z kolei ktoś, kto pracuje w aplikacjach do, powiedzmy, użytku wewnętrznego, może na przykład potrzebować działać z AWS-em i umieć wyklikać jakieś podstawy. To temat rzeka.

Myślę, że to, co jest kluczowe ze strony architekta, to otwartość, chęć dzielenia się feedbackiem, zadawanie wielu pytań – wydaje mi się, że junior może mieć taką blokadę w głowie: że te pytania, które zadaje, są głupie. Ja na przykład tak miałem, bo jak wspomniałem, nie przyszedłem do IT po studiach informatycznych i na początku miałem taki, powiedzmy, kompleks, że jak zadam jakieś pytanie, to się najzwyczajniej w świecie ośmieszę. A to nie o to chodzi.

Wydaje mi się, że przez to, że jest coraz więcej ludzi, którzy napływają do IT z innych branż… Mam teraz na przykład koleżankę w team, która przyszła jako były pracownik instytucji finansowej, a robimy projekt fintechowy, czyli też z finansami. I ona właśnie nieraz potrafi nam powiedzieć rzeczy istotne z punktu widzenia biznesu, o które musielibyśmy zapytać klienta (a ona podaje nam to od razu). Albo pyta, czy na pewno możemy tak to zrobić, bo na przykład jej się wydaje, że nie.

Więc coś, co jest dla mnie super kluczowe, to to, żeby junior chciał się dzielić pomysłami, żeby zadawał pytania, żeby się nie bał, żeby był po prostu transparenty, bo to ułatwia pracę wszystkim: jego project Managerowi czy mnie jako architektowi. Gdybym z takim juniorem pracował, wiedziałbym, jak mogę mu pomóc. Każdy na tym korzysta. Wiem, że dużo moich kumpli czy podopiecznych, którzy zostali teraz juniorami, mają obawę, że muszą robić wszystko, co mid albo senior, że nie są wystarczający – że ktoś im płaci, a oni nie mogą przynieść takiej wartości. To kompletnie nie tak.

Wydaje mi się, że to tak wygląda też dlatego, że w innych branżach od osoby, która przychodzi do pracy, oczekuje się, że te wyniki muszą być już takie mocno namacalne.

Tak.

A w branży IT wygląda to trochę inaczej. Ta perspektywa z innych branż powoduje, że te osoby chcą być lepsze niż tak naprawdę potrzeba.

To prawda. Mnie osobiście było głupio: nie dość, że ja nie mogłem zrobić zadań, które przynosiłyby dużą korzyść, to jeszcze odbierałem czas jakiemuś seniorowi, który ze mną siedział. Mnie wtedy było głupio, ale teraz wiem, że po pierwsze większość ludzi naprawdę lubi pomagać, pogadać sobie, pomentorować, przypomnieć sobie, jak to było. A po drugie to tak naprawdę może być dla seniora szansa rozwoju – tak też na to warto popatrzeć: że robimy tej osobie przysługę, że może się ona spełnić w roli mentora. Potem to jest naprawdę normalne, więc śmiało pytać i być transparentnym. To jest ta najważniejsza podstawa, którą możecie zrobić.

Czy architekt oprogramowania bierze udział w rekrutacji juniorów?

Właśnie jak Ci wcześniej mówiłem, na to spotkanie wszedłem po rozmowie kwalifikacyjnej. Co prawda nie rekrutowałem juniora, ale to akurat jest przypadek, powiedzmy, trochę o to zahaczający, ponieważ jest to back-end developer, który zaczął coś robić na froncie. I szczerze mówiąc, to jego zadanie wypadło dobrze, ale były tam jeszcze pewne pola do rozwoju. Powiedzmy, że mogłem rekrutować takiego frontowego juniora.

Wydaje mi się, że architekt ma najlepszy pogląd na to, co się dzieje w organizacji – tym bardziej jeśli to jest taki architekt, który siedzi w kilku projektów naraz. Wie, że w jakimś teamie brakuje na przykład kompetencji SEO – u nas jest taki przypadek – brakuje kogoś, kto mógłby pomóc u klienta ze stroną. My robimy aplikację, ale oprócz tego potrzebujemy takich kompetencji. Gdyby firma nie dostała ode mnie tego inputu: „kurczę, potrzebujemy takich kompetencji, nawet dwóch czy trzech osób i to na gwałt”, to mogliby rekrutować i poświęcać kupę czasu na ściąganie kogoś, kogo nie potrzebujemy. No, przykro mi, ale tak mogłoby być.

Architekt więc jak najbardziej powinien brać udział w rekrutacji – myślę, że jest to też dość powszechna praktyka. Nawet jeśli nie bierze udziału w rekrutacji (tak jak Scrum Master nie musi być na daily, tak architekt nie musi być na rekrutacji), to musi na pewno usteczniczyć w ustalaniu wytycznych. Firma, która ma jakiś plan na siebie, nie wrzuca tego samego ogłoszenia za każdym razem, tylko jest ono dostosowywane do tego, czego teraz potrzebujemy. Taki architekt musi w tym uczestniczyć.

To może jeden offtop. Mam osobę, która się przebranżawia z SEO na juniora front-end, więc może będziesz zainteresowany, więc podrzucę Ci potem kontakt.

Spoko, jasne, jak najbardziej!

Jakie umiejętności i wiedzę podczas rekrutacji sprawdza architekt?

Myślę, że tu powtórzę się z tym, co on miałby umieć jako junior, bo w końcu to, co musi umieć na rozmowie kwalifikacyjnej, to jest to, co on musi umieć podczas pracy.

To może na co zwracasz uwagę?

Dodam tylko, że to nie takie oczywiste, bo w sumie widziałem wiele rekrutacji, podczas których wrzucają juniorowi na przykład jakieś zadanie na złożony algorytm, a on ma potem poprawiać style na stronie. Więc w sumie może to nie jest takie jasne, ale moim zdaniem w idealnym scenariuszu rekrutacja powinna odwzorowywać warunki pracy – fajny byłby wtedy jakiś warsztat. U nas w DNA są robione właśnie takie warsztaty. Spotykamy się z kandydatem i robimy rozkminę.

Dajemy też zadanie domowe i patrzymy, jak to robisz – ale (ważne, żeby ludzie byli tego świadomi) bardzo często nie chodzi o to, żebyś zrobił 100% tego zadania, tylko żebyśmy zobaczyli, w jaki sposób myślisz. Jeśli czegoś nie zrobiłeś, to z czego zrezygnowałeś, gdzie ściąłeś zakręty? Bo to też jest ważne. Jeśli masz ograniczony czas pracy, to najzwyczajniej w świecie nie da się wszystkiego zrobić. Fajnie więc, jak ktoś pisze w zadaniu komentarze typu „wiem, że to jest źle, ale tego nie umiałem / już się spieszyłem / jeszcze tego nie robiłem / nie jestem pewien” – cokolwiek. Taki komentarz to dla mnie sygnał, że dana osoba potrafi powiedzieć, że czegoś nie umie.

Lipa jest trochę wtedy, gdy w pracy będziesz siedzieć dwa dni nad zadaniem i nie odezwiesz się do nikogo, że masz problem. A ktoś mógłby Ci w piętnaście minut dać rozwiązanie i szedłbyś dalej. Szybka nauka. A jak ktoś się boi powiedzieć, że czegoś nie umie, albo nie potrafi tego jasno zakomunikować, to tak naprawdę i sobie robi krzywdę, i projektowi, i firmie. Ponownie więc: taka transparentność jest super kluczowa.

Bardzo fajnie jest też, gdy ktoś wyśle maila i powie „nie rozumiem tego opisu”. Bo przecież to też nie jest tak, że klient daje Ci wymagania, a Ty siadasz i klepiesz kod. Czasami tak jest, ale na przykład nie u nas. My raczej stawiamy na to, żeby komunikować się z klientem i się upewniać, że na pewno zrobimy to, co on chce. Zawsze jak dostawałem jakieś zadanie, to myślałem, że to i tak za mało, że chciałbym o tym pogadać: czy to bardziej w taki sposób byłoby potrzebne, kto będzie użytkownikiem… Więc taka wymiana maili na przykład z rekruterem technicznym z punktu widzenia architekta jest bardzo na plus, bo widać, że ktoś ma szerszą perspektywę, a nie tylko chce siąść i zrobić coś tak, jak już się nauczył. Jest to taki pierwszy kluczowy etap rozmowy kwalifikacyjnej.

Drugi etap to pewnie będzie jakiś live coding albo spotkanie techniczne (u nas to warsztat, ale wiem, że to nie jest częsta praktyka). Wówczas też, jak nie wiesz, nie umiesz na coś odpowiedzieć, to powiedz: „nie wiem / nie umiem”. Nie musisz się tłumaczyć, masz prawo nie wiedzieć. Nie ma sensu kombinować i ściemniać. Jeśli rekrutuje Cię jakiś senior czy architekt, to on to i tak wyczai i to naprawdę nie wypadnie dobrze – że próbujesz go zbajerować. Na pewno dużo lepiej by wypadło, gdybyś powiedział: „sorka, nie wiem, idźmy dalej”.

Czy coś w wykształceniu lub doświadczeniu zawodowym juniora jest dla architekta oprogramowania szczególnie istotne?

Wiesz co, u juniora może być to o tyle trudne, że jego poprzednie doświadczenie dużo może nie powiedzieć. Wydaje mi się jednak, że fajnie mieć jakiś background, na przykład sprzedażowy, bo to pokazuje, że można mieć chociaż minimalnie rozwinięte umiejętności komunikacji. Ostatnio pisałem w artykule o rekrutacji, że dawno minęły czasy, gdzie można się było zamknąć w piwnicy z kapturem. Trzeba z klientem gadać, zrobić czasem jakieś demo. Więc gdybym takie coś zobaczył (doświadczenie w sprzedaży), to powiedzmy, że byłoby to na plus.

Ale chciałbym tu od razu podkreślić, że tak naprawdę nie patrzę już na takie doświadczenie. U developerów zerknę, OK (tak naprawdę, jak trafia do mnie CV, to jest już przefiltrowane przez rekruterkę), ale staram się tym nie sugerować. Pamiętam, jak jeszcze w Clearcodzie Marcin (...) (pozdrawiam) przyszedł do nas na rekrutację – to była pierwsza rekrutacja w moim życiu, którą miałem prowadzić – i nic w tym CV nie miał wpisane. Powiedziałem koledze z zespołu: „kurczę, ja tego nie widzę”, a on mówi: „poczekaj, czasami są takie czarne konie”. I faktycznie Marcin super sobie poradził, odpowiedział na więcej pytań niż jakikolwiek inny kandydat i był potem świetnym pracownikiem, który wniósł do zespołu megadużą wartość. Dostałem więc taką szybką lekcję, że na CV nie warto się za bardzo fiksować i lepiej dać się takiej osobie wykazać podczas rozmowy.

To może dodam taką jedną rzecz, którą właściwie sam wcześniej powiedziałeś: że była osoba z finansów, która bardzo Wam w projekcie pomagała. Może więc jest to element, na który warto zwrócić uwagę. Jak idziesz do fimry, która ma temat fintechowy, to jak jesteś z branży, masz łatwiej.

Można szukać po różnych branżach – w ten sposób łatwiej będzie Ci znaleźć pracę, bo znasz już temat. Jeśli masz pracować w banku, a wcześniej pracowałeś „na kasie w banku”, to też już jest duży plus, bo znasz zasady, jakie panują w banku i dużo łatwiej Ci potem zaprogramować aplikację.

Tak, dokładnie. Myślę, że przede wszystkim absolutnie nie można się wstydzić swojego doświadczenia. Trzeba być dumnym z tego, co się przepracowało – cokolwiek by to nie było. To może być praca na produkcji, budowie, w banku, jako lekarz – każda ma jakiś unikalny zestaw umiejętności, które musimy mieć. Warto wspomnieć o tym, czego się nauczyliśmy. Może nie wpisywać wszystkich rzeczy, które robiliśmy, ale to, jakich zestawów umiejętności na tych stanowiskach od nas oczekiwano. To może być akurat coś, co jest potrzebne i może sprawić, że rekruter (bo raczej rekruter będzie sprawdzał tego typu rzeczy) takie CV przepuści dalej do developerów.

Jaką wartość dla zespołu w oczach architekta oprogramowania ma junior?

Myślę, że przede wszystkim to, że junior wybija z rutyny. Nieraz jak pracowałem jeszcze z juniorami (teraz akurat w DNA juniorów nie mamy, ale w poprzednich firmach mi się to zdarzało), to bardzo podobało mi się, gdy ktoś był, powiedzmy, odważny (albo mniej, ale po prostu potrafił się odezwać – to nie musiało być na spotkaniu, ale później na Slacku). Taki junior, gdy przyjdzie, to nie ma kontekstu i nie jest przyzwyczajony do schematów, w które my już wpadliśmy, będąc w projekcie na przykład rok czy dwa. Może więc zadać Ci takie pytanie, że myślisz sobie: „o kurde, jak my w ogóle mogliśmy nie zwrócić na to uwagi?”. To świeże spojrzenie na problem jest super wartościowe i pozwala wprowadzić nową, nowatorską jakość do rozwiązań. Dlatego tym bardziej wracam do tego, co powiedziałem: warto zadawać jak najwięcej pytań, dzielić się swoim feedbackiem. Jeśli to nie będzie zasadne, to nie będzie, ale przecież tak naprawdę może być zasadne. Wydaje mi się, że to jest największą korzyścią współpracowania z juniorami.

Druga jest taka, że wielu ludzi chciałoby się sprawdzić w roli mentora. Może nie mają możliwości pracować w firmie szkoleniowej, a chcieliby to porobić sobie w pracy, więc tak naprawdę umożliwiamy komuś rozwój jego kariery i potem awans albo zwiększenie zarobków. Bo często od roli seniorskiej wymaga się tego, że taka osoba umie już wdrażać innych, że takie umiejętności przekazywania wiedzy ma, więc na kimś się musi nauczyć. Jest to więc też potencjalna wartość.

Korzyści finansowe z zatrudnienia juniora też firma może mieć. Zatrudnia kogoś za relatywnie niższą stawkę, a jak ktoś jest bystry, to firma ma przez jakiś czas takie okienko, że więcej na takim pracowniku zarabia – bo dealuje swojego klienta więcej, a pracownik jest tańszy.

Nie patrzmy więc na naszą rolę juniora tak, że ktoś nam robi łaskę. My też wnosimy do tej firmy wartość i warto tak na to patrzeć – jesteśmy wartościowym pracownikiem.

Mówiliśmy o blokerach i o poświęcaniu czasu na własne poszukiwania, a gdy one nie dadzą efektu, to dopiero wtedy powinniśmy iść do kogoś bardziej doświadczonego. Jakiej samodzielności w pracy z architekturą oprogramowania oczekujesz od juniora? Czy chcesz coś dodać?

Czasami widzę oferty dla juniora za 10-12 koła. Zastanawiam się, czego oczekują od ludzi na stanowisku juniorskim za takie pieniądze (były to zwykle jakieś javove stanowiska), ale wydaje mi się, że junior juniorowi nie równy. Gdy ktoś aplikuje na tego typu stanowisko, to jest takim juniorem, który pracuje na przykład rok, ma komercyjne doświadczenie i jest bardzo ogarnięty. Dlatego są takie stawki i od takiego juniora będzie się oczekiwać więcej.

Czasami firmy robią też taki przykry trick, że nazywają stanowisko juniorskim, żeby zaniżyć stawki, a oczekują nie wiadomo czego. Często widzę ten żal wylewany na grupach na Facebooku i też się tym ludziom nie dziwię.

Chcesz powiedzieć, że widzisz to, co trzeba umieć na stanowisko juniorskie i myślisz sobie: o, to chyba pasuje do mnie?

To idzie w dwie strony, wiesz? Widzę często oferty, które są normalnie juniorskie, i są tam widełki 3-5 koła. Rozumiem, że to nie są te wymarzone stawki, które ktoś miał w głowie, gdy myślał, że pójdzie do IT. Często ludzie będą przez chwilę zarabiali mniej, niż zarabiali w swojej dotychczasowej pracy. Ale są to nieraz zasadne stawki, bo jednak się uczysz. Nie robisz tego za darmo, to nie są jakieś psie pieniądze, choć wiadomo, że czasem możesz zarobić tyle samo w pracy, do której wchodzisz „z ulicy”.

Przy takich stawkach masz ten komfort, że ktoś faktycznie będzie prawdopodobnie chciał Cię nauczyć, nie oczekując, że będziesz umieć więcej niż absolutne minimum. Takie coś sugerowałbym osobom, które boją się presji i wolałyby pracować na spokojnie. Przy większości takich stawek, jeśli są niskie, to po trzech miesiącach możesz pójść na rozmowę i chcieć więcej. Wtedy oczywiście z większymi zarobkami idzie większa odpowiedzialność, ale skoro masz je dostać, to chyba sobie na nie zasłużyłeś.

Bardzo ciężko powiedzieć, na ile samodzielnym powinno się być. Myślę, że warto o takie rzeczy pytać. Dużo stresu może to kosztować, gdy ktoś się napali i będzie chciał tę pracę w końcu dostać – bo to nieraz jest dużo kasy wydanej na bootcamp, dużo godzin po pracy i chcesz wziąć cokolwiek. Znam jednak sytuacje, gdy ktoś poszedł do takiej pracy i kazali mu robić robotę kogoś, kto ma dużo większe doświadczenie i na przykład nawet nie mówić tego klientowi. Inny przykład: moja koleżanka robiła UX i też oczekiwali od niej pracy na poziomie mida czy seniora.

To generuje dużą presję, duży stres i trzeba sobie zadać pytanie, czy to jest tego warte. Może trzeba to przeboleć, zdobyć w takim miejscu doświadczenie i potem pójść gdzie indziej, ale ja bym po prostu pytał: czego będziecie ode mnie oczekiwać, czego oczekujecie ode mnie za trzy miesiące, pół roku i rok? Jak jest spoko firma, to często podaje to sama, ale warto o to zapytać, bo po pierwsze będziesz miał ścieżkę rozwoju w głowie i po drugie będziesz mniej więcej wiedzieć, czy jesteś w stanie coś takiego zrobić, czy to jest dla ciebie za duża presja. A może za mała i chcesz więcej? Ale przynajmniej będzie klarowna sytuacja.

To może jeszcze dopytałbym Cię o jedną rzecz. Wspominałeś przed spotkaniem o tym, do czego junior ma prawo. Było takie fajne stwierdzenie, które może chciałbyś dodać. Mówiłeś, że ma prawo się uczyć, ma prawo nie wiedzieć, pytać… To może już dokończę. Nikt od niego nie oczekuje poza nim samym – junior sam stwarza sobie presję, która powoduje, że praca nie daje mu tyle zadowolenia, ile by chciał.

Tak, to prawda. Słyszę to od kolegów. Widzę, że wkładają w pracę dużo serca, żyją nią. To wynika z tego, że są ambitni i są naprawdę fajnymi ludźmi. Dbają o to, że skoro ktoś im płaci, to chcą coś zwrócić.

Była na przykład taka sytuacja u mojego kolegi. Back-endowcy nie dowozili mu back endu, nie miał endpointów, nie umiał jeszcze tego mockować („udawać” serwera, by móc pisać front end bez dokończonego back endu) i mówił: „Ja wiem, że to nie jest moja wina, że to nie jest jeszcze gotowe, ale ja po prostu czuję presję, bo ta moja robota też nie jest dowieziona”. To trzeba zrozumieć – że jako junior ma się prawo nie wiedzieć, ma się prawo robić coś dużo, dużo wolniej (nie trochę wolniej, tylko dużo wolniej).

Ja miałem to samo. Zastanawiam się tylko, co mam takim ludziom poradzić. Bo to nie jest tak, że te osoby o tym nie wiedzą. Zwykle właśnie słyszę od nich, że „wiem, że sam sobie daje tę presję, ale i tak ją czuję”. Ja czułem dokładnie to samo. Pamiętam do dziś, jak mieliśmy pierwszą integrację, siedzieliśmy na piwie w Katowicach i mój manager powiedział: „Kurde, zobaczycie, że Radek kiedyś będzie ogarniał coś dużego, że mu się uda”, widział we mnie potencjał. Ja byłem tym totalnie, totalnie zaskoczony. Zdębiałem. Zawsze myślałem, że jestem największą zakałą teamu, najmniej umiem zrobić, po prostu tragedia – że prędzej mnie zwolnią niż powiedzą o mnie takie rzeczy. Patrzyłem na to, porównując się do seniora, który pracował już pięć lat, a nie z perspektywy osoby, która dopiero zaczęła i już na przykład szybko progresowała.

To, co bym zasugerował, to pytać o feedback – przyjść do swojego Project Managera, do swojego kolegi z zespołu. Można zrobić sobie taką formatkę w arkuszach Google i wysyłać anonimowo – bo może ktoś nie chce dawać feedbacku osobiście. Na internecie też są dostępne takie typowo feedbackowe formatki – co robię dobrze, co robię źle, co lubisz we współpracy ze mną, czego nie lubisz. Wtedy trochę nas to może uspokoić albo wskazać to, co może być usprawnione. Osobiście wolę jakąkolwiek krytykę, jakikolwiek feedback od domyślania się. Jak się będę domyślał, to wiadomo, że mózg świruje i dopowiadam sobie jakieś niestworzone scenariusze.

Myślę, że to rozwiązanie jest super – prosić o feedback. Pewnie ludzie dużo cieplej o nas myślą, niż sami sądzimy.

No, tak to się zwykle właśnie kończyło.

Pamiętajcie więc: warto robić takie rzeczy i tym się podbudowywać.

Jakiego typu zadania junior może spodziewać się od architekta?

Junior to może być ktoś, kto dopiero przychodzi do branży, ale też ktoś, kto na przykład jako back-endowiec ma zacząć robić coś frontowego. Po pierwsze więc architekt to nie jest osoba, która delegowałaby zadania. Myślę, że w dobrze działającej organizacji team developerski sam powinien ustalać, co chce wziąć na sprint. Ale architekt mógłby na przykład zasugerować takiej osobie, żeby robiła tzw. spike’i, czyli po prostu researche, które kończą się dokumentami, na przykład w Google Docs czy na Confluence, czy gdziekolwiek, gdzie można to spisać.

My na przykład mieliśmy ostatnio taki case, że trzeba było zrobić serwis do generowania dokumentów (faktur… obojętnie) – z front endu klikasz „download”, dane idą i robi się formatka. Jak się okazało, to nie jest takie trywialne, a rozwiązania gotowe albo są płatne, albo nie pozwalają się ładnie stylować. W takiej sytuacji zleciłbym juniorowi, żeby zrobił research, jakie są na rynku rozwiązania oraz jakie mają plusy i minusy. Taka osoba musi więc potem włączyć sobie filmik na YouTubie, przeczytać jakiś artykuł na Medium czy dyskusję na Stack Overflow.

Trochę to trwa, może to nie jest zawsze super fascynująca robota, ale to może bardzo, bardzo rozwijać, bo uczy po pierwsze szukać takich informacji szybciej i je filtrować, a po drugie przygotowywać feedback dla innych. Skoro junior będzie musiał spisać efekt spike’a (bo to musi być spisane, żeby reszta grupy miała tę samą wiedzę lub zbliżoną), to wymusza to, by research był porządnie zrobiony.

Tak jest też z uczeniem – jak uczysz ludzi, to łapiesz się na tym, że dogłębniej sprawdzasz temat, bo wiesz, że możesz być sprawdzony. Takie spike’i wydają mi się czymś, co jest z korzyścią dla zespołu i dla tej osoby. Teoretycznie nie wymagają nie wiadomo jakiego skilla, tylko chęci i umiejętności szukania.

Myślę, że przy takim researchu też dużo można się nauczyć, można znaleźć ciekawe tematy. Zabrzmiało to trochę jak zadanie teoretyczne, ale to może być też bardzo praktyczne – to zależy od tematu, jaki trzeba wyszukać, prawda?

Tak.

Czym junior może podpaść architektowi oprogramowania? 😉

Wydaje mi się, że nie tylko architektowi, ale ogólnie ludziom. Są dwa typy juniorów (śmiech): jedni przesadnie się boją, że są niewystarczający i podważają swoje kompetencje, a inni bardzo chełpią się tym, co już potrafią. Wydaje mi się, że to może wynikać z tych samych emocji – braku pewności siebie – tylko inaczej przekazywanych na zewnątrz: albo skrytością, albo próbą przykrycia tego przesadną pewnością siebie.

Sugerowałbym, żeby tej pokory trochę mieć. Gdzieś czytałem ostatnio takie fajne zdanie, żeby mieć w sobie tyle samo pokory, co ambicji. Staraj się, ucz się, pytaj, bądź aktywny – to jest wszystko super – ale też uszanuj to, że ta osoba, która robi coś już pięć lat i mówi Ci, że coś potrwa długo (może oczywiście mówić tak dlatego, że jest po prostu uparta itd., ale to mniejsze prawdopodobieństwo), to ona wie, jakie mogą tam czyhać na Ciebie pułapki, wie, że to jest złożony problem. W takiej sytuacji nie drąż i nie dyskutuj, tylko zatrzymaj się, powiedz „OK, rozumiem”, sprawdź sobie to i dopiero potem wróć z feedbackiem, że na przykład można to zrobić szybciej. Tylko znowu: żeby to nie było na zasadzie udowadniania, że „ja ci pokażę”. Wydaje mi się, że takie zdrowe podejście jest kluczem, a jego przeciwieństwo to coś, czym najłatwiej jest podpaść.

Dodam też, że w większość firm, w jakich pracowałem (jak nie we wszystkich; dużo firm też to deklaruje, choć to mogą być tylko deklaracje), o wiele chętniej zatrudniano ludzi, którzy zachowywali się fajnie podczas rozmowy, z którymi chcielibyśmy współpracować, z którymi byśmy się dogadali. Te osoby nie muszą się płaszczyć i wchodzić w tyłek – to nie o to chodzi. Są po prostu przyjazne, otwarte na feedback, komunikatywne, a nie takie, które chcą wszystkim pokazać, że są najmądrzejsze. Jeśli więc dasz trochę ciała na zadaniu technicznym, to się nie przejmuj. To może być tak naprawdę kompletnie zapomniane, jeśli wypadniesz spoko z tej miękkiej strony.

Czego junior powinien oczekiwać od architekta oprogramowania?

Myślę, że jako junior bardzo bym chciał, żeby mi ktoś wytyczył ścieżkę rozwoju. Teraz jest to trochę prostsze. Nie chcę mówić, że „za moich czasów”, bo to też nie było jakoś strasznie dawno temu, ale mimo wszystko w ciągu kilku lat jeśli chodzi o edukację sporo się zmieniło. Ja zaczynałem na Eduwebie, kupiłem tam parę kursów: Backbone.js, JQuery… Tak naprawdę nie bardzo wiedziałem, czego opłaca się uczyć, a to przecież trochę trwało.

Gdy się zatrudniłem, wykazywałem raczej taką proaktywną postawę – wolałem wziąć coś w swoje ręce i się uczyć. Ale z mojej perspektywy bardzo fajne byłoby to, gdyby ktoś przyszedł i powiedział: „U nas w firmie potrzebne jest, żebyś umiał to”. Mnie się sto razy łatwiej uczy, gdy wiem, że to ma jakąś wartość. Jeśli mam się czegoś uczyć na zapas albo dlatego, że mi się tak spodoba, to bardzo szybko tracę motywację. A jak klient przyjdzie i powie mi: „Kurde, mega potrzebujemy takich i takich umiejętności”, to ja mam dziesięć razy większą motywację, bo wiem, że po pierwsze robię coś, co jest pożyteczne, a po drugie to jest też dla mnie karta przetargowa przy negocjacjach wynagrodzenia lub przy awansie: potrzebowaliście kogoś, kto to zrobi, ja to zrobiłem, jestem elastyczny.

Na pewno więc poszedłbym do architekta i poprosił o to , żeby mi powiedział, jakich technologii się w firmie używa i których najczęściej. Fajne, szczególnie chyba z perspektywy juniora, jest pytanie o to, z jakimi technologiami klienci dopiero przychodzą. Jak jest jakiś lead albo potencjalny klient, to zanim on podpisze umowę i zanim wystartuje projekt, to może minąć parę miesięcy. Może się okazać, że wszyscy w firmie pracują w Reakcie, a on potrzebuje coś we Vue. Jak zapytasz o to architekta, a on Ci powie, że ma akurat sporo zapytań o Vue albo Angulara (albo cokolwiek), to możesz powiedzieć: „Dobra, to ja już teraz siadam i się tego uczę”.

Za trzy miesiące wchodzisz do tego zespołu i tak naprawdę możesz firmie uratować kontrakt. Bo mogliby nie mieć zasobów ludzkich do tego, żeby obłożyć taki projekt, a ty im wskoczysz i nie tylko opłacisz swój etat, ale też na przykład pięć innych, które byłyby zwyczajnie nieutylizowane w tamtym czasie. Myślę, że to by było fajne biznesowe podejście i pokazanie, że jest się pracownikiem myślącym o biznesie firmy.

Często się słyszy, że architekt to też w jakimś sensie mentor. Czy architekt jest w stanie znaleźć na to czas? I czego junior ma szansę nauczyć się od architekta prócz tego, co już powiedziałeś?

Czy ma czas…? To zależy. Jeśli to jest taki architekt, który jest w zespole, to wydaje mi się, że nie ma on takiej bieżącej pracy na co dzień – że ma wypchany backglog. Programista często ma długi backlog i jak mu się skończy robota, to może sobie coś w sprincie dobrać, na przykład refactor, style do poprawy, które trzeba było zrobić, ale do tej pory nie było czasu. On zawsze ma co robić. A ze strony architekta to nie jest tak, że codziennie musi podejmować decyzje architektoniczne, codziennie rozkminić nowy produkt czy jakąś nową gałąź, więc potencjalnie miałby czas na mentorowanie ludzi.

Chociaż może to być też tak, że architekt – jako że jest to czasem rola ad hoc, na żądanie – jesteś przerzucany między wieloma teamami. Jeżeli tak to wygląda, to wtedy rzeczywiście nie masz czasu, żeby usiąść i mentorować. Ale u nas na przykład w DNA jest tak, że rusza teraz program mentoringowy i ktoś, kto chce się sprawdzić w tej roli, ma do tego okazję. Jeśli w firmie jest czas na self developement, to możesz go poświęcić na mentorowanie kolegi z pracy. A ktoś inny może Ciebie mentorować z czegoś innego. Więc potencjalnie ten czas jest.

Drugie pytanie było odnośnie do tego, czego jeszcze junior może oczekiwać?

Tak, odnośnie do przekazywania wiedzy.

Ostatnio w podcaście Taby vs spacje była o tym mowa także w kontekście architektury – że to nie tylko ustalenie, z jakich komponentów coś się składa, jaka jest struktura katalogów, jak komunikują się serwisy czy jakiekolwiek inne elementy, ale też na przykład przygotowanie dokumentacji i dzielenie się wiedzą w organizacji. To też jest składowa architektury i w sumie wybrzmiało mi to w głowie dość mocno. Zgadzam się z tym, że architekt dba o to, żeby wszystko działało, robi tak, żeby to wszystko „było dobrze”, jak to się często mówi.

Taki junior może więc od architekta oczekiwać właśnie tego, żeby wiedza ze spotkań czy ustalenia biznesowe były transparentne, bo on wtedy nie musi być na tych wszystkich spotkaniach, co architekt. Może mieć za to wyciągnięte z tego samo to tzw. mięsko i też być potem bardziej świadomym pracownikiem, lepiej rozumieć potrzeby swojej firmy, potrzeby klienta. Architekt nie musi tego pisać sam, ale powinien dbać o to, żeby tworzenie dokumentacji było kultywowane i żeby było to robione w ramach jakichś dobrych praktyk.

Gdyby junior developer chciał zostać architektem oprogramowania, to co byś mu doradził?

Pamiętam, że ja dość szybko wskoczyłem na rolę architekta, bo pierwszy raz miałem okazję to robić po trzech latach pracy w zawodzie – takiej etatowej. Zawsze mam problem, czy liczyć te czasy freelancingu, czy nie. Było to jakieś doświadczenie, bo musiałem gadać z klientami, ale to nie było aż takie obłożenie czasowe jak na etacie. Powiedzmy więc, że nie licząc tego, to po trzech latach.

Czułem, że to jest za szybko. Ja tę rolę w Clearcodzie porzuciłem po roku jej sprawowania. Oczywiście dostawałem pozytywny feedback. Znów może było to złe podejście z mojej strony, bo miałem nawet potem testować jeszcze inną rolę w firmie, tak naprawdę wyższą, ale zrezygnowałem z tego, bo sam czułem, że to jeszcze nie był ten etap.

Chociaż spełniałem te oczekiwania, które były przede mną stawiane, to wymagało to ode mnie bardzo dużo stresu. Każde zadanie było obarczone tym, że musiałem się tego nauczyć. Nie było tak, że masz 30% nowych rzeczy i 70% takich, które umiesz. Oczywiście dostałem super szansę, za którą jestem mega wdzięczny, mega mnie to rozwinęło, ale to była moja decyzja, żeby w to wejść i moją decyzją było to, żeby zrezygnować.

Zacznę więc od tego, że to nie jest prosta sprawa i nadal uważam, że jeszcze wszystko przede mną. Powiedzmy, że mam ten tytuł i takimi rzeczami się zajmuję, ale wiem, że są ludzie, którzy mnie po prostu zjadają. To jest złożone. Powiedziałbym więc, żeby się nie spieszyć. Każde pójście na skróty to nie jest zbyt dobry pomysł.

Wiadomo, że lepiej się uczyć na swoich błędach. A może nie błędach? Bo może ktoś ma do tego smykałkę i urodził się z takim potencjałem, że poszłoby mu to gładko i to woli. Trzeba się też liczyć z tym, że ta rola to trochę również odcięcie od kodu i skupienie się na architekturze i biznesie.

Po pierwsze: trzeba uczestniczyć we wszystkich spotkaniach. I nie tylko uczestniczyć, ale uczestniczyć bardzo aktywnie i robić notatki. Nie może być tak, że jako architekt pójdziesz na spotkanie, klient Ci powie, czego potrzebuje, a Ty potem zapomnisz, bo nie zrobiłeś notatek – i zrobisz architekturę, która nie uwzględnia czegoś kluczowego. Jest to więc mega ważne – żeby mieć ustrukturyzowaną pracę z wymaganiami klienta, żeby być na spotkaniach. Jeżeli to Cię będzie jarać, a nie nudzić, to spoko. Jeżeli to będzie Cię nudzić i męczyć, to jest to sygnał, że może niekoniecznie warto iść w tę stronę. To nie musi być stały kierunek, w którym idziesz. Ale jeżeli byłby to fun, to takie coś proponuję.

Przede wszystkim jest to jeszcze zakomunikowanie tego ludziom, którzy są nad Tobą, którzy zdecydują o Twojej ścieżce kariery – typu Project Manager. Wydaje mi się, że tę szansę dostałem dlatego, że jasno o tym mówiłem: że jara mnie ta praca, że to moja pasja, że jestem ciekaw, co jest dalej. Nawet jeżeli się super angażujesz i myślisz, że ktoś to zauważy i Ci tę szansę da, to ktoś może nie wiedzieć, że Ty jej chcesz. Nie czekajmy więc, aż ktoś się domyśli, tylko po prostu powiedzmy: to mi się podoba, chciałbym to robić. Może ktoś da Ci na talerzu ścieżkę, którą musisz przejść, żeby to ogarnąć.

W Bolderze (też bardzo fajna firma, pozdrawiam) mają coś takiego jak ścieżka przyspieszonego rozwoju, na przykład z mida na seniora. Wydaje mi się, że tam, jak zgłosisz chęć, to dostajesz plan rozwoju, gdzie w krótkim czasie (już teraz nie pamiętam dokładnie w jakim) przeskakujesz do przodu. Napisałem nawet o tym post na LinkedInie i też się włączyłem do dyskusji, bo jest to kontrowersyjne. Nie wiem, czy da się tak bardzo przyspieszyć ilość doświadczenia, ale da się zdobyć dużą wiedzę i potem już tę wiedzę wykorzystywać w praktyce.

Wydaje mi się, że to też nie jest tak, że kogoś wrzucą na głęboką wodę, tylko że będzie jakieś wsparcie itd. Pokazuje to, że w dojrzałych organizacjach, które starają się dawać ludziom szansę do rozwoju, wystarczy przyjść, powiedzieć i taką szansę się dostaje.

Ale tutaj super rozwinąłeś temat. Tak jak mówisz: nie bierzmy za dużo na siebie, bo potem możemy tego żałować i się zniechęcić.

Jaką książkę polecisz osobie, która chce podszkolić się z architektury oprogramowania?

Szczerze mówiąc, mam taką jedną książkę Czysta architektura. Kiedyś po roku czy dwóch pracy miałem rekrutację na stanowisko seniora, gdzie w ofercie było napisane, że mocno oceniana będzie architektura. Kupiłem więc tę książkę w Helionie, otworzyłem, przeczytałem 5-10 stron… To była męczarnia. Parę razy do niej wracałem i mi to nie siadło.

Wrócę do niej teraz, bo by wypadało, ale komuś, kto dopiero interesuje się takim tematem raczej poleciłbym zaczęcie od czegoś bardziej przystępnego, ogólnie o praktykach pracy w IT: Mistrz czystego kodu Roberta C. Martina (Uncle Boba). Książka mówi o tym, jak postępować. Nie trzeba się tam ze wszystkim zgadzać. Jest tam na przykład stwierdzenie, że na pracę trzeba poświęcić 60 godzin w tygodniu: 40 na pracę i 20 na naukę. Według mnie to jest dużo, nie każdy może sobie pozwolić, jak ma rodzinę i inne zajawki. Ale mimo wszystko jest to jakiś drogowskaz – jak ludzie bardzo ambitni, którzy chcą być na najwyższych stanowiskach, podchodzą do pracy. Część z tego można wyciągnąć dla siebie.

Jak tę książkę czytałem, to odniosłem wrażenie, że pokazuje ona, że warto mówić „nie”. Tak to odbierałem, nie wiem, czy się zgodzisz.

Tak, to jest taka umiejętność, której juniorzy na początku mogą nie mieć. Jeżeli się odnosisz do takiego czegoś jak zwiększanie scope’u lub branie kolejnych tasków do sprintu, to tak: trzeba umieć mówić „nie”.

Tak, trzeba umieć, ale tego też trzeba się nauczyć. Chciałeś jeszcze coś dodać?

Tak, jest jeszcze Pragmatyczny programista. To też bardzo fajna książka, która zawiera dużo takich ciekawych prawd o tym, jak rozwój oprogramowania wygląda, w jakie pułapki myślowe wpadamy. Myślę, że warto po nią sięgnąć. I jest w miarę przystępna.

I chyba nawet ostatnio było dziesięciolecie. Co ciekawe, w IT to bardzo dużo. Ale akurat ją też miałem w rękach i ta książka fajnie pokazuje, jak to się wszystko rozwijało. Jest parę naleciałości z tych dziesięciu lat, które ja akurat pamiętam, ale to fajnie też pokazuje, jak to wszystko się rozwija.

Ale wydaje mi się, że wyszła teraz też odświeżona wersja – z nową okładką i chyba zaktualizowana.

Tak, ale też widać, że niektóre rzeczy są jak gdyby ciągle takie… że tak powiem „starsze”.

Kumam.

Gdzie możemy Cię znaleźć w sieci?

Głównie można mnie znaleźć na LinkedInie. Tak dwa czy trzy razy w tygodniu wrzucam posty, jak wygląda praca w IT, z jakimi trudnościami się ludzie spotykają, ale też takie typowo techniczne sprawy: jak pracować z CSS-em, Reactem itd.

Na grudzień szykuję ciekawy cykl – taki kalendarz adwentowy – więc jak ktoś wpadnie, to się załapie na małą, fajną porcję wiedzy codziennie aż do świąt.

To super, to zapraszamy na LinkedIn do Radka. Będzie się działo. A Tobie dziękuję za rozmowę i podzielenie się z nami swoimi doświadczeniami.

Ja również dziękuję, naprawdę fajnie było wystąpić.