To jest 66. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o roli regular developera. 

Przypominam, że w poprzednim odcinku rozmawiałem o zastosowaniu chmury w biznesie. 

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/66

Jeśli jeszcze tego nie zrobiłeś, to wystaw ocenę lub recenzję podcastowi w aplikacji, w której teraz tego słuchasz. 

Chcę poszerzać horyzonty ludzi z branży IT i wierzę, że poprzez wywiady takie jak ten, publikowane jako podcasty, będę to robił z sukcesem.

Nazywam się Krzysztof Kempiński i życzę miłego słuchania!

Odpalamy!

 

 

Cześć, mój dzisiejszy gość to doświadczony inżynier oprogramowania, specjalizujący się głównie w aplikacjach webowych. Występuje z prelekcjami i prowadzi warsztaty z Domain-Driven Design, TDD i programowania obiektowego. Fan dobrych książek, na co dzień pracuje w firmie DocPlanner. Moim i Waszym gościem jest dzisiaj Patryk Woziński.

Cześć, Patryk! Bardzo mi miło gościć cię w podcaście.

 

Cześć, Krzysiu! Super, że udało mi się do ciebie wpaść. Bardzo się z tego cieszę.

 

Z Patrykiem porozmawiamy sobie o takiej roli, o której, mam wrażenie, mówi się najmniej.

Dużo mówimy o roli junior developerach, czasem mówi się też trochę o senior developerach. Natomiast pośrodku jest jeszcze pole do zagospodarowania, czyli można powiedzieć, rola regular developera, niektórzy nazywają ją mid developerem. 

Coś, co jest takim terenem, o którym się trochę mniej mówi. Rola regular developera będzie tematem naszej dzisiejszej rozmowy.

Żeby tradycji stało się zadość, to muszę zapytać cię o to, czy słuchasz podcastów i jeśli tak, to jakich najczęściej?

 

Tak! Słucham podcastów. Na pewno znajduje się tutaj pozycja, która jest ci dosyć dobrze znana, czyli właściwie twój podcast! 

 

Dzięki! [śmiech]

 

Przypomniała mi się historia, kiedy wracając z pracy słuchałem Twojego podcastu, padło to pytanie i ktoś zareagował podobnie jak ja. 

Poza twoim podcastem słucham No Kill Switch — jest to podcast Sebastiana Gębskiego. Właściwie to on zaraził mnie Elixirem, bardzo ciekawe rozważania Sebastiana na temat i życia, i samej branży. Fajnie sobie posłuchać i przemyśleć co ten człowiek ma do powiedzenia. 

Poza Sebastianem słucham też Allegro Tech. Tutaj jest bardzo szerokie spektrum tematów. Warto wybrać coś dla siebie i naprawdę jest to coś całkiem fajnego. 

Poza Allegro zostaje jeszcze ostatni podcast, którego słucham — jest to biznes w IT, bo czasami o biznesie też fajnie posłuchać.

 

Jasne. Czasami trzeba też tę drugą stronę zobaczyć, żeby być lepszym developerem.

Dzięki za podzielenie się podcastami, które słuchasz. 

Na początku chciałem zapytać Cię o to, czy granica pomiędzy rolą juniora, później vice developera, dalej seniora jest w jakiś sposób ostra — czy da się w ogóle w jakiś sposób zdefiniować te role i je określić na tyle, żebyśmy wiedzieli, kiedy już przechodzimy do tej innej roli a zostawiamy poprzednią? 

Czy myślisz, że istnieje takie dosyć mocne odcięcie i jednoznaczne określenie tych właśnie ról, o których się najczęściej mówi? 

 

Wydaje mi się, że nie można tego określić zero-jedynkowo. Stanowisko, czy rola w zespole, jaką pełnimy, jest bardzo zależna od wielu, różnych aspektów. I to wszystko bardzo mocno zależy od firmy, w której się znajdujemy, bo znajomość biznesu i znajomość funkcjonalności, które rozwijamy, bardzo duży wpływ ma na stopień, który w danym środowisku mamy.

Wszystko zależy od firmy, naszego mindsetu. Czasami ktoś, kto potrafi szybko się uczyć, dużo szybciej wyciągnie coś przydatnego dla siebie niż osoba, która przez wiele lat siedzi w jednej, konkretnej firmie i po prostu jest, po prostu rozwija funkcjonalności czy naprawia błędy. 

 

Właśnie. Często mam wrażenie, że to jest interpretowane w ten sposób, że zaczynamy pracę jako junior, awansujemy później do roli pośredniej, mid developera po to, żeby na końcu skończyć z rolą senior developera.

Pokazuje to nam taką drabinkę, definiuje ścieżkę kariery, którą podążamy. Chciałem zapytać, czy regular developerem można się stać raz na zawsze? Czy to jest taki badge, który gdzieś tam sobie uzyskaliśmy i już na zawsze będziemy tym regular developerem, czy może jest to bardziej płynne i zależy od innych rzeczy?

Jestem ciekaw, jakie masz zdanie na ten temat. 

 

Moim zdaniem regular developerem nie można się stać raz i pozostać nim na zawsze, bo rynek, technologia bardzo się zmieniają, o czym przykładowo świadczą biblioteki java scriptowe, które dość szybko zostają wypuszczane na rynek. 

Właśnie — regular developer. Chodzi o to, żeby robić continuous learning. Nazwałbym to w ten sposób. Czyli cały czas się uczymy. 

Nie jest tak, że dostaniemy jakieś stanowisko, jakąś rolę i jesteśmy nim już do końca życia, bo przez jakiś czas po prostu wejdą nowe metodyki pracy, nowe technologie i później nasza wiedza może stać się już trochę przestarzałą. Można się po prostu zasiedzieć!

Poznałem wiele osób, które niestety wpadły w ten wir. Nauczyli się konkretnych rzeczy, osiedli na konkretnym stanowisku czy to regular developera, czy też wyżej, bo nie ma to już większego znaczenia. Ci ludzie niestety przestali się rozwijać. Stwierdzili, że jest to już dla nich idealna pozycja, osiągnęli to, czego chcieli i mogą zająć się na przykład wędkowaniem.

Z czasem ta wiedza przestaje być taka świeża i w pewnym momencie, kiedy jesteśmy w tej firmie dłużej, trochę zasiedzeni, to może chcielibyśmy zmienić pracę. Fajnie — jesteśmy regular developerem, nie będzie jakoś super trudno. 

