Nie raz zastanawiałem się, lub właściwie bardziej starałem się zdefiniować kim tak naprawdę jest senior developer, jakie on posiada cechy, co go wyróżnia od mida czy juniora. W internecie jest oczywiście trochę artykułów poruszających taką lub podobną tematykę. Jednak gdy zobaczyłem, że w ramach grupy ITCorner Tech Meetup będzie organizownay meetup w całości poświęcony tematowi seniorów w IT, bez chwili zastanowienia postanowiłem się na niego zapisać. Sam meetup odbył się w poniedziałek 25 listopada o 17:30.

CodeGrip.SOLID

Przyznam, że czegoś takiego jeszcze nie widziałem :D. Bardzo oryginalne. W środku są cukierki na styl tic tac'ów.

CodeGrip.SOLID

UWAGA! Ten post nie będzie pięknym płynnym i przede wszystkim spójnym ciągiem tekstu. Cała treść powstała na bazie moich notatek i tego co zapamiętałem, dlatego jest wiele zdań napisanych tak po prostu, jako zapamiętana myśl czy notatka jednak czytając całość, każdy powinien zrozumieć sens wszystkiego i co do czego nawiązuje. Pierwszy raz na meetupie równolegle słuchałem i robiłem notatki w miarę możliwości.

ITCorner Tech Meetup

ITCorner Tech Meetup

Jest to grupa obecnie licząca 1076 członków. Grupa dostępna na meetup.com. Członkowie tej grupy oraz firmy w których oni pracują, organizują różne tematycznie meetupy. Natomiast ITCorner to dolnośląski klaster zrzeszający około 60 firm technologicznych.

Jest to świetna inicjatywa, ponieważ można uczestniczyć w prezentacjach, gdzie wypowiadają się ludzie z różnych firm z różnym doświadczeniem i wiedzą.

Jak zostać dobrym seniorem ?

Taka była główna tematyka tego spotkania. Było w sumie 4 prelegentów i każdy omawiał inny temat.

  • Quo vadis, Programmer? - Michał Kurzeja, CTO w Accesto
  • Modelowanie rozwoju drogą do roli Seniora, Łukasz Sutuła, Architekt Oprogramowania w Unity Group
  • Kto to jest “senior developer”?, Wojciech M. Gańcza, C++ Senior Software Developer w VM.PL Software House
  • Senior vs. DX, Maciej Stasiełuk, CTO/Software Architect w Vazco

Pierwsza prezentacja

Jak zostać dobrym seniorem

Pierwsza z prezentacji została dedykowama dla juniorów i midów. Czyli jak zostać dobrym seniorem. Opowiedzi były mniej wiecej takie, że senior to właściwie wręcz 'rzemieślnik', osoba z której zarówno biznes jest zadowolony oraz członkowie zespołu chętnie z nim pracują. To człowiek, który potrafi dzięki swojej wiedzy i doświadczeniu rozwiązać wiele problemów.

Ale senior to nie tylko długi czas w danej technologii.

W dążeniu do stopnia seniora trzeba przemyśleć karierę i jej rozwój. Należy rozwijać odpowiednie skille. Często ludzie młodzi myślą, że od razu trzeba umieć najnowsze, najbardziej hype'owane technologie jakie obecnie są na rynku.

Ważna jest wartość biznesowa w projekcie tzn. programista ma rozwiązywać problem lub ogólnie problemy, a nie tylko dostarczać linijki kodu.

Oczywiście umiejętności miękkie mogą być ok, kiedy rozwijamy się w kierunku np. managera czy product ownera.

Suma projektów buduje karierę i doświadczenie.

Powinno starać się stosować możliwie proste rozwiązania tzn. najprostsze na sam początek a następnie w miarę potrzeb rozwijać je z czasem i udoskonalać. Junior zazwyczaj lub nie zawsze jest w stanie poradzić sobie z dużym zadaniem ze względu na brak rozbicia go na pomniejsze problemy. Złożone zadania trzeba dzielić krok po kroku.

Znaj podstawy

Czyli za nim weźmiemy się za 'grube' technologie, należy się upewnić, że znamy wystarczająco dobrze podstawy.

Następnie było omówione zagadnienie jakim jest model T. Nie znałem tej koncepcji i wcześniej w sumie nawet o niej nie słyszałem. Nie potrafię tego opisać ale znalazłem artykuł - kompetencje-analityka opisujący te zgadnienie. Warto zobaczyć, ja sam też na pewno w wolnej chwili jeszcze będę to analizował. Ogólnie należy starać się rozwijać trochę szerzej a nie tylko w wąskiej specjalizacji.

Dziel się wiedzą

