POIT #069: Full stack developer

Witam w sześćdziesiątym dziewiątym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest full stack developer.

Dziś moim gościem jest Grzegorz Lipecki – programista z wieloletnim doświadczeniem związany z firmą Consdata, w której na ten moment jest chapter leaderem w obszarze Cloud, wcześniej frontend. Software architect odpowiedzialny za ewaluację i dobór technologii. Prelegent na konferencjach i meetupach technologicznych.

W tym odcinku o full stack developerze rozmawiamy w następujących kontekstach:

  • jak definiuje się stanowisko full-stack developera i jak to się ma do stosu technologicznego?
  • czy działa on tylko w stosie webowym?
  • czy w czasie gwałtownego wzrostu branży IT stanowisko full stack developera nadal ma sens?
  • na jakie wyzwania i problemy trafia osoba, która chce nim zostać?
  • czy podążanie za nowinkami technicznymi nie zajmuje zbyt dużo czasu?
  • czy rynek pracy jest bardziej otwarty na takie osoby?
  • jak w praktyce wygląda praca full stack developera?
  • jaką wartość wnosi do firmy?
  • czy zespół składający się z samych full stack developerów to najlepsza konfiguracja?
  • czy osoby aspirujące do takich stanowisk powinny od początku szeroko się rozwijać?
  • czy stanowisko przetrwa dłużej?

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, która wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner  (posłuchaj)

Transkrypcja podcastu

To jest 69. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o stanowisku full stack developera.

Przypominam, że w poprzednim odcinku rozmawiałem o Centrum Operacji Bezpieczeństwa. 

Wszystkie linki i transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmoit.pl/69

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

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

Już dzisiaj możesz mnie wesprzeć w tej misji, zostając moim patronem na platformie Patronite. 

Wejdź na patronite.pl/porozmawiajmyoit i sprawdź szczegóły! 

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

Odpalamy! 

 

Cześć! Mój dzisiejszy gość to programista z wieloletnim doświadczeniem, związany z firmą Constada, w której na ten moment jest chapter liderem w obszarze cloud, wcześniej frontend. 

Software architekt, odpowiedzialny za ewaluację i dobór technologii, prelegent na konferencjach i meet-up’ach technologicznych. Moim i Waszym gościem jest dzisiaj Grzegorz Lipecki. 

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

 

Cześć wszystkim! Miło mi tutaj być razem z tobą.

 

Na początku powiedziałem, że Grzegorz związany jest z różnymi technologiami. Odcinek tego podcastu będzie przedstawieniem koncepcji full stack developera, czyli osoby, która w różnych technologiach, różnych językach programowania może się specjalizować. 

Grzegorz, na początku jednak standardowe pytanie wprowadzające w moim podcaście, czyli: czy słuchasz podcastów, a jeśli tak, to jakich najczęściej? 

 

Sprawa jest o tyle ciekawa, że z podcastami pożegnałem się jakieś 2 lata temu, gdy urodził się mój syn. Luksus posiadania czasu w większym okienku jest mi na razie nieznany. Myślę, że wrócę do tego za jakiś czas. 

Natomiast w międzyczasie posiłkuję się blogami, newsletterami. Gdy jeszcze słuchałem podcastów, to na pewno ThoughtWorks namiętnie słuchałem i gdzieś w tym się obracam. Szukam materiałów, w których mogę pochłonąć się w okienkach, krótkich przerwach.

 

Pewnie, rozumiem! Zacznijmy od definicji. Czy full stack developer to jest taki one man army? Szwajcarski scyzoryk, który w każdym projekcie sobie poradzi i każde zadanie jest w stanie ogarnąć czy też może w jakiś sposób istotne jest tutaj znaczenie słówka „stack”, które stanowi odniesienie do zakresu umiejętności takiej osoby. Jak to jest według Ciebie?

 

Bardzo podoba mi się to określenie „wolnej armii”! Od razu kojarzy z takim uzbrojonym Rambo. Pewnie tak można na niektórych mówić. Gdybyśmy się nad tym tak bardziej zastanowili, to moglibyśmy zacząć od takich przykładów. Kim dla mnie jest full stack developer i jest to z mojej codziennej pracy – pozwolę sobie przytoczyć. Wczoraj zajmowałem się przerabianiem rekrutacyjnych zapytań SQL na potrzeby jednego z naszych zapytań, dzisiaj z kolei zajmowałem się dodawaniem wirtualnego scrolla w tabeli, którą wyświetlamy na front-endzie użytkownika. Jeszcze tydzień temu zajmowałem się pisaniem skryptów budujących cache dla naszych buildów na Jenkinsie. To jest dla mnie kwintesencja full stacka. To jest człowiek, który może zająć się wszystkim. Osoba, która jest w stanie ogarnąć cały projekt, ale to siłą rzeczy idą za tym takie cechy jak ciekawość świata, z szerokimi zainteresowaniami i takim ogólnym, koncepcyjnym wyczuciem wszystkiego, co się dzieje. Moglibyśmy powiedzieć, że ma taki big picture całego projektu. 

Najczęściej spotykam się z takimi full stackami z krwi i kości, którzy nierzadko są pasjonatami, dla których programowanie to nie tylko praca, ale również coś więcej. 

Gdybyśmy chcieli scharakteryzować full-stacka, to ja bym się jakoś nie trzymał specjalnie tych pojęć “full-stacka”, w rozumieniu powstawania konkretnych technologii, czy warstw stosu. Dla mnie to jest człowiek, który jest się w stanie szybko nauczyć nowych konceptów i wejść w każdy nowy temat – nie boi się ich. Może ruszyć dowolne zadanie, które przed nim stoi. 

 

Dla mnie to jest człowiek, który jest się w stanie szybko nauczyć nowych konceptów i wejść w każdy nowy temat – nie boi się ich. Może ruszyć dowolne zadanie, które przed nim stoi.

 

Jego umiejętności wynikają z doświadczenia, które w międzyczasie zdobywał na różnych etapach. Wtedy ten stos jest w znany w miejscach, w których miał okazję pracować. Czyli full stack, jako taki Rambo, to jest przede wszystkim człowiek, który potrafi w każdy temat i zawsze wie, gdzie się coś dzieje. 

 

Bardzo fajnie to przedstawiłeś. Ta definicja, w oderwaniu właśnie od konkretnych technologii. Przedstawiłeś tutaj koncepcję człowieka, który chce być zaangażowany w różne aspekty projektu, jednocześnie chce się też dość szeroko rozwijać. 

