Szymon Warda: Cześć. Słuchacie Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: …i Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie klasycznie na patoarchitekci.io tym razem /72 lub gdzieś na dole w Twoim playerze będzie link do wszystkich materiałów. Dobra Szymon, co masz w tym tygodniu?

Szymon Warda: Dwa linki. Jeden ciekawy pod paroma względami. Mianowicie - pierwsze pokazuje dystrybucję różnych poziomów inżynierów, czyli deweloperów de facto, w Uberze na przestrzeni ich poziomów tak naprawdę. I to fajnie widać, bo widać, że poziom czwartego jest tak najwięcej. 5A jest mniej, a tych takich najwyższych poziomów już jest bardzo, bardzo niewiele. I to fajnie pokazuje dystrybucję, jak budować organizacje i ile de facto potrzebujemy, ale jest też coś ciekawszego w tym. Mianowicie - jak fajnie definiowane są różne poziomy właśnie deweloperów, bo podejście do tego, że ten inżynier najwyższego poziomu niejako tak naprawdę to jest company level, potem idziemy w dół, czyli organization level, area level, group level, team level, project level i task level. I wydaje mi się, że to jest idealny opis de facto jeżeli mówimy o seniorowatości, czyli doświadczeniu de facto ludzi właśnie. Jak dużym taskiem może się zająć na poziomie technicznym, na poziomie właśnie takiej koordynacji typowo technicznej. Mała pierdoła, ale naprawdę bardzo zwięźle opisująca zakres kompetencji poszczególnych osób i co dawać ludziom na kolejne poziomy, żeby awansowali, żeby się ładnie rozwijali i jako wyznaczanie kolejnych celi. Kolejnych poziomów de facto.

Łukasz Kałużny: Znaczy wiesz co, ale to w większości big techów wygląda bardzo podobnie ta drabinka. Jak wejdziesz na Levels.fyi i zmatchujesz, zobaczysz gdzie jaki level się matchuje to większość jest bardzo podobna.

Szymon Warda: Tak, jak najbardziej. I w ogóle te L i tak dalej, one są do siebie… Mapują się bardzo ładnie, czasami jest ich 6, czasami jest ich 8, niewiele się różnią.

Łukasz Kałużny: I SDE, ewentualnie SDE.

Szymon Warda: Tak, więc właśnie wracając do dystrybucji, czyli najwięcej jest zdecydowanie właśnie project level i team level tak naprawdę. A potem jest taki drastyczny, drastyczny spadek tak naprawdę.

Łukasz Kałużny: Bo osób, które łączą kropki na wyższych poziomach potrzebujesz coraz mniej.

Szymon Warda: Zgadza się jak najbardziej, ale już nawet osób, które łączą kropki na poziomie group level.

Łukasz Kałużny: Tak.

Szymon Warda: Czyli takiego teamu. To już jest kilkakrotnie większy spadek.

Łukasz Kałużny: Ale właśnie to widać, słuchaj, to widać. Bo to łączenie to jest coś tak jak mówimy, że dlaczego architekt powinien mieć tam przełożenie np. jak popatrzymy sobie na rynek gdzieś tam korporacyjny inny, a nie techowy. To też pokazuje właśnie, dlaczego mówimy, że architekt czy osoba, która w tego typu organizacjach ma właśnie taką rolę staffową, jej praca ma się przekładać na ileś osób, jego pomysły, kierunek ma być skalowalne grupą osób. Dużymi grupami osób.

Szymon Warda: Jest jeszcze jedna rzecz ciekawa, najniższy poziom, czyli task level, czyli de facto junior. Nie oszukujmy się. Jest mniej juniorów niż powiedzmy takich midów. Czyli project level. Projekt może bym nawet powiedział, że to taki bardziej mid-senior de facto.

Łukasz Kałużny: No.

Szymon Warda: Ale jest mniej juniorów tak naprawdę, więc też ta drabinka ciekawie wygląda tak naprawdę, no.

Łukasz Kałużny: Ale chyba wszędzie, wiesz co, task level wszędzie wygląda w miarę też podobnie.

