#18 Programista Full Stack. Czy warto zostać Full Stack Developerem? Łukasz Ostrowski.

O kurczę, to muszę pić już stary. Nie. Powiem ci, kto to jest internista. A, no tak. Wady, podstawa. Ja teraz jak oglądam czyjeś podcasty, to zawsze patrzę, co oni piją. Cześć, jestem Nikodem. Witam w kolejnym odcinku podcastu DEVision. Dzisiaj w studio jest ze mną Łukasz Ostrowski, z którym będę rozmawiał o roli Full Stack Developera. Cześć Łukasz. Cześć. Zanim przejdziemy do tematu, powiedz kilka słów o sobie. To zapewne najbardziej interesujące będzie moje życie zawodowe, więc może pokrótce powiem, jak to wyglądało u mnie.

Nie wiem, czy było takie specjalnie ciekawe. Jak pewnie wiele osób w tej branży zaczynałem gdzieś jako dziecko z komputerami, programowaniem, grami i tak dalej. Potem gdzieś tam doszłałem się na studia informatyczne, których nie skończyłem, ale zacząłem programować. Zacząłem od stronek internetowych, tak trochę hobbystycznie, jeszcze nie wiedząc w ogóle, że będzie to dla mnie coś więcej. Potem stopniowo dostałem jakąś tam swoją pierwszą pracę, zacząłem pracować jako Frontend Developer. Potem stopniowo rozwijają się w kierunku bardziej właśnie Full Stackowym. Teraz bardziej biznesowo, w sensie dalej czynnie programuję, ale też jestem Product Ownerem i Team Leadem. No, także mniej więcej tak to wygląda w przypadku mojego doświadczenia w ostatnie ileś tam lat.

Kim jest Full Stack Developer? Ja myślę, że w przypadku tej roli Full Stack Developera, to trzeba by to rozebrać na jakieś czynniki pierwsze, żeby chyba odpowiedzieć na to pytanie. Ja oczywiście nie roszczę sobie żadnej tutaj jakiejś prawidłowej odpowiedzi, bo myślę, że jej nawet nie ma. Jakbyśmy wpisali w Google Full Stack Developer, to pewnie znaleźlibyśmy odpowiedź, że jest to ktoś, kto robi i frontend, i backend. I myślę, że większość z nas, jak to słyszymy, to pewnie też ma to na myśli. Z drugiej strony raczej nie postawimy w tym samym zestawie umiejętności osoby, która jest Full Stackiem z Reactem, Nodem, Serverlessami, co osoby, która jest, nie wiem, Java Enterprise, która pisze w Angularze przykładowo w jakiejś korporacji.

Myślę, że mogą to być na tyle Różnorodne staki, że nie tylko mają ze sobą niewiele wspólnego, ale też jakby ten nacisk może być złożony w innym kierunku. Tutaj myślę, że trzeba by się zastanowić właśnie przede wszystkim, po pierwsze w jakich technologiach się poruszamy, bo to słowo, to właśnie to stwierdzenie Full Stack, czyli jakby pełen stos technologiczny, to nam trochę definiuje, że powinniśmy teoretycznie poruszać się po wszystkich technologiach w danym projekcie czy w jakimś tam obszarze, w którym się zajmujemy. No ale czy to w takim razie oznacza, że jeżeli zmienimy projekt, to przestaje być Full Stackiem, dlatego że zmienił się framework, czyli język? Myślę, że to jest trochę wykluczające się, więc myślę, że jakbyśmy zaczęli, jeżeli traktujemy tą Full Stackową rolę jako takie pewne umowne coś, to sobie doprecyzujemy, ale nie wchodzimy w detale, to pewnie skończylibyśmy na tym front-end, back-end, ale może jeżeli chcemy

Naprawdę zgłębić, czym się kto zajmuje, to warto byłoby złożyć to trochę na czynniki pierwsze, w jakich technologiach się poruszamy. Nawet jak ofertę o pracę pisałem, przecież ja mam ogłoszenia, to też definiowaliśmy, że to jest na przykład Full Stack z Note'em czy z React'em, żeby właśnie zawęzić to stwierdzenie, bo ono jest na tyle szerokie, że nawet się może trochę wykluczać. Odpowiedź na to nie jest taka prosta, jak się wydaje. Załóżmy w takim razie, że Full Stack będzie w naszym rozumieniu oznaczał osobę, która potrafi zająć się jednocześnie front-endem i back-endem i rozważmy takie podejście. Jakie uważasz, że wynikają z tego plusy? Jaka jest zaleta bycia Full Stackiem albo posiadania Full Stack Developerów w zespole?