Również ważnym aspektem jest dzielenie się wiedzą na różne sposoby. Chodzi tutaj o proces przekazywania wiedzy, dzięki któremu nam jako osobie tłumaczącej komuś jakieś zgadnienia o wiele lepiej udaje się zrozumieć dany temat właśnie przez to, że musimy go na tyle zrozumieć żeby o nim opowiadać.

I ogólnie nie powinno zajmować się tylko tym co jest obecnie najmodniejsze, najbardziej nowoczesne i najbardziej reklamowane.

Prawdziwa wiedza to znajomość przyczyn Arystoteles

Druga prezentacja

Modelowanie rozwoju

To była prezentacja o modelowaniu rozwoju. Miała ona na celu przedstawienie, jak w świadomy sposób pokierować własnym rozwojem aby stać się seniorem w IT. Były pokazane różne fazy rozwoju z różnymi etapami.

4 fazy kompetencji tzn.

  • nieświadoma niekompetencja
  • świadoma niekompetencja
  • świadoma kompetencja
  • nieświadoma kompetencja

Rozwój to przede wszystkim poświęcony czas

I to jest całkowita prawda, ponieważ już z własnego, chociaż niewielkiego doświadczenia widzę i czuję, że naprawdę (w moim przypadku programowanie) to jest coś w czym trzeba bardzo dużo siedzieć i być przede wszystkim bardzo zdeterminowanym żeby zaobserwować jakieś rezultaty.

Oczywiście na procesy rozwojowe ma też wpływ otocznie w jakim jesteśmy. Czyli kiedy jest sytuacja, w której jesteśmy otoczeni ludźmi bardziej doświadczonymi od nas, to mamy dobre warunki ku temu, żeby nasza wiedza szła do góry. Jednak kiedy jesteśmy najmądrzejsi w danym pokoju, pokój ten należy zmienić (dobry tekst ale też prawda).

Czasami trzeba zrobić krok do tyłu. Może nie jesteśmy w odpowiednim obszarze, może nie do końca dana technologia jest dla nas, może jakieś trendy się pozmieniały.

Rozwój to aspekt rzeczywistosci

Można sobie stworzyć mapę z obaszarami i kierunkami do rozwoju, szczegółową, opisaną. Bardzo fajna koncepcja, której też nie byłem świadomy.

Trzecia prezentacja

Kim jest senior developer

Czyli kim jest senior developer ? Kto to właściwie jest ? Czy aby na pewno jest to osoba która :

  • ma duże doświadczenie w danej dziedzinie, i jak to się ma do IT które idzie tak szybko do przodu ?
  • pracuje x lat jako programista np. 5, 10 i więcej ?
  • potrafi samodzielnie rozwiązać dany problem programistyczny ?
  • pisze tak zaawansowany kod że nikt go nie rozumie ?
  • mieszka w hiszpani (señior) :D ... ?

Propozycja definicji rekurencyjnej :

Senior developer to ktoś, kogo inni senior developerzy uważają za seniora.

I tak raczej tylko inni seniorzy rekrutują seniora i sprawdzają jego wiedzę techniczną.

Osoby mniej doświadczone, zaczynają pisać bardziej złożony kod naśladując osoby doświadczone.

Dla pracodawcy, senior to osoba bardziej doświadczona niż pozostałe.

Dobry pracownik branży IT :

  • osoba samodzielnie myśląca
  • umie dopasować się do wymagań
  • dobrze współpracuje w zespole
  • zdolny do rozwiązywania problemów międzyludzkich
  • mentor dla młodszych stażem

Umiejętności indywidualne to nie wszystko

Zazwyczaj z punktu widzenia pracodawcy, istotny jest zespół a nie pojedyncze osoby. Panuje również hierarchia czyli rozróżniamy poziomy - od juniora do seniora. Grupa seniorów jako zespół też nie do końca ma sens, ponieważ nie szkoli nowych ludzi. Ale ma taką zaletę, że seniorzy mogą ze sobą konsultować różne rozwiązania i wybierać te najbardziej optymalne.

Senior developer to jest doświadczony członek zespołu zarówno technicznie jak i w relacjach międzyludzkich.

Jesteśmy neuronami w zespole - bardzo ciekawe spojrzenie

Praca seniora ma już charakter bardziej koncepcyjny lub architektoniczny.

Typowy projekt to jest około dwóch lat (tak średnio - wiadomo) od projektu do kodowania i pierwszego releasu. Sam projekt jest zazwyczaj rozwijany bez końca, czyli dochodzą kolejne funkcjonalności, łatanie błędów, updatey.

Scrum master pilnuje tylko, żeby projekt szedł do przodu - on nie jest do zarządznia zespołem.

Czwarta prezentacja

DX - developer experience