Szukamy na rynku pracy, są różne oferty, śmiało aplikujemy — wychodzi coś, czego się nie spodziewaliśmy wcześniej: aktualne wymagania na rynku pracy są całkowicie inne, niż nasz skill set i nasza rola była zależna od wiedzy o systemie, w którym pracujemy, zamiast tym, co potrafimy.

Niestety — wydaje mi się, że regular developerem nie zostajemy na całe życie.

A Ty co o tym, Krzysiu, myślisz? 

 

Myślę, że definiuje to, jakie umiejętności posiadamy i oczywiście sami siebie możemy nazwać senior developerem, możemy wstawić sobie taki tagline na LinkedInie.

Natomiast to powinno wyglądać w drugą stronę: to rynek, pracodawca, być może nasi koledzy powinni nas określić i zdefiniować w ten sposób, bazując na tym, co w danej chwili potrafimy, co wnosimy też w danej firmie, środowisku.

Według mnie bardzo trudno jest zdefiniować jednoznaczny schemat, że powiedzmy  regularem stajesz się wtedy, jeśli opanowałeś dokładnie to, to i to, a jeśli jednej rzeczy nie potrafisz to nie możesz się nazywać regularem.

Jest to dosyć płynne i tak jak na początku powiedziałeś, zależy od wielu zmiennych środowiskowych, w środowiskach, w których się znajdujemy. 

Według mnie jednym z takich elementów, który na to wpływa, jest staż pracy. Jest to ile czasu w danej firmie pracujemy, nad danym projektem. 

Chciałem cię zapytać, czy według ciebie to, że 10 lat siedzimy w jakimś projekcie, znamy go już na wylot, wiemy o wszystkich zależnościach, które tam występują — czy jest to wystarczający element, żeby nazwać nas seniorami, regularami. Żeby określić nas jakimś stanowiskiem.

Czy też może, niestety, może dojść do tego ostatnio często powtarzanego hasła o tym, że mamy rok doświadczenia powtórzony 10 razy i to w żaden sposób nie wpływa na to, że osiągnęliśmy jakiś tam mityczny status, mityczną wiedzę?

 

Co o tym myślisz? 

 

Wydaje mi się, że często jest to w ten sposób interpretowane. Widzimy w jakimś ogłoszeniu o pracę informację, że wymagane jest 5, 6 lat doświadczenia. 

Moim zdaniem doświadczenie to jest coś zupełnie innego niż staż pracy. Doświadczenie to inaczej… Coś doświadczać! Nowych rzeczy, nowych zjawisk i tego wszystkiego się uczyć. 

Staż to jest po prostu przeklepanie czegoś przez ileś lat, ileś miesięcy — dokładnie tak, jak powiedziałeś i niestety w wielu firmach, wielu branżach jest tak, że wymagany jest konkretny staż, co niestety nie przekłada się też na umiejętności.

Każdy zna ludzi, którzy w konkretnym miejscu przesiedzieli bardzo dużo czasu. Trochę się zasiedzieli, przez co ich doświadczenie może być tak jak dokładnie powiedziałeś: 10 lat powtórzonego tego samego. 

 

Wobec tego spróbujmy może w jakiś sposób zdefiniować lub określić, kiedy osiągamy już ten poziom mid developera. Po części zasugerowałem, że nie ma jednoznacznego, wszędzie spotykanego szablonu, miary, która powie, że teraz jesteś mid developerem. 

Spróbujmy się może zastanowić, co definiuje tę pozycję? Kiedy mniej więcej my i nasze środowisko wie, że może nas tytułować taką rolą. Czy to według Ciebie rynek pracy, nasz pracodawca, czy też może zestaw umiejętności może najlepiej zdefiniować ten poziom i określić, że: okej, teraz już jesteś mid developerem!

 

Wydaje mi się, że nie możemy tak jednoznacznie określić, kiedy jesteśmy taki mid czy regular developerem. Super narzędziem do określenia czegoś takiego jest czasami znany nam OID. Wybieramy sobie cele, do których chcemy dążyć, zbieramy wskaźniki, które będą nam wskazywać, w jakim stopniu się czegoś nauczyliśmy i zbieramy zadania, które pozwolą nam do tego celu dążyć. 

Taki OID jesteśmy w stanie zbudować sobie z naszym mentorem, jeżeli takiego nie mamy — jeżeli nie, to należy go znaleźć, bo mentor świetnie boostuje naszą karierę i umiejętności. 

Mając taki OID jesteśmy w stanie konkretnie widzieć cele, które chcemy osiągnąć. Czyli na przykład: chcę osiągnąć umiejętność pisania testów. Więc jednym ze wskaźników będzie to, że 80% napisanego przeze mnie kodu będzie napisane podejściem test-driven development, czyli jasno jest powiedziane co, w jaki sposób i mamy tę konkretną umiejętność, w jakiś sposób opanowaną.

Tak samo ten zbiór różnych umiejętności możemy zebrać właśnie w taki zestaw, który powie nam: okej, jeżeli to wszystko opanowałeś to w swoim mniemaniu, czy twojego mentora jesteś już właśnie tym regularem.

Do tego wszystkiego dochodzi oczywiście też kontekst firmy. Nie znając branży pożyczkowej, w firmie, która tworzy jakiś system nie jesteśmy seniorem przychodząc z zewnątrz i nie mając doświadczenia. Musimy posiąść wiedzę o tej domenie, zrozumieć to i wtedy dopiero jesteśmy w stanie wskoczyć na jakieś konkretne stanowisko. 

Czyli właśnie ten kontekst firmy. Wydaje mi się, że to jest bardzo ważne i nie należy o tym zapominać, a poza tym cały czas pamiętajmy o OID-ach, o przygotowaniu ich i dążeniu do konkretnych celów. 

 

W ogłoszeniach o pracę często widzimy nagłówki typu regular java script developer, mid PHP developer. Bardzo często jest to jakiś kontekst konkretnej technologii. Rzadko spotykam takie ogłoszenia, które mówią, że poszukujemy mid developera, niezależnie od technologii.

