Mid developer

Krzysztof Kempiński
May 19 · 14 min read
Image for post
Image for post

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Patrykiem Wozińskim o stanowisku mid/regular developera.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

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.

Czytaj dalej na: https://porozmawiajmyoit.pl/poit-066-regular-developer/

kkempin’s dev blog

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store