Mimo wszystko, gdy myślimy sobie o full stack developerze, to nie da się nie pominąć tematu technologii. Mnie najbardziej, jeśli chodzi o full stack developera, to kojarzy się ten stack webowy. Jakoś tak przylgnęło do definicji full stack developera myślenie, że to tyczy się tego stacku webowego.

Nie jest to jedyna możliwość. Mógłbyś powiedzieć, jakie inne jeszcze stacki mogą być obsługiwane przez full stack developera?

 

Cieszę się, że poruszyłeś ten temat. Jest to dla mnie ciekawy konik i to porównanie, które przychodzi tak najprościej wszystkim do głowy, czyli frontend versus backend. To jest oczywiste porównanie. Najtrudniej dyskutować, bo ta linia jest wyraźna między front-endem a back-endem. 

Gdybyśmy zastanowili się nad innymi miejscami podziału, to może być ktoś, kto pisze usługi do systemu, zajmuje się głównie testami. Po przeciwnej stronie jest człowiek, który zajmuje się bazami danych i pisze SQL-e. Innym takim miejscem może być ktoś, kto zajmuje się UX-em, a ktoś się zajmuje UY-em. Wydawałoby się, że część osób wrzuci to we wspólny worek frontend, a jednak mogą tam być różnice. Tak samo możemy spojrzeć na przykład na devopsa i developera, który pisze aplikacje. 

To jest takie ciekawe spojrzenie. Teraz możemy zauważyć pewne przykłady. Czyli co gdybyśmy mieli frontednowca, który zupełnie nie rozumie mechanizmów sesji serwerowej i z tego będą wynikać jakieś konsekwencje w decyzjach, które podejmuje. 

Co, jeżeli backend developer nie rozumie baz danych i nie wie co to są JOIN-y, nie wie czym jest problem N+1 i zacznie pisać kod, który nie w stanie jest wykorzystywać ich narzędzia, zacznie z nim walczyć. 

Tak samo możemy mieć devopsa, który nie rozumie systemu, który deploy’uje. Na jednej z konferencji słyszałem taką ciekawą anegdotę związaną z GraphQL-em, gdzie tam jest model, że endpoint z zapytaniami zawsze się wystawia, tylko może nie działać. Przyszły informacje od IT, że usługi chodzą, a developerzy zgłaszają, że nie chodzą – rodzi to problemy. Wynika to właśnie z tego zamknięcia się w swoją specjalizację. Wiadomo – jeżeli ktoś chce, to zawsze znajdzie dla siebie jakąś niszę, natomiast fajnie jest rozmawiać o tym problemie trochę szerzej niż front-end, back-end i to są te przykłady, które można tak na szybko wymyślić. 

 

Zgadzam się! Branża IT, w której działamy, która nas otacza, rozwija się w zastraszającym tempie. Mam wrażenie, że to tempo narasta coraz bardziej. Pojawia się coraz więcej frameworków. Tutaj też można by było pewnie przywołać liczne anegdoty z dziedzin czy wręcz specjalizacji związanych z branżą IT. 

Czy myślisz, że w takim środowisku, które rośnie przez pączkowanie – coraz więcej przyrasta nam tych różnych dziedzin? Czy w takim środowisku ma sens mówić jeszcze, ma szansę przetrwać idea full stack developera, który przekrojowo przez cały ten stos technologiczny będzie w stanie zaangażować się w różne aspekty projektu? 

 

Tak. Jednym zdaniem – oczywiście, że tak. To jest tylko kwestia, jak na to spojrzymy. Gdybyśmy patrzyli na technologie, frameworki, narzędzia, to nie ma szans. Dobrze wiemy, że w samym JavaScripcie codziennie powstaje milion kolejnych bibliotek, drugie tyle umiera. 

Gdybyśmy wrócili do tej definicji, którą próbowałem podać – full stack developera – i zastanowili się, co jest dla niego ważne. 

To jest moim zdaniem zrozumienie architektury, paradygmatów, wzorców. Te koncepty, o których mówię pojawiają się znacznie rzadziej, nawet w naszej branży. Potrzebują kilka lat, żeby się umocnić lub zniknąć. 

To już jest znacznie łatwiej śledzić. Jeżeli znajdziemy takie rzeczy, to one pojawiać się będą już w całym stosie. Nie są taką specyficzną rzeczą dla tylko jednej z tych warstw. Znając teorię, która za tym stoi, możemy już spróbować nadgonić poszczególne technologie najczęściej w ciągu kilku dni. 

Z takich prostych przykładów, które przychodzą mi do głowy, to programowanie reaktywne, które weszło szturmem na salony i tutaj mamy nieszczęsnego JS Angulara. Mówię „nieszczęsnego”, bo większość moich znajomych developerów, którzy stoją z front-endem na bakier, zawsze podają to jako element, który jest trudny do przyswojenia. 

Tak naprawdę na serwerze też mogą mieć reaktywne programowanie, mogą mieć RX Javę, mogą mieć Spring Webflux i ten paradygmat wystąpi tu i tu. Teraz zrozumienie tego i nauczenie się, w jaki sposób z tym kodem pracować, jest dużo ważniejsze niż jakaś konkretna implementacja czy konkretne nazwy operatorów, które możemy wywołać. To może wbrew pozorom powiedzieć, że jest wtórne. 

Na tej samej fali możemy iść dalej – no bo mówiąc o reaktywnym programowaniu, pojawiają się reaktywne bazy danych, systemy sterowane zdarzeniami, mamy Kafkę i tak dalej. 

To wszystko to jest ten sam wzorzec. Podobnym przykładem będą mikroserwisy po stronie serwerowej, które mam dosyć otrzaskane, znane i spójne. Wiadomo – pojawiają się tam jakieś koncepty, ale na frontendzie też stosuje się to podejście. Tworzy się mikro frontendy. Znając ten koncept możemy spróbować poimplementować na różnych płaszczyznach. 

Jeżeli będziemy skupiać się na tym, co jest naprawdę ważne, co wyznacza kierunek, to te poszczególne implementacje, nawet jeżeli się co 3 miesiące zmienią, nie będą tak złe, bo sprawna osoba szybko nadrobi różnice między nimi i wejdzie w nie na użytkowym poziomie. 

 