Sugeruje to, że może istnieć jakiś zestaw wiedzy, umiejętności twardych, które trzeba posiąść, żeby w danej technologii być postrzeganym, być nazywanym regular developerem. 

Zastanawiam się — to oczywiście jest różne dla każdej technologii. Wiadomo, że dla języków funkcyjnych będzie to coś zupełnie innego, niż obiektowość dla frontendu. Co innego niż systemów baz danych i tak dalej. 

Natomiast bardziej interesuje mnie, czy istnieje według ciebie taki zestaw umiejętności twardych, ale niezależnie od technologii, z których korzysta się w dzisiejszych czasach, którą według ciebie każdy regular developer powinien w toolboxie posiadać. 

 

Na ten temat jest wiele do powiedzenia. Można drążyć. Niestety, często jest to zapominane. Umiejętności junior developera — okej, jesteśmy jakoś w stanie określić, na przykład potrafi on posługiwać się jakimś podstawowym frameworkiem, czy zna jakiś system, który umożliwia nam persystencję, jakiś ORM, czy cokolwiek. 

Właśnie, jeżeli chodzi o mid developera, to jest pomijane. Juniorzy, którzy się uczą, nie wiedzą do końca, czego się uczyć, żeby wskoczyć o jedno oczko w hierarchii. Wtedy junior, wracający z konferencji, stwierdza, że dobra, domain-driven design, micro serwisy, to jest to! Teraz będę się tego uczył! 

Trochę nie. Wydaje mi się, że bardzo fajnie jest posiąść wiedzę na temat samego paradygmatu. Zrozumienie, czym jest programowanie obiektowe czy programowanie funkcyjne to jest tak naprawdę ogromna rzecz, ogromna wiedza, która przyda nam się na zawsze i niezależnie, czy będziemy pisali w Erlangu, pisali w Javie czy czymkolwiek, to ta wiedza będzie cały czas świeża i cały czas będzie nam dawała bardzo dużo. Do tego, jeżeli jesteśmy sobie takim programistą języka obiektowego, na przykład Javy, to fajnie jest poznać też ten drugi paradygmat. Poznać, jak to się wszystko robi, z czym to się je w takiej skali. Jak to tam wygląda? Otwiera nam to trochę oczy i daje trochę szersze pole widzenia. 

Poza samym paradygmatem coś, co jest bardziej oczywiste, ale niestety o tym dalej zapominamy, czyli właśnie design patterns: czyli wzorce, zrozumienie wzorców. Nie chodzi o podręcznikowe wykucie się tego, tylko zrozumienie co nam to daje. Co umożliwia. Dzięki konkretnemu wzorcowi, co jesteśmy w stanie zrobić. To bardzo przyspiesza development jakiegoś systemu czy rozwój nowych funkcjonalności. Poza wzorcami kolejna rzecz, którą warto sobie przyuczyć, to testy. Testy nigdy nie wyjdą z mody, zawsze warto je poznać, zrozumieć, a jeżeli chodzi o testy jednostkowe, to tu jest bardzo dużo do zrobienia, dużo do nauczenia. Wydaje mi się, że osoba, która zrozumie jak pisać dobre testy, nauczy się też pisać dobry kod. Dzięki temu bardzo szybko zrozumie dużo nowych, ciekawych rzeczy a same testy później mają fajny przekład na to, jak budować system, jak budować architekturę systemu, bo na przykład tworząc te testy zauważymy, że jesteśmy w momencie: o nie, teraz nie mogę zrobić kolejnego kroku, bo nie da się napisać tego testu!

Co to znaczy? To znaczy, że coś jest nie tak z designem tego kodu. Tak naprawdę więc test powiedział nam, że coś skopane jest na poziomie architektury czy po prostu designu jakiegoś obszaru, więc totalnie warto się tego nauczyć, tak samo, jak zrozumienie piramidy testów i tego, że nie jest to też zero-jedynkowe. Dla systemów ze złożonym zapisem to piramida jest taka, że piszemy dużo jednostkowych. 

Co w systemie skomplikowanego odczytu, gdzie nie mamy czego testować jednostkowo? Tam piramida się nam odwraca. Zrozumienie tego wszystkiego, jak działają testy, kiedy i ile ich pisać, bardzo dużo nam daje. Jedna rzecz, która moim zdaniem warto praktykować: object calisthenics. To jest zbiór zasad, dzięki którym możemy pisać tak hardcorowo, fajnie obiektowy kod. 

Czasami są to ciężkie zasady i nie jest łatwo ich wszystkich przestrzegać, ale robiąc takie ćwiczenia w domu czy rozwiązując jakieś domowe projekty, to bardzo dużo się nauczymy. Dużo nauczymy się o projektowaniu jakiegoś kodu i tutaj wchodzi znowu zbiór zasad GRASP, który — jak Mariusz Gil powiedział podczas swojej prezentacji. Mariusz Gil, znany ze świata PHP-owego przede wszystkim, powiedział, że GRASP nie jest prawie w ogóle googlowany. Googlowane są mikro serwisy, które są wokół tego całego hype-u, a te rzeczy, które są u podstaw, które dają nam najwięcej, tak naprawdę pomijamy. 

Wiele osób pomija temat samego GRASP-a, jako takiego zbioru zasad. Nie wiem, jak podchodziłeś do nauki Elixira, bo mam tu pewną sugestię. 

 

Lubię się uczyć nowych technologii w praktyce, więc mam taki patent, który stosuję, żeby najpierw ogólnie przejść przez albo książkę, albo dokumentację bez założenia, że muszę wiele z tego wynieść. Raczej chcę mieć taki obraz sytuacji. Chcę też zobaczyć sobie jakieś dobre praktyki. 

Właściwie później, w momencie, kiedy już mniej-więcej wiem o co chodzi, zaczyna rozwiązywać konkretny problem, wówczas drążę te tematy, które są mi w danej chwili potrzebne. Uważam, że nie ma sensu aż tak dużego, zwłaszcza w tak szybko zmieniającej się branży uczyć się dużo rzeczy do przodu, na wyrost. Jestem raczej fanem takiego just-in-time learning. Jeśli czegoś potrzebuję, to się tego uczę. Jeśli nie potrzebuję, to zapominam. 

Takie mam podejście.

 

Okej, to jest na pewno jedno z wielu bardzo fajnych, bardzo pragmatycznych podejść. 

