Full Stack to przeszłość

Nadszedł czas, by rekruterzy odświeżyli praktykę przygotowywania ofert pracy i zatrudniania, aby wpasować się w nową rzeczywistość, ponieważ nazwa “Full Stack” nie pomaga już w dopasowaniu wymagań stanowiska do umiejętności kandydata.

Geneza Full Stacka

Na początku nowego tysiąclecia narzędzia webowe dotarły do miejsca, w którym wszystko, co potrzebne do zbudowania strony internetowej, można było uzyskać z oprogramowania typu open source. Luźno podążając za modelem sieciowym OSI, zaczęliśmy nazywać całość stosem (ang. stack), a poszczególne jego elementy warstwami.

Stos LAMP był pierwszym z nich i posiadał cztery warstwy: L dla systemu operacyjnego Linux, A dla serwera HTTP Apache, M dla bazy danych MySQL i P dla języka skryptowego PHP. Z czasem koncepcja warstw sprawdziła się i pojawiło się wiele wariantów stosu: WAMP, MAMP, XAMPP, LEMP, LEPP, MEAN, JAMStack i inne.

Każdy z nich dawał prostą receptę na rozwój oprogramowania, co znacznie obniżało barierę wejścia dla osób zainteresowanych tworzeniem stron internetowych. Potrzebna była tylko wytrwałość i chęć uczenia się nowych narzędzi, języków i protokołów. Nie było potrzeby stosowania Microsoftu, Oracle, IBM ani innych komercyjnych dostawców. Było to pole przyciągające wielu graczy, co doprowadziło do spekulacyjnej ery ".com" w późnych latach 90-tych. 

Wkrótce, wprowadzenie AJAX w przeglądarkach (XMLHttpRequest) poskutkowało pojawieniem się nowego ich typu i przejścia do ery Web 2.0 wraz z aplikacjami internetowymi. Jednak nakład pracy związany z opracowywaniem nowych aplikacji oznaczał, że przy pracy w pojedynkę na developerach ciążyła duża presja, by zmieścić się w deadline'ach. 

Poskutkowało to pojawieniem się specjalizacji. Front-endowcy mieli HTML, CSS i JavaScript. Back-endowcy natomiast zajmowali się systemami operacyjnymi, serwerem HTTP i bazą danych. A programiści, którzy byli biegli w obu dziedzinach, byli nazywani Full Stack Developerami.

Era Full Stack

Specjalizacja była czymś dobrym, dopóki nie przestała taka być. Z jednej strony, oznaczała ona, że zespoły mogłyby pracować równolegle, aby skrócić cykl rozwoju oprogramowania, z drugiej, jednak, musieliśmy się bardzo natrudzić, aby przekazać wstępne wymagania i zmiany w specyfikacji, ryzykując utratę korzyści z naszej równoległej pracy, jeśli tego nie zrobimy.

Tak więc posiadanie zespołu Full Stack Developerów, bez wyróżniających się grup frontendowców i backendowców, wydawało się być dobrym pomysłem.

Najważniejsze było to, że każdy programista dobrze znał konsekwencje nawet najmniejszych zmian. Każdy z nich mógł odpowiednio ocenić wpływ i ryzyko, dając zarządowi jasny obraz kosztów i opóźnień. Dodatkowo, gdy zdarzały się odejścia pracowników, można było bezzwłocznie kogoś znaleźć i szybko przeprowadzić onboarding. 

Jednak wraz z poprawą podstawowych technologii, ten piękny obrazek stał się mniej przekonujący. Stos nie był już ograniczony do początkowych czterech warstw systemu operacyjnego, czyli serwera HTTP, bazy danych i języka skryptowego.

• Musieliśmy rozwijać nasze proste aplikacje, aby obsłużyć coraz to większą liczbę jednoczesnych użytkowników. Dodaliśmy więc równoważenie obciążenia.
• Potrzebowaliśmy szybszego udostępniania nowych serwerów przy mniejszym ryzyku krytycznych awarii. Przeszliśmy więc na rozwiązania chmurowe.
• Zaczęliśmy tworzyć rzeczy, które miały być skierowane do globalnej publiki. Zaczęliśmy więc duplikować nasz system w regionalnych centrach danych.
• Odkryliśmy, że bazy danych z ciężkimi schematami i skomplikowane joiny nie zawsze były najlepszym rozwiązaniem. Zaczęliśmy więc używać baz danych key-value. 
• Potrzebowaliśmy lepszej kontroli jakości. Zatrudniliśmy więc dedykowanych inżynierów do testów regresyjnych.
• Chcieliśmy zapewnić przeglądarce kontrolę nad renderowaniem i kompozycją, dlatego zmieniliśmy renderowanie po stronie serwera na REST-owe API.
• Dowiedzieliśmy się, że dobre zarządzanie kodem ma kluczowe znaczenie dla skuteczności zespołu, zatem stworzyliśmy odpowiednie workflowy przy pomocy Githuba. 
• W miarę wzrostu naszego potencjału, zaczęliśmy bardziej zwracać uwagę na to, co mówią nasi użytkownicy:

• Nasi użytkownicy oczekiwali, że aplikacje będą miały mniej formularzy, większą płynność, spójność i łatwiejszą obsługę. Zatrudniliśmy więc ekspertów od interfejsów użytkownika o umiejętnościach artystycznych i wrażliwości na ergonomię.
• Nasi użytkownicy domagali się mniejszej ilości przeszkód, aby wykonać swoją pracę. Zatrudniliśmy zatem specjalistów od UX, którzy mieli zbadać nasze niedociągnięcia i opracować lepsze sposoby interakcji.
• Nasi użytkownicy odkryli wygodę telefonów komórkowych i dręczyli nas, dopóki nie daliśmy im mobilnych wersji naszych dużych aplikacji SaaS.

I przez cały ten czas fundamenty się rozrastały:

• HTML5 dojrzał, aby objąć zasięgiem sieci semantyczne pracowników usług, dostępność, pracowników usług oraz komponenty.
• CSS się rozwijał, wykraczając daleko poza selektory i kaskady, aby objąć animowane przejścia, zmienne, nowe modele układu i media stronicowane.
• JavaScript eksplodował. Zawierał modularyzację, obiektowe klasy, funkcje asynchroniczne i możliwości wykonywania wszędzie - w przeglądarce, na serwerze i na desktopie.
• Protokół HTTP też się rozwinął. Zawierał lepsze buforowanie, zasady bezpieczeństwa, trwałe sesje, zmultipleksowane strumienie, kompresję nagłówków i ustalanie priorytetów.

Full Stack nie tyle umarł, co został zajechany. Warstwy stosu stały się tak ogromne, że nikt nie był w stanie wszystkiego samodzielnie ogarnąć. Pojawienie się dywersyfikacji obowiązków i specjalizacji było czymś oczywistym. Chwała Full Stack Developerów będących ludźmi renesansu w dziedzinie programowania, stała się przedmiotem legend. W nowej erze nikt nawet nie śni o ogarnięciu wszystkiego w pojedynkę. 

Stack w 2020

Musimy odpowiedzieć kilka pytań: czy są jeszcze osoby posiadające na tyle rozległą wiedzę i umiejętności, aby pracować na kilku warstwach? Jak uwzględnić zróżnicowaną mieszankę doświadczeń, które Full Stack Developerzy wnosili do projektu? W jaki sposób zarządy firm spełniają wszystkie te potrzeby? Jak osoby rekrutujące powinny filtrować potencjalnych kandydatów? Jak kandydaci powinni sprzedać swoje umiejętności?

Czas zmienić podejście do Full Stacka.

Mówię to z pewną ambiwalencją, ponieważ pomogłem spopularyzować ten koncept. Witryna full-stack.com była moją kopalnią wiedzy w 2009 roku. Dziś jest to niestety relikwia odpowiednia dla Muzeum Historii Komputerów.

Wykres popularności terminu “Full Stack” w Google w latach 2009-2019. 

Co dziwne, wydaje się, że istnieje coraz większe zaciekawienie terminem „Full Stack”. Wykres Google Trends na lata 2009–2019 pokazuje gwałtowny wzrost w ciągu ostatnich pięciu lat i każdego roku popularność wzrasta. 

Zastanawiasz się, jakie rozwiązanie zastąpi Full Stacka? Oto i ono. Oczywiście musimy nadać mu nazwę, abyśmy mogli to omówić.

Nazwijmy to Stack 2020. Nowa nazwa dla nowej generacji.

Po pierwsze, wyrazy szacunku dla osób, które mają duże umiejętności w różnych obszarach. Dzięki nim możemy mieć nadzieję, że nie wpadniemy w pułapkę specjalizacji. Chcemy unikać imperialistycznych tendencji, guru z tajnymi zaklęciami oraz silosów informacji, które wkradają się ze specjalizacją.

Po drugie, pogódźmy się z tym, że rozwój kariery oznacza, że ludzie przychodzą i odchodzą. Organizacje muszą się tego spodziewać. Nie można przerywać działalności, gdy doświadczeni pracownicy przechodzą dalej. W końcu „nie ma ludzi niezastąpionych”.

Po trzecie, komunikacja między specjalistami jest osłabiona przez żargon domenowy. Kiedy eksperci używają terminologii, akronimów i wyrażeń idiomatycznych, specyficznych dla domeny, narażają siebie i swoich kolegów z zespołu na niebezpieczeństwo. Przenikanie się domen jest niezbędne, aby komunikacja była skuteczna.