No, w sumie to widzę dwie główne, jedną biznesową, drugą taką może bardziej technologiczną. Z tej strony biznesowej, jeżeli mamy zespół, który jest, czy ludzi, którzy są uniwersalni, to łatwiej nam jest tymi ludźmi zarządzać, tak? Czyli trzeba zrobić jakieś zadanie na frontendzie, mamy samych backendowców, no to może mieć problem, że oni nie umieją zrobić tego zadania przykładowo. No to jeżeli mamy samych full stacków, no to Siłą rzeczy będą w stanie to zrobić, czyli mamy po prostu dość łatwiejsze zarządzanie tymi naszymi zasobami, że tak brzydko wyrażę, co jest chyba dość pożądane, szczególnie w takich może agencjach, tak mi się wydaje, chociaż może się mylę, pewnie też zależy od poziomu skomplikowania projektów.

Z drugiej strony, takiej bardziej technologicznej, to jest moim zdaniem też chyba jedno z największych takich zalet rozwoju w tym kierunku full stackowym, No to, że rozumiemy po prostu trochę więcej. Jeżeli się silosujemy, życie nie ma nic złego w specjalizowaniu się, tylko że znamy się tylko na frontendzie i zasadniczo wszystko, co opuszcza przeglądarkę, jest dla nas black boxem, no to myślę, że to ma pewne wady w rozumieniu zarówno tego, jaki software wytwarzamy, jak i też naszego własnego rozwoju czy rozwoju tego produktu. Dobrze byłoby przynajmniej trochę liznąć inne obszary, które się stykają, czy to właśnie będzie ten design, żeby wiedzieć, w jaki sposób pracuje taki designer, jak działa HTTP czy jakieś API, cokolwiek, żeby mieć większe zrozumienie, potrafić się dogadać z takim backendowcem.

Rozumiem, rozumiem tutaj takie... Rozumiem ideę tego, żeby pogłębiać zakres swojej wiedzy i rozumienie tego, jak działa front-end i back-end. Jeszcze myślę, że jest jedna rzecz, bo w sumie jak powiedziałeś o tym, że łatwiej było zrobić na frontendzie, to też nie znaczy, że powinieneś to robić na frontendzie, prawda? Ale z drugiej strony, jeżeli mamy takiego full stacka, no to ta osoba też jest w stanie sama dowieźć ownership. I to jest też myślę, że dosyć jakby istotne. Trzeba coś zrobić, trzeba dodać jakąś nową, nie wiem, nowe jakieś tam, nowe pole do jakiejś tam ENCY, tak? I z jednej strony wyświetlić to na frontendzie, z drugiej strony dodać to do naszego API. Najpierw ktoś to zadanie zdefiniuje, potem musi to zadanie pójść do backendowca i frontendowca, jeden to musi dodać do bazy, dodać do API, musi zastanowić się, jak to ma wyglądać, dogadać się z tym pierwszym, ten z kolei musi to dodać na frontendzie, skonsumować i tak dalej, czyli zaczyna się nam robić strasznie dużo operacyjnych problemów i teoretycznie to complexity tego zadania drastycznie po prostu rośnie.

A jak wiemy, jakby im więcej osób jest zaangażowanych w dany problem, tym to jakby wykładniczo rośnie złożoność komunikacyjna. A tak to mam z jedną osobę, która byłaby w stanie nawet dowieźć ownership taki biznesowy, w sensie po prostu wie mniej więcej co ma zrobić, po prostu to robi. No to nam przyśpiesza zasadniczo bardzo mocno pracę, a też nie ukłamujmy się, często te systemy nie są jakieś bardzo skomplikowane. Co innego jest, kiedy mamy jakieś faktycznie bardzo wyspecjalizowane systemy, ale w przypadku jakichś, nie wiem, crudów, to chyba takie full stackowe podejście jest całkiem efektywne. Jak zaczynałeś swoją karierę? No raczej nikt chyba nie zaczyna karierę od bycia full stackiem. Zawsze się zaczyna od którejś ze stron. Od której zaczynałeś? Od frontu. No tak, od frontu i dopiero gdzieś tam się wyskidowałem w tym frontendzie, to zacząłem po prostu gdzieś tam sięgać dalej.