Tak. To jest bardzo ciekawa sprawa, którą poruszyłeś. Mam wrażenie, że większość takich kluczowych koncepcji dla informatyki, programowania już została kiedyś wymyślona. Te koncepcje zostały w jakiś sposób opracowane. Być może nie było odpowiedniej myśli, mocy przerobowej komputerów, żeby to zaimplementować, natomiast jak się cofniemy, zabrniemy w historię rozwoju informatyki, to zobaczymy, że obecnie jest mało takich rzeczy, które nagle pojawiałyby się jako koncepcja zupełnie nowa. 

Gdzieś to wszystko już istniało. Być może jest jak mówisz – jeśli postaramy się zaznajomić z tymi podstawowymi rzeczami, które powtarzają się i przechodzą przez różne warstwy, to właśnie łatwiej będzie nam szybko wskoczyć w konkretną implementację, konkretne rozwiązanie wiedząc, jak to wszystko działa od strony koncepcji.

 

Jasne! Być może w momencie, kiedy się pierwszy raz pojawiały nie było dobrego gruntu faktycznie i po prostu hype nie był silny z nimi. Teraz wiele tych rzeczy, na nowo odkrytych wraca. Być może właśnie dzięki temu, że pojawiają się w innych stosach i stają się ciekawe w miejscach, w których jeszcze nie próbowano tego robić.

 

Grzegorz – sam poruszasz się w wielu technologiach, o czym powiedzieliśmy na początku. Pracujesz też z ludźmi, którzy rozwijają się w szeroki sposób. Mało tego – wasza firma mocno wspiera takie podejście. Czy patrząc z perspektywy czasu uważasz, że taki rozwój kariery, który idzie w różnych kierunkach równocześnie to jest dobry wybór?

 

Z perspektywy czasu oceniam to bardzo dobrze. To jest dla mnie bardzo trafna decyzja i teraz bym jej nie zmieniał. Przede wszystkim tak szeroki rozwój dostarcza mi wiele rozrywki, wiele technologii oznacza brak monotonii. Oznacza stymulację, to jest zawsze nowe wyzwanie, można zawsze nauczyć się czegoś nowego, czymś nowym się pobawić i nie szufladkować się w jedno miejsce. To pozwala mi robić różne rzeczy albo brać udział w skrajnie od siebie odmiennych projektach. 

Dzięki tej elastyczności, którą mam i podejściu, w którym ważniejsza dla mnie jest teoria a technologia przyjdzie i to jest coś, co użytkowo często można nabyć w trakcie, no to daje mi szansę bycia w pierwszej linii tych projektów firmowych i to jest moim zdaniem ważne. Radość z pracy. 

 

Przede wszystkim tak szeroki rozwój dostarcza mi wiele rozrywki, wiele technologii oznacza brak monotonii. Oznacza stymulację, to jest zawsze nowe wyzwanie, można zawsze nauczyć się czegoś nowego, czymś nowym się pobawić i nie szufladkować się w jedno miejsce. To pozwala mi robić różne rzeczy albo brać udział w skrajnie od siebie odmiennych projektach. 

 

Patrząc też na to w ten sposób, posiadanie szerokiego zakresu umiejętności pozwala też w rozwoju dojść dalej. Osiągnąć wyższe stanowiska, doczłapać się do tych pozycji leadów, architektów czy w zależności od tego, w jakiej firmie – to szersze spojrzenie jest wtedy potrzebne. Zrozumienie problemu, gdzie rozwiązanie jest tak naprawdę ważniejsze niż konkretne wyniki kodu, które powstają. 

W moim odczucie zwiększa to też konkurencyjność w firmie i poza nią, bycie taką bardziej wszechstronną osobą. Ale też znając wszystkie obszary w wystarczającym stopniu, możemy reagować na zmiany na rynku pracy i być może przesuwać się tam, gdzie chwilowo nas bardziej interesuje. Też mam przykład z ostatnich kilku dni, gdzie jeden z kolegów, z którym współpracowałem – kupę czasu pracował jako Java full stack – chociaż to jest takie masło-maślane. 

Ostatnio zmienił zdanie i postanowił pójść w taki stos typowo node i… Czy on jest dobrym programistą? No jest! Pisze dobry kod. I czy to jest Java, czy to jest Node, to niewiele zmieni. Zakładam, że w ciągu kilku dni wyrówna sobie te różnice, które potencjalnie się pojawią i wynikają z różnego doświadczenia tych osób. 

Takie osoby zawsze są w cenie. Posiadanie rozległej wiedzy – pamiętajmy, nie zabrania nam specjalizować się w konkretnych obszarach. To, że czuje się wszędzie względnie dobrze nie znaczy, że gdzieś nie czuje się super i tam nie próbuje zrobić z siebie turbo eksperta. Po prostu nie zapominamy o tej reszcie. 

 

Posiadanie rozległej wiedzy – pamiętajmy, nie zabrania nam specjalizować się w konkretnych obszarach. 

 

Kwestią dyskusyjną jest to, czy full stack developerem można raz zostać i już nim być, czy jest to wieczna droga. Natomiast chciałem zapytać na jakie wyzwania, problemy może natrafić osoba, która chce wejść na tę drogę zostania full stack developerem? 

 

To jest trudne głównie ze względu na czas. To się przejawiało podczas tej rozmowy, że temat jest rozległy. Na pewno jest też trudne ze względu na wychodzenie ze strefy komfortu. Nauczymy się jednej rzeczy, pracujemy w niej, czujemy się swobodnie, nic nas nie zaskoczy no to nagle przychodzi ktoś i mówi, że jeśli chcesz być wartościowy, mieć wyższe notowania w firmie to warto byłoby poczuć się tego, czego do tej pory nie musiałeś się uczyć. Ta ciągła potrzeba uczenia się i rozwijania tych umiejętności może być faktycznie trudna. 

Co tutaj się pojawia – taki problem, jak w takim razie odfiltrować materiały, które najszybciej dadzą mi najwięcej wiedzy, żeby nie spędzać czasu na czymś, co powtarza coś, co już wiem i szybko nabierać tych umiejętności. 