Bardzo fajną metodą, która nawet tobie sugeruję przy poznawaniu nowych rzeczy, jest coś takiego, czego nazwę poznałem dopiero niedawno na portalu Dev2 – test driven learning. 

Ucząc się Elixira, bo właściwie to jest jakiś temat, który nas też łączy to podszedłem do tego w taki sposób, że sprawdziłem, jak działają sekcje, jak działają testy w Elixirze, bo jak wiemy to jest język, który bardzo fajnie wspiera testowanie. 

Zacząłem więc od testów. Napisałem je, później stwierdziłem: chcę jakąś zmienną. Co teraz? Napisałem test, który sprawdza, czy coś się ustawiło jako konkretną wartość i test się nie powodził. Nie powodził, dlatego że nie potrafiłem zaimplementować jeszcze zmiennej czy czegoś podobnego.

Wtedy musiałem doczytać jak to zrobić, zaimplementowałem, mój test przechodził, nauczyłam się czegoś nowego.

Później jakieś instrukcje warunkowe, jak to zrobić? Tak naprawdę zacząłem od asercji, od testów, później dopiero implementacja. Dzięki temu zaczynamy naukę nowego języka — to sprawdza się w szczególności przy językach, bo raczej ciężko gdzieś indziej zaprzęgnąć takie testy. 

Uczymy się rzeczy mega wartościowej, czyli testów plus do tego nowej technologii, więc jest to naprawdę super sposób i bardzo gorąco go polecam. 

Mam jeszcze jedną rzecz, którą uważam za ponadczasową i przydaje się zawsze, niezależnie od technologii — refactoring. Umiejętność refactoringu przydaje się zawsze. To nie jest tak, że zmieniając pracę, bo chcemy uciec z firmy, gdzie mamy brzydki kod. Chcemy wskoczyć do miejsca, gdzie będzie pięknie, kolorowo, mikro serwisy, domain-driven design i wszystko cudowne. 

Nie. Tak naprawdę zawsze znajdzie się miejsce, które trzeba w jakiś sposób zrefaktorować. Trzeba poprawić jakość i umiejętność tej poprawy jakości bardzo przydaje się podczas codziennej pracy developera. Wydaje mi się, że regular developer powinien przeprowadzać takie sesje refaktoringowe bardzo szybko i zwinnie, rozumiejąc to wszystko i rozumiejąc cel tego refactoringu. 

 

W momencie, kiedy zostajemy juniorem, kiedy rozpoczynamy swoją przygodę na przykład z językiem programowania, to najczęściej jest to właśnie jeden język programowania, jedna technologia, której się uczymy.

Zestaw umiejętności twardych, które musimy w tej technologii opanować. Zastanawiam się, jak to jest z mid developerami — czy powinni iść w kierunku poznania wielu technologii i szerzej? Czy wręcz przeciwnie — spróbować pogłębiać i drążyć temat tej jednej technologii po to, żeby stać się specjalistą w tym jednym obszarze. 

Jakie podejście ty praktykujesz?

 

Wydaje mi się, że to bardzo zależy od człowieka, który się tego uczy. U jednego bardziej sprawdzi się masterowanie konkretnej umiejętności i więcej mu to da, jeśli ciągle będzie poznawał jakiś nowe podejścia do rozwiązania problemów w konkretnej technologii, a u innej osoby sprawdzi się świetnie odpowiednie wymasterowanie na przykład naszego głównego języka, czyli C sharpa. Do tego, nauka czegoś całkowicie innego, żeby zobaczyć, jak wygląda to w innej technologii. Wydaje mi się, że to może fajnie inni to robią i przenieść wzorce do siebie. 

Dodajmy do tego zmianę paradygmatów. Myślę, że to jest super rzecz, która nawet w roli regular developera czy seniora jest świetna, bo pokazuje rozwiązanie jakiegoś jednego, konkretnego problemu w całkowicie inny sposób, dzięki czemu dużo się uczymy i ta wiedza jest bardzo przydatna. 

Koncentracja na jednej technologii, tak, ale nie zamykajmy się tylko na nią. 

 

Absolutnie się z tobą zgadzam! Trzeba to oczywiście w jakiś sposób wyważyć, ale najczęściej jest tak, że jeśli sięgamy do innych technologii, chociażby jako taki pep-project, albo coś, co zajmie nam chwilę, żeby się z tym zaznajomić to zazwyczaj owocuje tym, że stajemy się lepszymi programistami w naszej bazowej technologii, bo otwiera nam to oczy i daje też taki ogląd jak można rozwiązać dany problem w innych językach. Jest to więc często wartościowe.

Chciałem cię zapytać, co z projektami open source-owymi, jeżeli chodzi o angażowanie się w nie. Myślisz, że powinniśmy jeszcze bardziej doskonalić się po to, żeby do projektu open source-owego wnieść jakąś wartość, czyli dopiero będąc takim seniorem angażować się w rozwój tego typu projektów czy też może wcześniej, może już rola mid developera może być odpowiednia, żeby spróbować swoich sił i również w ten sposób udoskonalić trochę ten warsztat. 

 

Wydaje mi się, że temat open source-u i zaangażowania w tego typu projekty to jest coś, w co warto uderzyć niezależnie od stanowiska czy roli, umiejętności, jakie mamy. Open source zawsze nauczy nas czegoś nowego. Czasami rozwiążemy jakiś problem, nie będzie to idealnym rozwiązaniem, którego oczekiwałby założyciel projektu, ale wskaże nam jakieś rozwiązanie, nauczymy się czegoś.

Cały czas będziemy się czegoś uczyli. Zobaczymy podejście do rozwiązywania problemów w innym miejscu, nie tylko firma, w której pracujemy od trzech lat tylko zobaczymy, jak to się robi w podejściu, można powiedzieć, globalnym. 

Przy okazji uczymy się czegoś, co jest super istotne, ale o czym zawsze warto wspomnieć — czyli komunikatywności i pracy w zespole rozproszonym. Open source można tak traktować, że jest to jakiś zespół rozproszony, pracujący nad jedną funkcjonalnością i w ten sposób jesteśmy w stanie nauczyć się pracy z ludźmi, z którymi na co dzień się nie widzimy. 

 