Jak to w twoim przypadku wyglądało? Dlaczego postanowiłeś jednak nauczyć się też back-endu? Ogólnie wydaje mi się, że po prostu zawsze miałem taką ochotę na jakiś swój projekt, czy mieć jakieś takie swoje start-upy. Nie jakieś może wielkie biznesy, ale jakieś takie weekendowe projekty robić. I żeby takie rzeczy osiągnąć, no to nie da się tego zrobić na samym front-endzie. No więc po prostu zasadniczo pisząc takie aplikacje, zauważałem, że mam coraz więcej potrzeb. Więc zacząłem bardzo stopniowo rozszerzać tą wiedzę, doklejając sobie trochę tej jakiejś tam wiedzy i tak jakoś stopniowo osiągnąłem jakiś tam level, który pozwala mi tym Full Stackiem się nazwać. Oczywiście wiadomo, że pewnie by nie przyszedł rozmowy o pracę na Senior Backend Developera, gdyby zacząć mnie trzepać z jakichś tam zaawansowanych tematów, projektowania baz czy czegoś takiego.

Ale to też podkreśla, w jaki sposób ewoluuje technologia, że kiedyś aplikacje były takie back-endo centryczne, a front-endy były dość proste, a dzisiaj front-endy są bardzo skomplikowane, za to back-endy są as a service, można powiedzieć. Dzisiaj pisząc aplikację serverlessową z jakimiś bazami w chmurze i tak dalej, tak naprawdę nie trzeba być jakoś specjalnie Nie trzeba mieć jakichś ogromnych umiejętności, żeby być produktywnym w rozumieniu, takim biznesowym, żeby aplikacje dostarczyć. No, także to tak mniej więcej u mnie wyglądało. A jeśli chodzi jeszcze o to, to też jest ciekawe, jak powiedziałeś, że nikt nie zaczyna od Full Stacka. Właśnie wydaje mi się, że to jest często problem ludzi, którzy Tak, którzy zaczynają, że próbują robić wszystko naraz i widzą jakby jak strasznie dużo jest różnych technologii i jakby zanim się nauczą jednej, to już uczą się kolejnych i kolejnych.

Miałem zamiar zadać Ci pytanie, co trzeba zrobić, żeby zostać Full Stack Developerem. W sumie nawet raz taką inicjatywę przeprowadziłem. W jednej z firm front-endowcy mieli chęć rozwoju na Full Stack'a czy tam uczenia się Node'a. Ludzie zgłaszali takie zapotrzebowanie i zaczęliśmy się zastanawiać, jak to zrobić. I po prostu zrobiliśmy taki projekt poboczny, który był mikroserwisem. który był potencjalnym takim kontenerem, który można było po prostu zdeployować na jakąś nawet kliencką infrastrukturę, że kliencką, w sensie dla jakiegoś klienta można było zdeployować taki obraz jakiegoś tam API w nodzie. No jakby założenie było takie, że to jest po prostu robione z tak zwanej ławki, czy tam budżetu szkoleniowego, czy jak to tam nazwiemy, więc po prostu pisali to ci frontendowscy, którzy chcieli po prostu się nauczyć back-endu.

A jak już jesteśmy w jakiejś pracy, w jakimś konkretnym projekcie, no to jakby pracy przeważnie nie brakuje, więc myślę, że to nie jest jakiś wielki problem. No to ja właśnie miałem podobną historię. Zaczynałem na backendzie i dopiero kiedy poczułem się już pewnie w swojej roli, kiedy wiedziałem, że zajmuję się tak zadaniami jak powinienem, zgłaszałem się na początku po jakieś małe zadania frontendowe. Z czasem wiadomo, że coraz więcej i coraz trudniejsze, tak żeby właśnie podszkodzić się w tej technologii. Fajne jest jeszcze to, że nigdy nie zostawałem sam z danym zadaniem, tylko zawsze można liczyć na pomoc zespołu, także myślę, że w sytuacji, kiedy ktoś ma taką okazję w firmie i może liczyć na pomoc zespołu, to warto korzystać z takich okazji. Wszystko pięknie, ładnie i z Twoich obecnych wypowiedzi wynika, że warto jest być Full Stack Developerem.

No i tutaj myślę, że to jest bardzo indywidualne też, w jakiś sposób indywidualnie właśnie, czy lubimy po prostu, że tak powiem, nerdzić jeden temat, czy właśnie jesteśmy po prostu na tyle ciekawi, że jakby inne rzeczy nas interesują bardzo mocno. Tutaj chyba po prostu bym podążał za jakimś takim własnym przeczuciem, co po prostu jest dla nas interesujące. A jeśli chodzi o takie bardziej ogólne czy takie bardziej biznesowe podejście. Ostatnio na konferencji pojawiła się ciekawa myśl, że właśnie generalnie Full Stack Teams, ale nie Full Stack Developers. I tam właśnie jednym z takich argumentów było to, że Jeżeli mamy samych ludzi, którzy są od wszystkiego, to w praktyce nikt się na niczym nie zna. Owszem, każdy zna powierzchownie wszystko, ale nikt nie zna dogłębnie tej konkretnej rzeczy.