Pewnie warto pod ręką mieć jakiś autorytet, mentora. To nie musi być jedna osoba, bo to przecież każdy może się w tym specjalizować. To może być grupa osób. Tutaj warto wybrać firmę, gdzie jest dużo doświadczonych osób, od których będzie można uczyć się tych rzeczy, które będą mogły wskazać taki kierunek. Natomiast na pewno taka praca full stacka może nie być dla każdego. Jeżeli są osoby, które nie oczekują takich wyzwań i to miejsce kariery, w którym teraz są – jest dla nich komfortowe i dobrze się czują, to mogą nie chcieć inwestować w szerszy rozwój. To może być dla nich dobre. Wtedy te trudności przed nimi nie stoją. Tutaj pewnie warto pod ręką mieć jakiś autorytet, mentora. To nie musi być jedna osoba, bo to przecież każdy może się w tym specjalizować. To może być grupa osób. Tutaj warto wybrać firmę, gdzie jest dużo doświadczonych osób, od których będzie można uczyć się tych rzeczy, które będą mogły wskazać taki kierunek. Natomiast na pewno tak praca full stacka może nie być dla każdego. Jeżeli są osoby, które nie oczekują takich wyzwań i to miejsce kariery, w którym teraz są, jest dla nich komfortowe i dobrze się czują, to mogą nie chcieć inwestować w szerszy rozwój. To może być dla nich dobre. Wtedy te trudności przed nimi nie stoją. 

Natomiast jeśli szukamy wyzwań, nie boimy się opuszczać strefy komfortu, to warto zaryzykować, warto pójść dalej.

 

Chwilę wspomniałeś o tych materiałach, które warto by było dobierać w ten sposób, aby jak najszybciej dawały nam wartość. Chciałem zapytać właśnie o rozwój i podążanie za nowinkami technologicznymi. Czy full stack developer musi poświęcić ileś tam razy więcej czasu, by być na bieżąco w stosunku do osób, które są bardziej wyspecjalizowane we front-endzie, back-endzie czy jakkolwiek byśmy sobie ten stos technologiczny chcieli podzielić na warstwy? 

 

 Mógłby.  Taki i taki aspirujący do full stacka mógłby poświęcić więcej czasu i dałoby mu to wspaniałe efekty. Natomiast na pewno nie musi tego robić. Ta wiedza technologiczna przychodzi z czasem, z doświadczeniem i wiadomo, że nie zbudujemy tego w dzień, tydzień ani miesiąc. To się musi pojawić po drodze. Powiedzmy też sobie uczciwie, że nawet jeżeli przychodzi początkująca osoba, bez doświadczenia i zajmuje stanowisko full stack, to oczywiście nie będzie co do niej takich oczekiwań zrozumienia całego systemu, jak są do seniora czy do mida. To jest coś, czego będzie można nabrać i się nauczyć. Dlatego ja bym proponował skupić się na tym, co jest naprawdę ważne. Znowu wracamy do paradygmatów, wzorców. Do tego jakąś architekturę jak pisać kod, żeby był dobrym kodem. Są uniwersalne rzeczy, które możemy wykorzystać wszędzie. Teraz w zależności od tego, ile mamy tego czasu – takie minimum to są technologie, które bieżąco stosuję w projekcie.

Teraz jak zadbać o siebie? Być może jest to poprzez wywieranie wpływu wewnątrz firmy, żeby te technologie pomiędzy projektami były używane te same, no bo ta, której używam jest dobra, to czemu miałbym innym nie pomóc, skoro myślę, że używają być może mniej przydatnej. 

Teraz taki kolejny krok to pewnie byłoby ogólne wyczucie tej technologii, znajomość ich alternatyw, żeby móc na nie w razie czego zwrócić uwagę. Natomiast jeżeli w ten sposób będziemy dobierać coś, co jest kluczowe to pewnie niczego dogłębnie nie poznamy tylko będziemy potrafili się w tym poruszać, ale ta dogłębna wiedza przyjdzie w trakcie pracy. W trakcie korzystania z tych narzędzi. 

Wiadomo – im jesteśmy bardziej doświadczeni, z większą liczbą narzędzi się zetknęliśmy, to zaczniemy wyłapywać podobieństwa między nimi i ta wiedza będzie szybko przychodziła, i zostaną nam tylko konkretne case, na które, tak czy siak, trafimy. Wszystkiego się nie wyuczymy na sucho. 

Znając te wzorce i pojedyncze technologie, dzięki temu będziemy mogli się z łatwością wdrażać w te inne implementacje, które spełniają przecież te same ograniczenia albo być może wręcz autorzy podają czym szczególnie się różnią od tego, co już znamy i możemy szybciej przeskoczyć. 

 

Okej. Znajomość kilku technologii może być jakąś wartością dodaną dla nas i podnosić nasza wartość na rynku pracy. Chciałbym cię zapytać, czy według ciebie rynek pracy jest bardziej otwarty na osoby, które potrafią objąć cały stos technologiczny w stosunku do osób, które są bardziej wyspecjalizowane w jakimś określonym aspekcie tego stosu?

 

Mogę tylko z własnej perspektywy na to spojrzeć, bo nie znam statystyk rynku. Natomiast wydaje mi się, że ofert dla full stacków nadal jest dużo. Sami chętnie szukamy full stacków i chętnych nie brakuje – jest dużo osób, które są zainteresowane taką karierą. Mało tego, mamy sukcesy w nazwijmy to, przerabianiu osób na full stacków i to się zawsze wiązało z możliwością dodatkowego rozwoju i kiedy poznam jeden obszar to rozwijam się w kolejnych.

Według mnie okazuje się, że jest miejsce i że ten rynek jest takie osoby dalej przyjąć. Często jest też tak, że full stack dzięki szerszemu spojrzeniu potrafi przenieść rozwiązania z jednego stosu na inne. Coś, czego osoby, które pracują tylko w jednej technologii nie są w stanie zauważyć i nagle przychodzi ktoś ze świeżym spojrzeniem i mówi – niech już będzie, że a my na tym frontendzie to robiliśmy inaczej, weź spójrz, może to jest fajne. Coś, co dla kogoś, kto zawsze pisze w backendzie być może nie przyszłoby mu to do głowy.

Sam czuję, ze posiadając szerszy wachlarz umiejętności trochę swobodniej mogę przebierać w ofertach pracy. Mogę spojrzeć na różne – gdy przeczytam opisy tych stanowisk – to gdy nawet jest jakieś wyspecjalizowane to czuję, że mógłbym w nie wskoczyć, bo jestem w stanie te umiejętności albo już je mam, albo mogę je szybciej podgonić wiedząc co wiem z innych miejsc.

 

Poruszyłeś temat przechodzenia na inny stos technologiczny. Chciałbym spytać o potencjalne niebezpieczeństwo, które może wiązać się z tym, że pracujemy w jakiejś firmie, pracujemy w jakimś stosie technologicznym jako full stack. Czy jesteśmy w stanie w miarę swobodnie poruszać się po technologiach, które przez tę firmę są powiedzmy stosowane? 