Okej. Poruszyłeś temat pracy z ludźmi. Chciałbym zapytać cię o umiejętności miękkie, na które coraz częściej kładzie się nacisk, bo coraz rzadziej pracujemy jako one man army. Najczęściej jest to praca zespołowa i te umiejętności miękkie są znaczące, wręcz mówi się o tym, że coraz częściej posiadanie umiejętności świadczy o takiej przewadze konkurencyjnej na rynku pracy. 

Czy według ciebie mid developer również powinien rozwijać się w kierunku poszerzania miękkich kompetencji? Jeśli tak, to na jakie umiejętności powinien zwrócić szczególną uwagę?

 

Wydaje mi się, że jest tak jak mówisz – rynek coraz bardziej nastawia się na otwartych ludzi. Takich otwartych na umiejętności miękkie, umiejących pracować w zespole, umiejących rozwiązywać różne problemy na poziomie zespołu samego w sobie. 

 

Umiejętności miękkie, wydaje mi się, stanowią coraz większą wartość wraz z naszym doświadczeniem. Senior, który nie ma rozwiniętych umiejętności miękkich nigdy nie będzie prawdziwym seniorem, bo wtedy samo w sobie programowanie nie jest już tak ważne, jak właśnie rozwiązanie problemu biznesowego. Rozmowa z klientem, jakikolwiek przedstawicielem tego biznesu. Wydaje mi się, że bardzo ważną rzeczą, której powinien uczyć się każdy regular developer jest… Dzielenie się wiedzą!

 

 

Umiejętności miękkie, wydaje mi się, stanowią coraz większą wartość wraz z naszym doświadczeniem. Senior, który nie ma rozwiniętych umiejętności miękkich nigdy nie będzie prawdziwym seniorem, bo wtedy samo w sobie programowanie nie jest już tak ważne, jak właśnie rozwiązanie problemu biznesowego. Rozmowa z klientem, jakikolwiek przedstawicielem tego biznesu. Wydaje mi się, że bardzo ważną rzeczą, której powinien uczyć się każdy regular developer jest… Dzielenie się wiedzą! 

Po prostu: róbmy prezentacje wewnątrz firmowe. To nie jest jakimś wielkim wyzwaniem przed nami. Możemy przed pięcioma osobami wyjść, powiedzieć im coś ciekawego, zobaczyć, jak oni na to zareagują, uczymy się też takiego sprzedawania własnej wizji. To jest też ważne. Wydaje mi się, że programista powinien umieć sprzedawać. Tutaj towarem nie jest jakiś fizyczny przedmiot, towarem jest nasza umiejętność, nasza wizja i wydaje mi się, że taki programista, który chce osiągnąć coś fajnego musi potrafić też sprzedawać. Dzięki temu jest w stanie dowieść coś więcej i więcej znaczyć dla zespołu. 

Kolejna z takich umiejętności miękkich, wydaje mi się, że jest ważna: umiejętność akceptacji krytyki. Ludzie muszą rozumieć, że konstruktywna krytyka jest bardzo cenna. Code review, kiedy nasz kolega Janek napisze nam 15 komentarzy na temat naszego kodu, to nie jest coś dlatego, że chce nam dopiec, kopnąć w plecy czy coś, on chce nam pomóc. Jeżeli coś z tego wyciągniemy to win-win. Mamy fajny kod, umiemy coś nowego, widzimy jego podejście. Czyli właśnie: akceptacja krytyki i takie podejście bardzo pragmatyczne.

 

Cieszę się, że mówisz o tych umiejętnościach jako o czymś istotnym, bo nie wszyscy zdają sobie sprawę albo mocno fokusują się tylko na rozwoju umiejętności twardych, które oczywiście też są ważne, ale trzeba sobie jasno powiedzieć, że umiejętności twarde — ich jesteśmy w stanie się nauczyć znacznie szybciej, niż tych miękkich. Wręcz zaryzykowałbym stwierdzenie, że niektórych umiejętności miękkich nie da się nauczyć. 

Byłoby znacznie dla nas wszystkich lepiej, jeżeli coraz więcej osób technicznych, odpowiedzialnych za rzeczy techniczne, zrozumiałoby, że nie tylko na tym zamyka się ich świat i zaznajomienie się z tym, co jest istotne z drugiej strony, biznesowej, klienckiej, po pierwsze też jest istotne, a po drugie ubogaca nas jako ludzi, powoduje, że po prostu się rozwijamy. 

Jeśli już mówimy o rozwoju, to mam wrażenie, że obydwoje się zgodziliśmy z tym, że będąc mid developerem i mając aspiracje, żeby się rozwijać, dążyć na wyższe stanowiska, to musimy się… Rozwijać! Jeśli traktujemy pozycję mid developera tylko jako przejściową, to koniecznie trzeba postawić akcent na rozwój.

Jak według ciebie powinno to wyglądać? Na czym skupić się, aby ten czas, kiedy jesteśmy w fazie przejściowej, najlepiej wykorzystać? 

 

Częściowo już poruszyliśmy ten temat. Wydaje mi się, że ważne, aby nauczyć się robić rzeczy, które sprawiają nam też satysfakcję. Klepanie czegoś po to, żeby było, czyli jakieś bezsensowne refactoringi miejsc, które nie są istotne z punktu widzenia biznesu — one za dużo nam nie dadzą, ale jeżeli skupimy się na tym, aby zrozumieć ten biznes, czyli dowozić konkretne funkcjonalności, ale cały czas pozostawiając jakiś procent czasu na to, żeby zrobić to lepiej. Żeby zrobić to lepiej za każdym razem. To już da nam bardzo dużo.

Jeżeli mamy aspiracje, że chcemy wskoczyć tam wyżej, to powinniśmy analizować wszystko, co robimy. Czyli zaimplementowaliśmy jakąś nową funkcjonalność, była to potrzeba naszego działu biznesowego, to później usiądźmy do tego kodu, zbierzmy feedback od innych developerów, którzy pracują w tej części i przeanalizujmy własne błędy. 

Tak jak często jest z jakimiś grami zespołowymi, kiedy nagramy swoją rozgrywkę, później jesteśmy w stanie obserwować to raz jeszcze i zobaczyć błędy, które popełniliśmy, żeby później coś z tego wyciągnąć. Wydaje mi się, że tak samo tutaj: obserwujmy samych siebie i wyciągajmy wnioski. 

 

 