Szymon Warda: Powiedziałbym właśnie, że w projektach polskich często właśnie juniorów mimo wszystko jest trochę więcej, albo jest na równi z tymi midami. Tak naprawdę.

Łukasz Kałużny: Nie, ja mówię bardziej, patrzę pod kątem big techowym, bo to co lokalny rynek projektów… To tak, z Tobą się zgadzam, że są projekty, gdzie nie ma praktycznie juniorów, czyli są bardziej wzięci do rozwoju, a są niektóre, gdzie nimi się ogarnia dosłownie kuwetę.

Szymon Warda: Jestem ciekawy, bo właśnie przez 2021 to właśnie było takie niejako wymiecenie juniorów, po prostu ciężej było nimi zarządzać zdalnie. Jestem ciekawy jak ten rynek teraz wygląda, bo właśnie nie widziałem jeszcze żadnego raportu. Poszukam, to się może znajdzie.

Łukasz Kałużny: Tak, trzeba będzie zerknąć jak to wygląda, zrobić przegląd tegorocznych raportów. Dajcie znać, jeżeli któreś już czytaliście, bo się tego namnożyło, więc może wskażecie, które są interesujące.

Szymon Warda: Tak, a co Ty masz, Łukaszu?

Łukasz Kałużny: Dobra… Zastanawiam się… Mam trzy linki, ale zacznijmy może od żartu, żeby było na luźno. Znowu Oskar. Pozdrawiamy Oskara, ale śmiał się z naszego hejtu na Postgresa, że zaraz będzie do wszystkiego i do niczego. Będzie wyglądał gorzej niż projekty Oracle’owe i wrzucił linka, który powiedział, że też naszą opinię dobije gwoździem i wrzucił projekt, który się nazywa DBDev, Postgres SQL Package Manager.

Szymon Warda: Przewidziałem ten fakt, że to w tym kierunku pójdzie.

Łukasz Kałużny: Nie wiedziałeś, że pójdzie, ale tak, Select DB. DB install.

Szymon Warda: To ja dorzucę. Łukasz sobie nie żartuje z tym select db install. Dokładnie tak to wygląda.

Łukasz Kałużny: Tak, żeby nie było to z tym akurat nie żartowałem. Tylko wiesz co… I zastanawiałem się jak na to… Zerknąłem sobie tam, to co się pojawia i o co chodzi z Postgresem i takie - z jednej strony to jest podśmiechujka, z drugiej strony administracyjnie to może być dość ciekawa rzecz. Jeżeli chodzi o rzeczy… extensiony do Postgresów. Extensiony i jakieś wszystkie dodatki administracyjne, wsparciowe, czyli np. tutaj recommended index for given SQL query.

Szymon Warda: Ja tak się trochę śmiałem, ale uważam, że ten pomysł jest genialny tak naprawdę, bo w tym momencie mamy wersjonowanie, mamy package’e, możemy je podpisywać, możemy je weryfikować dla usługi, która z reguły była zaniedbana. W sensie właśnie baza danych, jak ogólnie nie wiem czy Postgres. I której z reguły konfiguracja i instalacja to było po prostu ręczne klikanie w bardzo wielu przypadkach. Teraz już jest tego trochę mniej.

Łukasz Kałużny: W sumie tak, Oracle też się dość mocno klikało, tymi zdalnymi x-ami jak się instalowało.

Szymon Warda: Tam dużo naprawdę było tego klikania. Mimo wszystko. No nie, więc no podśmiechujka, ale to ma sens, ja się z tego cieszę tak na przykład.

Łukasz Kałużny: Jest tak znowu. Tylko żeby nie poszło w złą stronę, bo porównajcie do npma. Stąd…

Szymon Warda: Oraz…

Łukasz Kałużny: Stąd po prostu moje wiesz… DevDB fills the same role for Postgres as NPM for JavaScript.

Szymon Warda: Jakby tylko brali przykłady z czego innego.

Łukasz Kałużny: Potem jest PP Cargo, więc jest lepiej w przykładach. Ale dobra, jaki jest Twój kolejny link Szymon?