Znamy się na tym stosie technologicznym używanym przez firmę. Czy to może oznaczać, że niekoniecznie łatwo będzie nam przejść na zestaw technologiczny oferowany przez inną firmę, bo może się okazać, że tam nie będziemy już full stackami, bo inne technologie są przez nią wykorzystywane, na których my się jakoś nie znamy, nie specjalizujemy?

Czy to nie zamyka nam w jakiś sposób dróg do zmiany pracy? Może niekoniecznie chcielibyśmy, będą full stackiem w firmie A przeskakiwać tylko na back end w firmie B. 

Jak na to patrzysz?

 

Zastanowiłbym się tutaj – to o, czym mówimy, to jest ryzyko. I czy to ryzyko faktycznie może się spełnić? Ta trudność w zmianie tej technologii, przejściu gdzieś indziej… To jest takie proste pytanie. Czy faktycznie, nawet jeżeli trafimy do innej firmy, która ma teoretycznie ten sam stos to to przejście jest płynne i od pierwszego dnia jesteśmy produktywni? Doświadczenie pokazuje, że nawet w tej firmie korzystającej z tej samej technologii będą jej używały trochę inaczej. Będą nazwijmy to, miały „firmowy dialekt” korzystania z tych narzędzi. 

Często okazuje się, że na danym narzędziu zostanie nadany jakiś firmowy framework czy rozwiązanie tak duże, że sama znajomość tego konkretnie narzędzia niewiele nam pomoże. Sam pracowałem w takich projektach, w których teoretycznie był Spring czy Angular. Ta nadbudówka sprawiała, że to nie były typowe problemy springowe czy angularowe, tylko 90% problemów wynikało ze stosowania narzędzia, które ta firma sobie stworzyła. Patrząc w ten sposób, nawet ten sam stos nie daje nam tej gwarancji. 

Jeżeli założymy, że full stack to jest osoba, która się rozwija, zna tej podstawy, teorię, wzorce, przykłady implementacji jakichś referencyjnych, to teoretycznie może to nadgonić. 

Doświadczenie pokazuje, że największą barierą przed wejściem w projekt raczej nie jest technologia – no bo technologia to jest coś, co doświadczona osoba w kilka dni, góra kilka tygodni jest w stanie nadrobić, ale najczęściej barierą jest wiedza biznesowa. Dziedzina tego problemu. I to i tak sprawi, że wejście w taki system zajmie 3 miesiące, w którym spokojnie będziemy mogli pod gonić technologiczne braki, jeżeli takie się pojawią. 

 

Doświadczenie pokazuje, że największą barierą przed wejściem w projekt raczej nie jest technologia – no bo technologia to jest coś, co doświadczona osoba w kilka dni, góra kilka tygodni jest w stanie nadrobić, ale najczęściej barierą jest wiedza biznesowa. Dziedzina tego problemu. I to i tak sprawi, że wejście w taki system zajmie 3 miesiące, w którym spokojnie będziemy mogli pod gonić technologiczne braki, jeżeli takie się pojawią. 

 

To wszystko sprawia, że ja bym się tego nie bał. To nie jest tak, że nie będziemy mogli przeskoczyć między dwoma projektami, bo to wręcz można sprowadzić do poziomu projektu w jednej firmie. 

Czy ja mogę zmienić projekt? Prawdopodobnie bardziej będę się bał tego, co ten projekt robi, bo jest duży i długi i ma siwą brodę niż tego, jakie narzędzia tam są, bo to jest coś co przyswoję, poznam. Może nawet przy okazji się przy tym pobawię. 

 

Jak to wygląda w praktyce? Nawet osoba, która dobrze zna się na backendzie i frontendzie – zostańmy już przy tym klasycznym podziale – w takim średniej wielkości projekcie, jest przydzielona do zadań w konkretnym obszarze. Dajemy na to, że w sprincie jakimś tam jednym zajmuje się dodaniem jakichś formularzy ze strony front-endu. 

Czy praca takiej osoby to jest ciągłe przełączanie się co jakiś czas ze sprintu na sprint, z różnych aspektów? Czy też jest to w miarę płynne? 

Jak to działa w praktyce i jakie wzorce, jakie podejście sprawdza się najlepiej? 

 

U nas w firmie wygląda to tak – od strony podejścia do tego tematu, bo jest ciekawy. Jeżeli zastanowimy się, w jaki sposób powinien pracować taki zwinny zespół, tak idealistycznie, to byłby to pewnie autonomiczny i samodzielny zespół, który jest gotowy podjąć dowolny temat i takiemu zespołowi zadania wrzuca się budując mu backlog. Jak to się ma do full stack?

Jeżeli przyjmiemy, że zespół jest autonomiczny i samodzielny, i zawsze realizuje funkcjonalność, to te funkcjonalności najczęściej jednak przekraczają się przez te wszystkie elementy. Nawet zakładając ten podział front-end, back-end, no to ta formatka, o której powiedzieliśmy, nie jest do pokazania, jeżeli nie ma do niej backendu. Jeżeli nie jest do pokazania, to nie jest zbyt dobrym elementem do backloga, bo przecież dobrze by było te elementy pokazywać na demo jako działające. 

Nagle okazuje się, że robiąc dowolną rzecz i tak musimy prawdopodobnie… Załóżmy, że robimy nowy moduł. Musimy go gdzieś zbudować, deployować, musimy go zaimplementować. Musimy przygotować zmiany na front-endzie, zadbać o tę spójność EYUX i to by znaczyło, że w takim zespole każdy ma okazję podjąć wszystkie zadania. Raczej staraliśmy się nie wiązać w: „Jakieś zadanie należy do kogoś, bo on się w tym specjalizuje”. I czy to czasami jest tak, że ja jako specjalista w jakimś obszarze biorę przede wszystkim te zadania, bo zespół na mnie liczy? No pewnie. Tak się zdarza. Jednak czy to równocześnie oznacza, że kiedy ja jestem obłożony innymi tematami to zespół ich nie podejmuje bo czeka, aż ja to zrobię? Absolutnie nie. 

Teraz, nawet jeżeli inne osoby, które wiem, że znają cały projekt, poruszają się swobodnie we wszystkich jego warstwach. Jeżeli podają takie zadanie, którego nie czują, to wtedy zapytają mnie, jak je zrealizować albo zapytają o jakąś wskazówkę, ale będą w stanie je podjąć. Na pewno nie będą się go bali. Na pewno nie będzie takiej sytuacji, gdzie powiedzą: „Ja tego nie dotykam, bo to są SQL-e”. 

