Full stack developer

Krzysztof Kempiński
Jun 15 · 15 min read
Image for post
Image for post

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Grzegorzem Lipeckim o full stack developerze.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

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ę.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-069-full-stack-developer/

kkempin’s dev blog

Dev and life 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