Szymon Warda: U mnie coś poważniejszego tak naprawdę. Znowu. Ciekawy link organizacyjny. O co chodzi? Chodzi o to, że tematy, których nikt nie lubi robić, ale czasami trzeba to ogarnąć, a jak to zostawimy HRom to będzie ogarnięte źle, no jak to często niestety bywa. Mianowicie LinkedIn wypuścił, dokładnie na swoim Engineering Blogu, wypuścili ciekawy artykuł, za chwilę pewnie będzie kręcenie oczami “O Jeezu”, ale co mierzą, mierzą Developer Productivity i Developer Happiness. No nie, i teraz… Ale zrobili to naprawdę ciekawie, bo w jaki sposób mierzą? Jeżeli chodzi o mierzenie productivity to mierzą effectiveness i efficiency. Effectiveness to jest generalnie - jaka jest szansa, że się uda ten projekt zrobić? Efficiency - jak szybko ten cel osiągniesz? Czyli bardzo dobre metryki, naprawdę proste.

Łukasz Kałużny: Są proste.

Szymon Warda: Tak.

Łukasz Kałużny: Czy się uda dowieźć, czy dowiozłeś. Koniec.

Szymon Warda: Tak. To są dwie metryki na mierzenie productivity. Teraz dużo trudniejszym jest happiness. Tak naprawdę. No bo to jest takie, no to…

Łukasz Kałużny: Właśnie, kurde…

Szymon Warda: Ilość owocowych śród czy tam czwartków? No niekonieczne!

Łukasz Kałużny: Raczej, to jest moim zdaniem wiesz, jak sobie popatrzysz na to zanim wejdziemy tam w artykuł i to jak oni określili to jest właśnie żeby zadbać o te developer happiness trzeba zadbać o developer experience. Po pierwsze. Tego na czym… Toolingu, narzędzi na których pracujesz, a drugie na tą część, którą trudniej spełnić to procedury organizacyjne. To nazwijmy. I flow organizacyjny.

Szymon Warda: I oni się skupili dużo bardziej de facto właśnie na niekoniecznie toolingu, ale tym o czym developer myśli developując tak naprawdę.

Łukasz Kałużny: Tak.

Szymon Warda: I jakie mają metryki, mierzą: Developer build time czyli czasu spędzonego na Buildy. Dla mnie super metryka, jak najbardziej, ciekawe jak to mierzą. To jest niezłe: Code review response time, super. Post-commit CI speed, bardzo dobra metryka, CI decommission, deployment success rate i net user satisfaction. To już jest takie typowe, żeby było coś miękkiego tak naprawdę, żeby się HR wykazało.

Łukasz Kałużny: Tak, to jest tak, dokładnie. Ale tak, jeżeli popatrzymy no to te metryki są bardzo przyjemne - raczej poza tą pierwszą, bo ja bym bardziej powiedział Developer Build Time, hmm…

Szymon Warda: A ja bym powiedział, że to jest jedna z najlepszych metryk, tylko nie mam pojęcia jak trzeba go mierzyć.

Łukasz Kałużny: Znaczy nie, wiesz co, tylko jest trudna, cholernie trudna do mierzenia, żeby była… Bo wiesz, to jest pytanie co oni rozumieją przez developer build time. Czy to jest pokłosie tego, że ściągają te informacje tak naprawdę z jobów CIowych? Ile trwa sama kompilacja? Czyli wiesz o co mi chodzi.

Szymon Warda: Właśnie nie, lokalny. Chodzi im tu o lokalny build i dlatego się mówi, że to jest super trudne do mierzenia. Znaczy inaczej - łatwe, bo de facto to można zmierzyć. To nie jest nic magicznego, ale musiałyby to wspierać narzędzia i musielibyśmy wspierać jakiś sposób na zbieranie tego, a to już zaczyna śmierdzieć taką no inwestygacją, bardzo mocną i śledzeniem ludzi.