Jeżeli tak na to spojrzymy to ten wspomniany przydział, że jakaś osoba specjalizująca się w jakimś zadaniu bierze konkretny typ zadań, to jest jakaś optymalizacja, ale nie jest ograniczeniem w pracy zespołu. 

Takie rzeczy codziennie rozwiązuje się na planowaniu czy to na daily czy spotkaniach w ciągu dnia. Zespół, w którym mielibyśmy osobę, która robi tylko jeden typ zadań, faktycznie nie byłby w pełni taki samodzielny. Mogłaby się przydarzyć sytuacja, że czegoś nie będą w stanie zrealizować. I tak właśnie staramy się budować zespoły. Dostają zagadnienie, które składa się z wielu rzeczy. Czasami jest więcej jednych tematów, czasami drugich, ale każda osoba w zespole jest w stanie takie zadanie podjąć i zrealizować, czy to samodzielnie, czy na tyle dobrze się w nim poruszać, że będzie wiedziała, kiedy poprosić o pomoc, a kiedy zrobi je zupełnie sama. 

 

Okej. To wprowadza fajną zwinność – domyślam się, że ta zwinność może być zwłaszcza cenna w różnego typu startupach, gdzie trzeba robić wiele rzeczy naraz, często przełączać konteksty, również te technologiczne. Czy w większych firmach według Ciebie jest podobnie? Czy ta wartość full stacka wynikająca z tego, że może szybko przeskoczyć przysłowiowo na różne aspekty technologiczne też ma tak duże znaczenie? 

Ogólnie – jaką wartość zdefiniowałbyś jako taką główną rzecz, którą full stack developer wnosi do firmy, do projektu? 

 

Gdybym miał nazwać jedną wartość, którą daje posiadanie full stacka – mówimy o full stackowych zespołach – to jest elastyczność. Z punktu widzenia firmy. To jest ta możliwość posiadania sprawnego zespołu, który jest zgrany, dobrze naoliwiony, super ze sobą pracuje i wrzucenia mu dowolnego problemu, który chwilowo akurat się pojawia. Nawet jeżeli nie jest to temat, którym się zwyczajowo zajmują. Jeżeli tak na to spojrzymy i sobie powiemy, że takie najsprawniejsze zespoły to pewnie będzie – o to możemy się pokłócić, ale załóżmy, że 4-5 osób, a jednak takich technologii jest więcej niż 4-5, to bez full stacków jest to bardzo trudne, żeby przykryć te wszystkie tematy pojedynczym zespołem. Natomiast taki zgrany zespół pozwala zminimalizować czas wdrożenia tego zespołu. Tam zawsze część osób zna większość i oczywiście oni się uzupełniają, ale razem mogą dosyć szybko wejść w dowolny temat i zminimalizować ten czas od podjęcia decyzji: „Okej, to zespół A się tym zajmuje” do momentu, aż są faktyczne efekty ich pracy. 

Tutaj mam ciekawy przykład. My startupem już nie jesteśmy. Korporacją też nie. Jesteśmy gdzieś pomiędzy ale nam też przytrafiały się sytuacje, gdzie musieliśmy być bardzo zwinni. I tutaj czynniki zewnętrzne sprawiły, że inaczej się nie dało. Mam na myśli projekty, gdzie zajmowaliśmy się wdrażaniem wniosków 500+ w momencie, kiedy się 500+ uruchamiało czy zajmowaliśmy się teraz, na bieżąco wnioskiem o dofinansowanie z PFR-a. To są takie projekty, w których od momentu, kiedy padła decyzja: „Okej, chcemy to uruchomić, chcemy to mieć” do momentu, kiedy pierwsza osoba musi zacząć składać te wnioski minie na przykład 3 tygodnie. 

My posiadając takie zespoły, które wiemy, że mogą dostać wszystko, to szarpiemy taki temat na funkcjonalne fragmenty, uruchamiamy kilka takich zespołów no i to się nam udaje. Dzięki temu, że te zespoły mogą dostać temat i one muszą opracować go w całości, czyli jak to ma wyglądać, jak mamy z tym zejść dalej, jak się będziemy z tym integrować systemami i te zespoły mogą nad tymi fragmentami pracować, to jest taka super zwinność. Zwinność, elastyczność, którą trudniej byłoby uzyskać budując takie tematy z pojedynczych ludzi, którzy się nie czują dobrze razem, nie są dobrani, nie współpracują już długo. 

 

Czy myślisz, że lepszy jest taki układ, kiedy w firmie czy projekcie wszyscy są full stack developerami? Czy też jak najbardziej do pogodzenia jest układ, w którym tylko kilka osób lub jedna jest full stackiem, a reszta ma jakieś węższe specjalizacje? 

 

Uważam, że taki zespół znacznie lepiej będzie działał, jeżeli będzie składał się z osób, które mają te przekraczające się kompetencje. Nie będzie nikogo, kto się specjalizuje w jednej, konkretnej rzeczy, no bo jeżeli mamy takie osoby, to pojawiają się takie prozaiczne czasem problemy, jak co się stanie, jeżeli jedna z tych osób pójdzie na urlop albo się rozchoruje, albo jakakolwiek inna sytuacja losowa się przytrafi. 

Co byśmy chcieli zrobić, jeżeli w jakimś konkretnym sprincie na jednej z osób będzie leżało dużo więcej zadań niż na reszcie i ktoś się będzie nudził, a ktoś nie będzie w stanie się wyrobić? Ta specjalizacja wprowadza troszkę takie ryzyko. Oczywiście pojawiają się jakieś sposoby, jak to rozwiązać, które miałem okazję przećwiczyć na sobie. To było dynamiczne łączenie zespołów, przerzucanie ludzi pomiędzy zespołami czy wrzucanie pojedynczych, technicznych tematów, niefunkcjonalnych do zespołu, bo akurat można było w czym konkretnym pomóc. To wszystko rodzi jakieś problemy, bo taki pojedynczy, techniczny temat sprawia, że zespół realizuje go bez zrozumienia szerszego kontekstu. Nie jest w stanie utożsamić się z tym, co robi i wziąć za to odpowiedzialności. 