Maciej Stadiełuk - CTO w firmie vazco.eu

Brak definicji w wikipedii.

Ale definicję można określić jako : połączenie wszystkich wrażeń i odczuć kiedy programujemy. W kontekście emocji, wrażeń i przeżyć.

Było również porównanie że DX to tak jak UX tylko dla developera.

Bierze się to z tego, z czym mamy na co dzień doświadczenie, czyli dana technologia lub też hardware.

Występują różne problemy a programista chce po prostu robić coś twórczego.

Bywa czasami też tak, że projekt i ogólnie cały codebase jest np. stary, dziwnie zaprojektowany, zaniedbany i zły ale sami ludzie w projekcie są w porządku.

Kto właściwie powinien dbać o DX ?

W zespole tak naprawdę każdy powinien tego pilnować, od juniora do seniora. Ale również ludzie, którzy tworzą różne rozwiązania i narzędzia dla developerów.

Kilka propozycji jak można to polepszyć :

  • należy przemyśleć cały proces deploymentu
  • należy postarać się aby build time się skrócił czyli proces budowania/kompilowania projektu
  • postarać się by np. w projekcie był HMR (Hot Module Replacement)
  • dążyć do automatyzacji różnych procesów (to jest obecnie zagadnienie bardzo na czasie)
  • można roważyć własne CLI przy bardzo rozbudowanych projektach i środowiskach - ale wiadomo nie pod każdy projekt bo to overkill

Takich propozycji może być o wiele wiele więcej jednak nie sposób wszystko wymienić. Chodzi tutaj o to żeby nakierować na dany temat i potem już te wszystkie aspekty samemu przeanalizować.

Dokumentacja - bardzo ważna sprawa

Nawet zwykły doc w stylu how to - jak rozwiązać dany problem, jak coś zrobić. Można jakieś zagadnienie spisać w formie ciekawostki lub historyjki.

Warto udzielać się na Stack Overflow

Ogólnie co do tematu związanego z code style - warto stosować takie narzędzia jak np. Prettier, ESLint

Sprytny kod czyli 'clever code' - nie zawsze wartko spalać się nad jednolinijkowcami. Przesadnie mądry kod wcale nie jest lepszy, pomimo naszego ego. Nie jest czytelny dla osób wchodzących do projektu w tym dla osób na poziomie juniorskim.

Ulubione IDE

Należy znaleźć swoje ulubione IDE i znać je najlepiej jak się da, do granic możliwości. W przypadku braku bardzo dobrej znajomości IDE, jest się po prostu gorszym developerem. No i warto transferować tą wiedzę, wymieniać się nią, pokazywać ciekawe ustawienia i możliwości.

Nie warto ignorować warningów lub całej wręcz listy warningów. Temporary solutions - to może być droga do nikąd. Można utworzyć plik z brzydkimi rozwiązaniami i traktować jako dług technologiczny, jednak wtedy mamy w jednym miejscu scentralizowane rzeczy, które trzeba będzie jakoś poprawić.

Inne porady :

  • warto zadbać o to by nowa osoba mogła łatwo wystartować w projekcie
  • dockerize when possible
  • CI/CD jeśli się da
  • postarać się, żeby dług technologiczny był jak najniższy
  • wymiana wiedzy, wspólna analiza problemów

Panel dyskusyjny

Ostatnim etapem był panel dyskusyjny,w którym prelegenci odpowiadali na różne pytania od słuchaczy.

Jednym z pytań było to, gdzie najczęściej szukają oni wiedzy lub odpowiedzi na pytania.

  • konferencje
  • koledzy
  • media
  • społeczność (np. community danej technologii)
  • twitter
  • google
  • rozmowa z innymi developerami
  • newslettery
  • wykop
  • blogi
  • grupy facebookowe
  • audiobooki
  • podcasty

W swoich odpowiedziach opowiadali oni, że czasami widzę zdobywają po prostu jadąc gdzieś dłuży czas komunikacją miejską, czasami na siłowni a czasami w pracy muszą zagłębić jakiś temat żeby zrealizować zadanie. A czasami kiedy jest to możliwe więcej działają podczas weekendów.

Jedno z ostatnich pytań było związane z tym, czy np. ilość deplymentów czy releaseów jest wyznacznikiem wydajności zespołu.

Czy deployment jest dobrą metryką ? To zależy. To zależy od charakteru projektu i po prostu tego jak często trzeba wydawać nową wersję.

Pizza && networking

Cały meetup był naprawdę fajny i ciekawy. Pokazał mi on jak zagadnienie senior developera postrzegają ludzie będący już nim lub w ogóle prowadzący własne firmy. Oczywiście potem była pizza i luźne niekończące się rozmowy.