Łukasz Kałużny: Bo bierzesz się, musisz, inaczej - to minimum musiałbyś w kompilatora, tam jeszcze powiedzmy, że jak jesteś w Javie albo w dotnecie to powiedzmy, że jesteś teraz na poziomie w stanie czasu kompilacji zrobić telemetrię.

Szymon Warda: Tak.

Łukasz Kałużny: Jakąś paczką swoją.

Szymon Warda: Właśnie to jest prosta telemetria, która… Metryka ogólnie byłaby bardzo użyteczna de facto, bo to jest czas, który idzie, no rozprasza i tak dalej, i tak dalej. Ale no właśnie to tak bardzo śmierdzi śledzeniem ludzi de facto i wyciąganiem z tego potem złych wniosków. Więc jestem strasznie ciekaw jak oni to zmierzyli, bo ma to bardzo sens.

Łukasz Kałużny: Wiesz co, tak, ma to sens. Przy czym dla większości świata ważniejszą metryką będzie post-commit CI speed, żebyś jak najszybciej dostawał pierwszy feedback z CI-a.

Szymon Warda: Wiesz co, wydaje mi się, że developerzy spędzają dużo więcej czasu na tych lokalnych. To najbardziej wkurzające. Jak debugujesz jakiś błąd albo jest w jakiejś dziedzinie to potrzebujesz, żeby ten projekt się szybko budował, a często to jest taki element gotowania tej żaby de facto, że ten czas z lokalnego buildu się wydłuża, wydłuża, wydłuża, wydłuża. Na te rzeczy CI-owe możemy dorzucić agentów, możemy dorzucić równoległość, pitu pitu, pitu pitu. A tu mówimy z reguły o laptopach, bo już mało kto siedzi na desktopach. No nie? I tego za bardzo nie zaadresujemy. To jest… Czasami może być taki dobry argument, załóżmy że kupmy mocniejszy sprzęt, bo przepalamy ileś godzin miesięcznie, ileśdziesiąt właśnie godzin miesięcznie, czasu developerów na budowaniu projektów. De facto, więc metryka mega użyteczna. Spójrzmy na jedną rzecz, wydaje mi się, że jak mówiliśmy parędziesiąt odcinków temu odnośnie tego, jak coraz więcej firm wchodzi w remote environmenty, dlatego żeby właśnie developerzy developowali na maszynach zdalnych w chmurze, to w tym momencie mierzenie tych metryk i optymalizowanie ich staje się super łatwe.

Łukasz Kałużny: I wiesz, to jest w to… Druga sprawa, jeżeli masz przykładowo wystandaryzowane buildy, na przykład takim Bazelem, który jest straszny w konfiguracji, ale jak już działa to działa świetnie, to wtedy masz możliwość też zbierania tych metryk. Tylko kurde, to jest raczej wiesz, po prostu patrząc się na to… Nie jest to zagadnienie, które… Każdy może sobie na to pozwolić.

Szymon Warda: To jest zagadnienie, które powinno być wspierane w narzędziach deweloperskich de facto i powinien być jakiś dobry pomysł na używanie tych metryk, na tą telemetrię, na wsparcie, żeby to było całkowicie zanonimizowane. De facto. Jakbyśmy tą opcję mieli, to wydaje mi się, że bardzo wartościowa metryka do posiadania.

Łukasz Kałużny: Dobra.

Szymon Warda: Ale tak, lean do rzucenia naprawdę warto, jest… Mimo, że on wydaje się długi, to tak naprawdę potem dalej już wchodzę jak oni to pokazują, już jest jak oni to mierzą wewnętrznie.

Łukasz Kałużny: Najważniejszy jest początek.

Szymon Warda: Tak, to jest… Pierwsze dwie strony de facto wchodzą. Można tam, powiedzmy sobie, no, ale fajne… Co tam jeszcze masz, Łukaszu?

Łukasz Kałużny: Dobrze, jeszcze przejdźmy sobie na chwilę do Kubernetesa, bo dojrzewa i ludzie dojrzewają. Pierwsza rzecz, z którą zgadzam się i nie zgadzam mocno, bo ekosystem… No raczej ktoś musiał to zrobić, więc Microsoft wyszedł przed szereg i powiedział, że Kubernetes 1.27 będzie w Azure wersją LTSową.