Myślę, że to się zawsze przyda, żeby próbować uczyć się na tym, co zrobiliśmy po to, żeby samemu stawać się lepszymi. 

Czy myślisz, że w momencie, kiedy jesteśmy regular developerem i developerem, czy jest sens myśleć o zmianie pracy? Czy to daje nam wystarczająco mocną pozycję na rynku pracy czy może poczekać, aż nam trochę ten level seniority podskoczy i wówczas mieć tę silniejszą kartę przetargową?

 

Wydaje mi się, że moment zmiany pracy raczej nie powinien być mocno powiązany ze stanowiskiem. Będąc seniorem, czy dopiero wtedy mogę zmienić pracę? Nie! Jeżeli jesteś regular developerem i nie masz od kogo się uczyć, to nie jest to miejsce dla ciebie. 

 

Wydaje mi się, że moment zmiany pracy raczej nie powinien być mocno powiązany ze stanowiskiem. Będąc seniorem, czy dopiero wtedy mogę zmienić pracę? Nie! Jeżeli jesteś regular developerem i nie masz od kogo się uczyć, to nie jest to miejsce dla ciebie.

Jeżeli nie jesteśmy w stanie się od nikogo uczyć i po prostu mamy taką stagnację, to warto rozważyć możliwość zmiany pracy, bo musimy cały czas się czegoś uczyć. 

Oczywiście senior już później nie ma takiego sufitu i musi sam wyciągać więcej wniosków i więcej się uczyć, ale regular developer powinien cały czas mieć od kogo się uczyć i mieć jakiegoś mentora, który pokaże mu jakąś drogę i zasugeruje jakieś rozwiązania.

Wydaje mi się, że właśnie to stanowisko mid-a jest bardzo stabilną pozycją do zmiany pracy. Czasami może być tak, że będąc midem w firmie A, przechodząc do firmy B nie będziemy już mogli wskoczyć na tę pozycję. Trafimy na przykład na juniora. 

To jest totalnie w porządku! Będąc juniorem, jeżeli finansowe kwestie nas zaspokajają, to jest to super pozycja. Jesteśmy najniżej, powinniśmy się turbo, dużo uczyć, czyli tak naprawdę cały czas się uczymy, coraz więcej wyciągamy i kiedy w tej nowej firmie przeskoczymy z powrotem na regular developera, to już będziemy dużo wyżej niż w poprzedniej firmie, widząc całkowicie inny kontekst pracy. 

Wydaje mi się, że regular developer i senior developer nie określa tego, czy to już jest moment na zmianę pracy, czy to już jest właściwa pozycja. Jedynie będąc juniorem warto się nad tym zastanowić, czy to jest odpowiedni moment, bo lepiej wyciągnąć wnioski, wskoczyć na taką stabilną pozycję regulara i dopiero wtedy analizować, czy to jest odpowiednie miejsce. 

 

Mam wrażenie, że gdy przeglądam sobie oferty pracy, albo jakieś oferty na LinkedInie, to najczęściej widzę junior lub senior przed nazwą stanowiska. Jestem ciekawy jak wynika z Twoich doświadczeń – czy regular developer jest mimo wszystko cennym dodatkiem do zespołu? Powiedziałeś tutaj, że to jest też taka rola, która cały czas powinna się uczyć, powinna mieć od kogo się też uczyć i to jest istotne. 

Jestem natomiast ciekaw, co według ciebie regular developer może wnieść do zespołu i czy jest po prostu cennym nabytkiem?

 

Odpowiadając na pytanie o tym, czy jest wartościowy, czy jest cenny, sto procent tak. Wydaje mi się, że zespół zbudowany z samych juniorów albo z samych seniorów jest kompletnie bez sensu. Ludzie muszą albo mieć od kogo się uczyć, albo mieć kogo uczyć. Regular developer jest pomiędzy — jednocześnie jest w stanie komuś dawać sugestie, jak i cały czas wyciągać wnioski z błędów innych kolegów, czy też z ich sugestii poprawy, zmiany. 

 

regular developer często wnosi wiele świeżości do projektu. Jest to osoba, która świeżo się na przykład uczyła i przeskoczyła do tej pozycji, czyli widzi coś z nowej perspektywy. Nie ma klapek na oczach jak niektórzy na stanowisku seniorskim, niestety. Ma takie nieszablonowe myślenie, które bardzo wiele wnosi, bardzo mocno potrafi wspomóc projekt sam w sobie. 

 

 

Wydaje mi się, że regular developer często wnosi wiele świeżości do projektu. Jest to osoba, która świeżo się na przykład uczyła i przeskoczyła do tej pozycji, czyli widzi coś z nowej perspektywy. Nie ma klapek na oczach jak niektórzy na stanowisku seniorskim, niestety. Ma takie nieszablonowe myślenie, które bardzo wiele wnosi, bardzo mocno potrafi wspomóc projekt sam w sobie. 

Czyli właśnie: regular developer jest bardzo ważny w zespole, fajnie jest ich mieć, fajnie, kiedy mamy w zespole wiele, różnych osób. Tak naprawdę to wszystko tworzy synergię, wszystko razem super pracuje. 

 

Jak najbardziej się zgadzam, pewnie! Są potrzebne osoby z różnym poziomem rozwoju. Po to właśnie, tak jak mówię — żeby tworzyć harmonijną całość, żeby wzajemnie mogło to fajnie działać. 

Jak wygląda sprawa pod kątem zarobków na takim stanowisku? Czy według ciebie jest duża różnica pomiędzy stanowiskami juniorskimi z jednej strony, od dołu patrząc a seniorskimi od góry? Czy to jest tak, że wynagrodzenie — oczywiście uśredniając, bo wiadomo, że to jest różnie, czy wynagrodzenie dla mid developera jest pomiędzy czy też może bardziej dąży albo juniorskiego, albo seniorskiego? 

 

To będzie bardzo subiektywne, co powiem. Wydaje mi się, że zarobki regular developerów często są bardziej odchylone w stronę seniorskich, co jest bardzo w porządku. Mają pewnie dzięki temu motywację, żeby przeskoczyć wyżej, uczyć się cały czas.