I tutaj na takim poziomie bardziej lidersko-menedżerskim można się zastanowić, czy faktycznie nie chcielibyśmy budować zespołów na tyle, Łukasz Ostrowski. Full Stackowy Team. Pewnie wszystko z kwestią jakiegoś tam balansu i też tego, jaki mamy ten produkt i zespół. Na dobrą sprawę przecież zespół może być całkowicie backendowy, no bo przecież mogą budować same serwisy, więc to też jakby nie ma chyba jakichś złotych zasad.

No i to może być po prostu ważniejsze dla niektórych przynajmniej, czy nawet taka domenowa wiedza, czyli nie wiem, pracując w banku, znam się na projektowaniu banków, więc już abstrahując od tego, możliwe po prostu, że ta wiedza jest ważniejsza niż samo konkretne języki, czy technologie, czy po której stronie barykady siedzę. Czy myślisz, że z biznesowego punktu widzenia Będzie kiedyś tak, że nie będzie się opłacało mieć wyspecjalizowanych ludzi, tylko lepiej, żeby wszyscy byli Full Stackami? Myślę, że nie, ale to chyba znowu zależy od tego, o jakim mówimy projekcie czy rodzaju biznesu. Jeżeli mamy, nie wiem, klepanie stronek na WordPressie, no to ten WordPress jest backendem, tak? Czy można powiedzieć, że ktoś, kto klepie stronkę na WordPressie jest Full Stackiem, bo zrobił jedno i drugie?

No ale mówimy tutaj o dość prostym systemie. Tak samo jak mamy jakieś krudy, no to też można by powiedzieć, że warto mieć tych full stacków, bo możemy dowieźć mniejszą ilością ludzi. Ale zawsze będą skomplikowane systemy. Może kto wie, może nawet będziemy mieli coraz więcej skomplikowanych systemów, bo te proste będą w pewnym sensie automatyzowane przez różne portale, które, przepraszam, frameworki, które nam te problemy prostego rzędu rozwiązują same. Więc jeżeli mamy skomplikowane systemy, to prawdopodobnie będziemy musieli mieć też odpowiednio wyspecjalizowanych ludzi. Myślę, że siłą rzeczy to musi pozostać. Zresztą nie chciałbym, żeby bank, z którego korzystam, miał Full Stack dewelopera od security, który się na tym tylko trochę zna, obok innych rzeczy.

Teraz mamy Photoshopa w przeglądarce, prawda? Ktoś to musi robić. I teraz pytanie, czy ten backendowiec, który pisał krudy 10 lat temu i umiał podstawy CSS, dzisiaj będzie w stanie napisać Photoshopa w przeglądarce? Może tak, może nie, ale myślę, że to jest jakiś tam trend, który tutaj akurat zaistniał. Kto wie, jakie będą trendy w przyszłości? To jest moim zdaniem chyba ważniejsze niż to, czy to będzie Full Stack, czy specjalista. Może po prostu warto byłoby na tym się skupić. Ja na przykład widzę właśnie taki trend z mojej perspektywy, gdzie wszyscy chcą mieć customowe front-endy, bo to jest część, którą widzi użytkownik, to jest jego experience, jego brand, znaczy brand firmy. A back-endy crude'owe można łatwo implementować w CMS'ach czy w jakichś back-end as a service, które nie są widoczne dla użytkownika, prawda?

No i teraz technologia też się bardzo szybko rozwija, więc jak możemy oczekiwać, że ktoś będzie znowu znał się na wszystkim? Możemy być tym chirurgiem od tego konkretnego api, które będzie na przykład, nie wiem, animacjami i to będzie nasza specjalizacja, ale oprócz robienia animacji pewnie wypadałoby, żebyśmy mieli też robić jakieś tam inne rzeczy. Także to jest chyba już indywidualna droga każdego, a ze strony biznesowej pewnie, no cóż, nie możemy przebierać w programistach, także myślę, że też nie mamy jeszcze problemów natury, czy zatrudnimy tego front-endowca, czy tego full stacka, czy tego back-endowca. Po prostu zatrudniamy, kto jest dostępny. Z czego korzystasz, żeby podnosić swoje umiejętności? Wolisz uczyć się we front-endzie czy back-endzie?