Z kolei przebudowywanie zespołów to też jest problem. Wszystkie teorie mówią -przynajmniej te znane mi – że zespół jest sprawny, kiedy się dotrze. A taki okres docierania może trwać nawet kilka miesięcy. Każda zmiana w takim zespole zaburza tę chemię. 

To jest problem. Natomiast jeżeli mamy taki zespół, który długo się zna, świetnie razem pracuje, już jest po tym okresie docierania i wrzucamy w nich różne tematy – oni są w stanie każdy podjąć, nawet jeżeli część z tych osób jest właśnie na urlopie, to wydaje mi się, że to daje taką zwinność i trochę spokój, jak te zespoły pracują. Nie trzeba w nie ciągle ingerować. One są w stanie większość tych problemów, takich organizacyjnych teraz mam na myśli, same pochłonąć i przeć do przodu. 

 

Okej. Mówiąc o full stack developerze często mamy na myśli znajomość tych twardych właśnie umiejętności, twardych technologii. W obecnym świecie jednak nie do przecenienia jest UX – User Experience. Czy według ciebie jego, chociaż pobieżna znajomość jest tutaj istotna, jeśli mówimy o full stack developerze czy też zamknięcie się, ograniczenie się do technologii jest według ciebie wystarczające a aspekty bardziej miękkie, bardziej poza to już jest zupełnie inna tutaj para kaloszy?

 

Experience będzie bardzo ważny.  To nie jest coś, co możemy pominąć. W moim rozumieniu full stacka to się jak najbardziej łapie jako kompetencja, którą można poszerzać, warto poszerzać. Takich rzeczy jest więcej. Spójrz na testy, gdzie pojawia się rola testera w zespołach. Czy to oznacza, że developer nie powinien testować, nie powinien być może poznać narzędzi automatyzacji takich testów? Ale też umiejętności miękkie. 

To jest coś, o czym dość często zapominamy a to wszystko jest potrzebne w sprawnym zespole. Troszkę nie do pomyślenia jest sytuacja, w której developer wiernie realizuje makietę, którą dostał z zewnątrz. I widzi ten przycisk i wie, że nie jest w stanie z nim pracować, bo to jest niewygodne i teraz zakłada, że może niech ktoś inny to ogarnie. Nie – ta wiedza UX-owa mu się przyda. 

Oczywiście będzie specjalista, który przeszedł szkolenia, który jest w stanie zaprojektować taki UX na poziomie całego systemu spójnie, no to takie podstawowe wyczucie, poczucie, być może jakieś wskazówki, być może właśnie wskazówki otrzymane od tej osoby, która jest specjalistą w tym zakresie, powinny każdemu leżeć na sercu. Powinien zwracać na to uwagę. 

Myślę więc, że tak. Takie nieoczywiste miejsca jak właśnie UX powinny się znaleźć w wachlarzu umiejętności full stacka. Wiadomo, że to pewnie nie będzie tak, że będziemy od początkującej osoby w ciągu pierwszego roku pracy oczekiwać, żeby na wszystkim będzie się znała, bo tego jest za dużo, to nie jest możliwe.

Jak już docieramy do takich stanowisk jak regular, senior czy może coś więcej, no to odpowiedzialność za projekt, za wszystkie jego aspekty, powinna być w cenie. 

 

Okej rozumiem. Z perspektywy osoby, która dopiero zaczyna, która wchodzi do programowania to te umiejętności full stack developera, wachlarz jego umiejętności, wachlarz technologii, które zna mogą być, łagodnie mówiąc, nieco onieśmielające. 

Czy myślisz, że taka osoba powinna od początku już myśleć o szerszym rozwoju w licznych technologiach czy też może raczej przyjąć taką strategię, gdzie najpierw dosyć stabilnie i głęboko rozwija się, jeśli chodzi o jedną technologię, dopiero później poszerza ten wachlarz swoich możliwości, umiejętności o kolejne cegiełki. 

 

Najważniejsze, to jest uświadomić sobie, że to nie jest coś, czego można się nauczyć naraz. Tak jak w międzyczasie powiedziałeś, full stackiem nie można się po prostu stać. Full stack to jest pewne podejście do problemu, który przed tobą stoi i w tym przypadku jest to problem rozwoju swojej kariery i kompetencji. 

Teraz, gdybym mógł przedstawić, jak ja do tego podchodziłem: zawsze stosowałem takie podejście, nazwijmy to „podciągania umiejętności”. To znaczy, że jeżeli chciałem się rozwijać, to popychałem jeden z obszarów wyżej niż moja globalna ocena kompetencji, zawsze musiał pójść trochę do przodu. Wtedy jak już ten obszar poszedł do przodu i on był taki dominujący i można było powiedzieć: „Grzegorz jest w tym dobry”, to zastanawiałem się: „Okej, gdzie mi brakuje? Co mnie wstrzymuje? Dlaczego nie mogę dostać awansu? Gdzie mam braki?” i wtedy zajmowałem się tymi brakami, tak jak powiedziałem wcześniej – podciągałem je do tego wspólnego poziomu. 

Taki prosty przykład, gdybyśmy chcieli się zaszufladkować na stanowiska, bo to dosyć łatwo zrobić i wszyscy to mniej więcej czują, że – załóżmy, że z frontendu jestem na poziomie seniora i jest jakaś możliwość ocenienia tego, ale u devopsa mam regulara, a UX na poziomie juniora, leadów wiem, że tam coś jest – to w tym momencie będę się starał te devopsy i UX podciągnąć, żeby to nie były takie hamulce w moim rozwoju. Żeby je mieć, żeby nie odstawały za bardzo od tych umiejętności, które mam najmocniejsze. 

To sprawia, że idę taką szeroką ławą, że czymś się specjalizuję, w wielu rzeczach jestem bardzo dobry, ale nawet tam te rzeczy, które nie do końca czuję, staram się, żeby nie odstawały. Żebym nadal mógł podjąć swobodną rozmowę z kimś, kto jest na podobnym poziomie co ja, ale specjalizuje się w tych tematach. 

Taki rozwój w kierunku full stacka, myślę, że warto zacząć od wybrania jednego obszaru. Jeżeli chcemy zacząć w firmie, która pisze dużo restów, no to bez sensu jest się uczyć frontendu, skoro teraz potrzebne jest pisanie restów. 