Szymon Warda: Dobrze.

Łukasz Kałużny: Czyli dostanie support na dwa lata, czyli z upgrade’em, potem do 1.33.

Szymon Warda: Długo.

Łukasz Kałużny: Dlatego mówię… I to jest ciekawe, bo Kubernetes się wygrzewa. To już jest ten moment wiesz, stabilności. Uważam, że tak - dla leniwych osób jest to w ogóle i do pewnych projektów będzie to zajebiste. Tylko z drugiej strony to, co widzę, jest… Pytanie - żyjąc w całym tym świecie podatności, zerodayów i innych rzeczy, które się rozgrywają. Wszystko fajnie, że będziemy mieli spatchowanego Kubernetesa, nasza apka będzie działała. Gorzej, jak weźmiemy, pójdziemy w ekosystem i wybierzemy sobie po tym, że na tym AKSie stawiamy narzędzia opensource’owe, które już do wersji Kubernetesa są przypięte i nagle się okaże, że fajnie, że dół mamy supportowany, ale góry no nie do końca możemy np. po roku zapgrejdować, bo z czymś nam będzie nagle kolidowało.

Łukasz Kałużny: I to jest właśnie ciekawa rzecz, bo jak weźmiemy sobie takiego AKS’a LTS, wtedy, weźmiemy ekosystem Microsoftu, weźmiemy od nich np. właśnie tego Ingress, kontroler z app gatewayem i innymi tymi rzeczami, no to dostaniemy całą taką wiesz, paczkę supportową, a tak nagle się okaże, że niby nie musimy apgrejdować dołu, a góra nam cieknie i płacze.

Szymon Warda: Jestem ciekawy, bo znowu - Znaczy mówimy sobie, że LTS jest fajny, bo to fajnie, ale teraz jak dużo bardziej skomplikowany będzie upgrade po dwóch latach.

Łukasz Kałużny: Tak.

Szymon Warda: Raczej to będzie masakra organizacyjna de facto.

Łukasz Kałużny: Wiesz co? Dlatego prawdopodobnie auto update’y razem z wcześniej auto validatorem. Czy nasze obiekty wszystkie będą zgodne czy nie? Będzie lepsza ścieżką dla większości.

Szymon Warda: Toolingu wokół Kubernetesa i wokół de facto hostowania.

Łukasz Kałużny: Jest za dużo.

Szymon Warda: Po prostu już taka ilość.

Łukasz Kałużny: Jest za dużo.

Szymon Warda: Ja widzę po tym co jest, nawet automatyczne upgrade’y, to mówimy de facto o spędzonym czasie co miesiąc, max co kwartał de facto żeby wszystko podbijać.

Łukasz Kałużny: Raczej inaczej, to tak trzeba tu… Może nie przesadzajmy. Jak ustabilizujesz i masz zmniejszony tooling to raz na pół roku robisz większe upgrade’y i tyle, a resztę przelatujesz automatem.

Szymon Warda: Wiesz co, ale ja w te upgrade’y wliczam też rzeczy platformowe de facto. Wliczam te całe obciążenie do zespołu platformowego potencjalnie jakiegoś, no nie? Czyli mówimy toolingu Kubernetesowego, potem mamy ten cały tooling do Observability i cały tooling do monitorowania, fluxy, helmy i wszystkiego…

Łukasz Kałużny: No tak ,to jest wiesz, jak…

Szymon Warda: Dlatego rośnie.

Łukasz Kałużny: Ja wiem, tylko jak na bieżąco upgrade’ujesz to w miarę to żyje. Dobra, wiesz co, chyba już skończmy na dzisiaj dyskusję.

Szymon Warda: Dobra.

Łukasz Kałużny: Tym wątkiem, że jest to wrzodem na dupie, bo jest to prawdą. I co…

Szymon Warda: Dobra, trzymajcie się.

Łukasz Kałużny: Na razie, hej.