Oto niektóre cechy nowego specjalisty:

Ponieważ nikt sam sobie nie poradzi z tym wszystkim, Stackiem 2020 musi zajmować się zespół. Nie przypadkowa grupa osób, ale prawdziwy zespół. Oznacza to, że gdy jedna osoba pozostanie w tyle, inna to nadrobi. Kiedy jedna osoba ma doskonałe umiejętności, może mentorować inne. Szuka się również osób, które posiadają bardziej rozległą wiedzę. 

Każdy członek musi się orientować we wszystkich dziedzinach. Każda osoba z zestawem umiejętności ograniczonym tylko do jednej lub dwóch warstw stosu w rzeczywistości nie jest wartościowym graczem. Tego typu osoby mogą aspirować do bycia przyszłymi członkami zespołu w 2020. Albo i nie. Dopóki zdobywają wiedzę, są zaledwie kandydatami.

Mieszanka umiejętności, które członkowie zespołu 2020 wnoszą do projektu, nie jest ściśle określona. W przeciwieństwie do kategorii front-end i back-end, które przyjęliśmy, podziały na 2020 rok są bardziej różnorodne. Jeden zespół 2020 może mieć członka o umiejętnościach obejmujących NoSQL, konfigurację chmury i ciągłą integrację. Tymczasem inny zespół 2020 może mieć analogicznego członka zespołu o umiejętnościach obejmujących bazy danych SQL, serwery Node.js, konteneryzację i orkiestrację. Określanie ich mianem back-ednowców nie oddaje w pełni tego, co wnoszą do projektu. 

Wreszcie, najistotniejszy element: komunikacja powinna prowadzić do podjęcia wspólnie najlepszej decyzji. Oznacza to, że współpracownicy, których umiejętności się przeplatają, powinni zachować otwarty umysł. Zamiast tylko informować innych członków zespołu o postępach, powinni również omawiać ze sobą różne rzeczy. To sprawia, że wszyscy się uczą i rozwijają symbiotycznie.

Powitajmy “Stack 2020”

Zobaczmy, jak możemy wykorzystać powyższe koncepcje, aby lepiej dopasować wymagania danego stanowiska do umiejętności kandydata. Oto, co project manager może zamieścić w ogłoszeniu rekrutacyjnym: 

Firma X poszukuje członka do zespołu Stack 2020. Wymagane duże doświadczenie w testowaniu, dokumentacji i zarządzaniu kodem. Kandydaci powinni także posiadać umiejętności w co najmniej dwóch z następujących obszarów: konfiguracja chmury, konteneryzacja, orkiestracja, CI/CD i skryptach server-side.

Pomóż nam kształtować naszą przyszłość, pomagając w doborze najlepszych narzędzi do pracy. W RCB awans zawodowy jest częścią tego, co robisz. Dziel się swoją wiedzą z resztą zespołu w Technologiczne Wtorki.

Rekruter mógłby też wybrać bardziej szczegółowy zestaw słów kluczowych, np.:

Nasz klient poszukuje nowego członka zespołu Stack 2020, który pomógłby w testowaniu regresji, dokumentacji API oraz zarządzaniu przepływem pracy w Github oraz jako DevOps. Jeśli uważasz, że do nas pasujesz, odezwij się.

Oto, co aplikant może umieścić na swoim profilu LinkedIn (pragmatycznie używając zarówno starej i nowej terminologii):

Jan jest członkiem zespołu Stack 2020 z dużym doświadczeniem w klasycznych technologiach back-endowych i współczesnym DevOps 2020, w skład których wchodzą Gitlab, Kubernetes i Digital Ocean. 

Jest entuzjastą oprogramowania open source oraz DRY, i uważa, że kluczem do efektywnego ponownego wykorzystywania jest dobra dokumentacja.

W powyższych opisach widzimy wyraźne połączenie ról między zarządzaniem kodem a zadaniami DevOpsa. Również używanie terminu Stack 2020 sugeruje bardziej wyrafinowaną rolę niż stereotypowego starego Agile’owca.

Warstwy, warstwy i jeszcze raz w warstwy

Jaki jest zatem najbardziej rozsądny sposób na umocnienie pozycji tego nowego terminu? Czy nazwy takie jak front-end i back-end są wystarczająco konkretne? A co z terminami serwer i sieć, które często pojawiają się obok terminów projektowanie i ops? 

Nie możemy też zignorować tych, którzy przeprowadzają testy, ponieważ bez ich wiedzy dostarczalibyśmy produkty gorsze od naszych konkurentów, a bez marketingowców nigdy nie mielibyśmy nawet klientów.

W kolejnym artykule podzielę się idealnym “stosem 2020”.

To oficjalne tłumaczenie z języka angielskiego, a oryginał tekstu przeczytasz tutaj.