Natomiast tak naturalnie z tym rozwojem – prawdopodobnie dotknie też innych projektów, prawdopodobnie mając więcej kompetencji dostaniemy też zadania z innych obszarów i podciągajmy to, bądźmy gotowi, żeby zawsze móc je podjąć. Natomiast faktycznie warto świadomie to wybierać. Taki rozwój full stacka wymaga faktycznie takiej świadomej oceny mocnych, słabych stron swoich. I takiego kierowania swego rozwoju. Planowania, gdzie się chce być za rok, trzy czy pięć. To nie jest tak, gdzie mnie poniesie tylko chcę to sobie jakoś ułożyć. 

To wydaje się generalnie wartościowe podejście do planowania swojej kariery, więc myślę, że to nawet jest dobra wskazówka sama w sobie. 

 

Powiedziałbym wręcz: całego życia! 

Taka samoświadomość jest przydatna na różnych warstwach, różnych etapach rozwoju, nie tylko zawodowego, ale też osobistego i tak dalej, więc mocna rzecz, pewnie. 

Dobrze. Na koniec chciałbym cię zapytać, czy myślisz, że rola full stack developera przetrwa? Powiedziałeś, że jak najbardziej ma rację bytu obecnie. Co do przyszłości – narastające podziały i specjalizacje, typu frontend, backend, development, właśnie utrzymanie. Czy to jest coś, co nadal pozwoli na istnieje jednej osoby, która w miarę jest w stanie poruszać się po tym całym stosie technologicznym? Czy te namnażające się specjalizacje nie wymuszają na pewnym etapie niestety, pozostania w jednej działce, być może w dwóch, ale mimo wszystko jednak nieogarnianie całości. 

Jestem ciekaw Twojego zdania jako osoby, która na co dzień rozwija się właśnie dosyć szeroko i jak widzisz przyszłość co do właśnie takiej roli full stack developera? 

 

Myślę, że pozycja full stacka nie zginie. Myślę, że to się utrzyma i będzie jeszcze długo dostępne. Nawet gdyby tak się zmieniła branża, że jednak jest popchnięcie w jakąś stronę, to przecież te zmiany są często okresowe a projekty się z dnia na dzień nie zmieniają. Posiadanie tej szerokiej wiedzy zwłaszcza wtedy może być przydatne, kiedy część branży się gdzieś przesunie. 

To niestety trzeba by monitorować. Natomiast myślę, że takiego zagrożenia nie ma. Też warto pamiętać, że bycie full stackiem nie oznacza bycia specjalistą we wszystkich tych dziedzinach. Na pewno tak jest, że full stack specjalizuje się w jednym, może kilku obszarach, natomiast kluczowe jest to, żeby znać te swoje mocne i słabe strony albo samemu potrafić znaleźć odpowiedź, albo wiedzieć, kto ich udzieli – podeprzeć się zespołem, z którym się długo pracuje we wszystkich obszarach. 

Tu jest taka ciekawa myśl, która może fajnie podsumować podejście full stackowe, czyli najważniejsze byłoby wiedzieć, czego się nie wie. Jeżeli wiemy, czego nie wiemy, to tam są miejsca, w których należy się zastanowić, a nie próbować na przykład force’ować rozwiązań na siłę. Full stack, mając szerokie zainteresowania, szerokie rozeznanie, będzie w stanie wyłapać te miejsca. 

 

Tu jest taka ciekawa myśl, która może fajnie podsumować podejście full stackowe, czyli najważniejsze byłoby wiedzieć, czego się nie wie. 

 

Tak jak gdzieś wcześniej wspomniane: developer, który nie czuje do końca SQL-i, nie wie, że może zrobić JOIN-a – jednak jeżeli będzie to wiedział, to tylko napisze inaczej. Gdyby się chciał zaszufladkować i powiedzieć: nie, nie, nie – nie szedłem na bazy na studia, żeby teraz SQL-e pisać. Jeśli się świadomie na to zamknie, to pewnie przegapi jakąś okazję, żeby coś zrobić dobrze. I tego pewnie bym się trzymał. Full stack to jest taki człowiek, który szybko może wskoczyć w nowe tematy, zna te silne podstawy teoretyczne, ma wyczucie całego systemu. Ta technologia mu nie przeszkadza. 

On wie, że to może nadgonić w dowolnym momencie i wskoczyć w dowolny temat, sprostać dowolnemu wyzwaniu, które na niego czeka. 

 

Bardzo dobre podsumowanie. Grzegorz – dziękuję ci z ciekawą rozmowę, za przedstawienie tej roli full stack developera i nakreślenie jej w sposób bardzo pragmatyczny. 

Jeszcze raz – wielkie dzięki z mojej strony i powiedz na koniec proszę, gdzie cię można znaleźć w Internecie? Jak się najlepiej z tobą skontaktować, gdyby ktoś miał jakieś pytania? 

 

Do mnie najlepiej będzie uderzać najzwyczajniej na LinkedInie. Jeżeli ktoś chciałby porozmawiać na jakiś temat bądź o coś zapytać, można mnie też znaleźć na naszym firmowym blogu, gdzie od czasu do czasu staram się coś opublikować. 

Również bardzo dziękuję za tę rozmowę, było miło, stres przed był znacznie większy niż był potrzebny. Super atmosfera. Dziękuję!

 

Dziękuję jeszcze raz! Oczywiście wszystkie linki dodam do notatki do tego odcinka. Dzięki z mojej strony trzymaj się i do usłyszenia! Cześć! 

 

Dzięki, trzymaj się! 

 

I to na tyle z tego, co przygotowałem dla ciebie na dzisiaj. Mam nadzieję, że po przesłuchaniu naszej rozmowy z Grzegorzem, masz lepszy obraz tego, jakim stanowiskiem pracy jest full stack developer.

Tak jak mówiłem na początku podcastu, założyłem profil na Patronite. To taka platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 złotych miesięcznie. Chciałbym oddelegować kilka rzeczy, które wykonuję przy każdym podcaście, a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie.

Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

Mój profil znajdziesz pod adresem patronite.pl/porozmawiajmyoit 

Link również w notatce do tego odcinka.

Cały czas aktywna jest też moja kampania związana z pomocą w IT. Z chęcią, zupełnie za darmo umówię się z Tobą na rozmowę i pomogę w miarę swojej wiedzy, z wyborem technologii, prowadzeniem projektu i rozwojem kariery.  

Możesz ustalić ze mną spotkanie już teraz, wysyłając maila na krzysztof@porozmawiajmyoit.pl 

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

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o stanowisku full stack developera.

Zapraszam do kolejnego odcinka już za tydzień! 

 

Cześć!

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.