Zarobki są wysokie, ale też bardzo zależne od technologii. Tak naprawdę mamy tutaj przykład słonia i chomika. Słoniem jest PHP, a chomikiem Golang. Mid developer Golanga potrafi zarabiać nierzadko więcej niż senior developer PHP, dlatego że taka jest potrzeba tego typu developerów. 

To bardzo zależy do technologii, w której ktoś pracuje i umiejętności miękkich. Jak ktoś potrafi się sprzedać i co więcej, poza samym programowaniem, poza dodawaniem błędów do pustego pliku, czyli programowaniem jest w stanie wnieść w firmie. 

 

Mam podobne obserwacje. Pensje mid developerów nie są pośrodku, najczęściej są trochę skierowane w kierunku wynagrodzeń seniorskich danej technologii. 

Myślę sobie, że tak jak powiedziałeś — to jest uzasadnione. Mimo wszystko chyba przeskok od juniora do regulara jest większy niż później od regulara do seniora, więc być może jest to w jakiś sposób uzasadnione. 

 

Tak! Jeszcze tutaj jest taka pułapka, bo jeżeli jesteś juniorem, uczysz się, jest fajnie, nagle dostajesz boost w pieniądzach — przeskakujesz na regulara i zarabiasz nagle, załóżmy, dwa razy więcej, to możesz popaść w taką pułapkę, że później chcesz tak jeszcze raz. Niestety, wiele osób tutaj się gubi. 

 

To tak nie idzie do przodu — mimo wszystko ten szklany sufit w wynagrodzeniach jest, trzeba być tego świadomym. To jest słuszna uwaga. 

Czy w związku z tym według ciebie bycie regular developerem to jest taka bezpieczna przystań? Czyli już coś tam zarabiamy, niemałe pieniądze, mamy jakąś wiedzę techniczną, jesteśmy być może już odpowiedzialni i mamy jakieś prawo głosu w wyborze rozwiązań technicznych. Coś już znaczymy, mamy wpływ, odpowiedzialność. Właściwie, po co iść dalej? W momencie, kiedy chcemy się jeszcze rozwijać, musimy wziąć większą odpowiedzialność, musimy więcej się uczyć, żeby w kierunku seniora jeszcze się zbliżać. 

W związku z tym mogłoby się wydawać, że ta pozycja mid developera to jest taka bezpieczna przystań, z której nie warto wypływać. 

Jak sądzisz? 

Czy mimo wszystko powinniśmy poprzestawać na tym, czy raczej powinniśmy traktować to tylko jako fazę przejściową w naszej karierze? 

 

Bezpieczna przystań to jest idealne określenie dla tego co powiedziałeś, czyli regular developer to jest idealne miejsce. Jesteśmy w stanie się fajnie uczyć, zarabiamy bardzo przyjemne pieniądze i jesteśmy z tego zadowoleni. Pójście o krok wyżej, dalej, czyli przejście na stanowisko seniora tak naprawdę daje nam spojrzenie z takiego wyższego poziomu, nie patrzymy w kontekście paru klas, w których pracujemy tylko patrzymy wtedy już w kontekście całej funkcjonalności, całego systemu. 

 

Bezpieczna przystań to jest idealne określenie dla tego co powiedziałeś, czyli regular developer to jest idealne miejsce. Jesteśmy w stanie się fajnie uczyć, zarabiamy bardzo przyjemne pieniądze i jesteśmy z tego zadowoleni. Pójście o krok wyżej, dalej, czyli przejście na stanowisko seniora tak naprawdę daje nam spojrzenie z takiego wyższego poziomu, nie patrzymy w kontekście paru klas, w których pracujemy tylko patrzymy wtedy już w kontekście całej funkcjonalności, całego systemu. Wtedy mamy też taką odpowiedzialność, za który kod tam powstaje, za całą funkcjonalność. Dodatkowo trzeba pamiętać, że ponosimy odpowiedzialność za juniorów. Tak naprawdę to senior developer powinien być przykładem, dawać dobry wzór dla osób, które uczą się cały czas. To jest odpowiedzialność. Jednak regular developer również powinien wspomagać innych, ale tutaj jesteśmy w tej przystani. Musimy się zastanowić czy chcemy wypłynąć, czy ktoś na pewno chce być proaktywny, wspierać cały projekt, mieć więcej do powiedzenia czy nie. Zdarza się, że decyzja o tym, czy ktoś jest krok wyżej często nie zależy od nas. Niejednokrotnie regular developer ma więcej do powiedzenia w jakimś projekcie od seniora. Tylko że dalej chroni go stanowisko. 

 

 

Powiedziałeś, że senior to jest też taka rola, która świadczy nie tylko o tym, że jesteśmy zaawansowani w danej technologii, że posiedliśmy już jakieś umiejętności, mamy doświadczenie techniczne. Również jest to rola, która w jakiś sposób powinna coś od siebie dawać więcej np. poprzez lepsze rozumienie biznesu, szkolenie juniorów, bycie mentorem dla nich. Jestem ciekaw czy część z tych obowiązków powinna być obowiązkami juniorów. Myślę tutaj głównie o ich nauczaniu, być może nadzorowaniu. Według Ciebie rola mid developera jest to tego odpowiednia? Może to jeszcze za wcześnie? 

 

 

Według mnie każdy moment jest dobrym czasem, aby wspomagać innych i ich uczyć. Wielu regular developerów daje świetny przykład swoim kolegom, oni są w stanie już wtedy być takimi mentorami dla innych. Dzięki temu oni sami swoje seniority powiększają. Pomagając innym rozwiązujesz problem innej osoby i zdarza się tak, że sam się uczysz nowej rzeczy. Nie zawsze trafisz na pytanie, które znajduje się w projekcie. Bywa, że junior na to trafi. Ty możesz mu pomóc i dzięki temu sam z tego dużo wyciągniesz. Podsumowując, nie tylko senior jest odpowiedzialny, również regular developer. Wymiana wiedzy w zespole powinna wychodzić od każdego. W ten sposób, każdy może od innej osoby się czegoś nauczyć, co wpływa bardzo pozytywnie na cały projekt. 

 

 

Bardzo dobra odpowiedź.

 

 

W tym momencie można powiedzieć jeszcze o jednej rzeczy, o nadzorowanie kolegów. Uważam, że nie powinnyśmy nadzorować innych, chciałbym powołać się na książkę Daniela Pink-a, Drive. 

Jest to książka mówiąca o motywacji, autor opowiada o rzeczach takich jak nadzorowanie, jako motywacja 2.0 – kontroluj, pilnuj, sprawdzaj, wynagradzaj, kiedy konkretny cel zostanie osiągnięty. Niestety to nie jest takie proste, nie o to chodzi. 

Powinniśmy dawać autonomię, każdy powinien mieć do tego prawo. Oczywiście są granice, aby w pewnych przypadkach nie wypłynąć za daleko. Oczywiście każdemu lepiej się pracuje, kiedy ma możliwość wprowadzania własnych wizji w system. 

 

 

Kiedy myślę o roli mid developera to dla mnie to jest solidny fachowiec, osoba, która dobrze wykonuje swoją pracę. Myślisz, że takie stanowisko jest stanowiskiem przechodnim? Każdy programista traktuje to jako jakiś szczebel w karierze, w dążeniu do seniora? Może to jest odpowiednia miejsce, aby na nim poprzestać, realizować się w tej roli? Taka praca może komuś sprawiać przyjemność, niekoniecznie każdy z nas chce brać na siebie taką odpowiedzialność? A wiemy, że taka odpowiedzialność już na stanowisku seniorskim występuje. Być może mid developer jest odpowiednim miejscem, by się tutaj zatrzymać?

 

 

Wszystko tutaj zależy od człowieka. Jeżeli dla kogoś jest to satysfakcjonujące, nie ma aspiracji na zarządzanie ludźmi, prowadzenie projektów, dobieranie technologii, chce po prostu dowozić jakieś funkcjonalności, robić to w dobry sposób dodatkowo ucząc się przy tym dużo, ale nie chce brać odpowiedzialności za inne osoby i je nadzorować, wspierać ich bez przerwy- to jest dobre miejsce dla takiej osoby. Traktuje tę pracę jaką dobrą podstawę, ale nie chce wychodzić poza krąg. W niektórych sytuacjach nie zawsze jest to od nas zależne, firma może nas powołać na wyższe stanowisko, ponieważ mamy duże doświadczenie, znamy dobrze produkt i nie ma w tym momencie odpowiedniejsze osoby. Regular developer powinien wiedzieć czego oczekuje, dokąd dąży i co jest dla niego satysfakcjonujące, aby być spełnionym. Ponieważ nie jest już juniorem, który dopiero się uczy. 

 

 

Na to wszystko nakłada się pewne doświadczenie życiowe, znajomość samego siebie, świadomość tego, co chcielibyśmy osiągnąć. Nie tylko wiedza związana z daną technologią, pracą w zespole. W związku z tym możemy określić dokładnie co byśmy chcieli robić, w którym kierunku dążymy. 

Bycie mid developerem może być dla nas satysfakcjonujące, nie znaczy to, że jesteśmy leniwi, że nam nie zależy na rozwoju. Możemy być świetni w tym co robimy oraz dobrymi fachowcami, co będzie stanowiło solidną podstawę zespołu. Myślę, że to jest jak najbardziej w porządku. 

 

 

Tak, dokładnie. 

 

 

Bardzo dziękuję, Ci za tą rozmowę. Jestem wdzięczny, że pokazałeś różne odcienie roli mid developra. Bardzo przyjemnie było mi z Tobą rozmawiać, dlatego chciałbym Cię jeszcze zapytać gdzie można Cię znaleźć, gdyby ktoś z naszych słuchaczy chciał pogłębić swoją wiedzę związaną nie tylko z rolami w zespołach, ale również z technikami, z którymi masz do czynienia, rzeczami, w których się specjalizujesz?

 

 

Według mnie najlepszą formą kontaktu jest LinkedIn. Zapraszam do kontaktu, jeśli ktokolwiek miałby jakieś pytania, chciał porozmawiać, chętnie poruszę z nim np. tematykę IT. 

 

 

Właśnie. Jak zawszę wszystkie linki umieszczę w notatce do tego odcinka. Partyk, bardzo dziękuję Ci za rozmowę. Trzymaj się, do usłyszenia. 

 

 

Również dziękuję, cześć!

 

To już wszystko, co przygotowałem dla Ciebie na dzisiaj. Rozmowa z Patrykiem bardzo dobrze pokazuje co jest wymagane, by określać się jako mid developer. Rozwiewa też pewne mity i niedopowiedzenia, które wiążą się z nazywaniem stanowisk w IT, zwłaszcza w świecie programistów.

Często dostaję od Was, słuchaczy pytania związane z tą branżą. Zakres jest dość szeroki, od polecania kursu programowania, co do przyszłości jakieś technologii i rozpoczęcia tworzenia własnej aplikacji. 

Aby jeszcze wzmocnić i poszerzyć to, co robię, chciałbym zaprosić Cię do umówienia się ze mną rozmowę poprzez Skype, Hangouts, telefon. Postaram się w miarę możliwości, własnej wiedzy, zupełnie za darmo i bez żadnych zobowiązań odpowiedzieć na Twoje pytania związane z IT.  Z wyborem technologii, prowadzeniem projektu, rozwojem kariery. 

Możesz już teraz umówić się ze mną na spotkanie wysyłając e-maila na adres krzysztof@porozmawiajmyoit.pl. 

W notatce do tego odcinaka znajdziesz link do wsparcia społeczności Hakersów, którzy uczą potrzebujące dzieciaki programowania i robotyki. W obecnej sytuacji związanej z Koronawirusem wiele z tych dzieci, zwłaszcza z małych miejscowości, domów dziecka straciło możliwość uczestnictwa online z uwagi na brak sprzętu. 

Dlatego Hakersi robią teraz akcję przekazywania komputerów, możesz dołączyć przekazując nieużywany sprzęt, albo dorzucić się do kupna nowego. Nie muszę chyba mówić, że warto pomagać. 

Link w notatce do tego odcinka na stronie porozmowiajmyoit.pl/66. 

Jeśli spodobał Ci się ten odcinek i nie chcesz przegapić kolejnych epizodów- zasubskrybuj go w swojej aplikacji podcastowej. 

Jeśli nie wiesz jak to zrobić, wejdź na stronę porozmowiajmyoit.pl/subskrybuj. 

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o roli regular developera. 

Zapraszam do kolejnego odcinka już za tydzień. 

 

Cześć!