Inżynierska prasówka
Przy okazji przeprowadzki na Substacka postanowiłem wydawać prasówkę co 3 wpisy. Więc to dzisiaj trafiają do Ciebie najciekawsze newsy z świata produktów cyfrowych.
Z racji, że zebrało się nieco więcej materiałów tematy podzieliłem na następujące kategorie:
Produkt
Inżynieria
Procesy
Miłego czytania 😊
Technologia
1. Modern Trade-off Analysis for Software Architecture - Neal Ford
Inżynierska prasówka bez Neala Forda to wydanie stracone😅
Pojawiły się już nagrania z DDD Europe, a wśród nich prezentacja Neala o analizie kompromisów w architekturze systemów. Neal jak zwykle w przystępny sposób opowiada o decyzjach architektonicznych:
jakie decyzje mają wpływ architektoniczny
na jakie kryteria zwracać uwagę
jak mitygować ryzyka
Dużo materiałów dookoła wzorców architektury, granularności serwisów i współpracy zespołowej.
Sam w organizowanych warsztatach Tech Lead wzoruję się na podejściu Neala, więc tym bardziej polecam nagranie.
2. Legacy Modernization meets GenAI
Zamiast obawiać się Generative AI, warto poznać techniki, które pomogą wdrożyć je do codziennej pracy.
U Martina Fowlera pojawił się artykuł Alessio, Tom i Shodhan o wykorzystaniu „sztucznej inteligencji” do wykonywania migracji systemu legacy w szerokiej skali.
Stworzone przez nich narzędzie CodeConcise łączy duży model językowy z grafem wiedzy na bazie kodu źródłowego. Pozwala to m.in.:
Wyciągać wymagania biznesowe z kodu.
Budować wysokopoziomowe opisy systemu.
Znajdować zduplikowane funkcje.
Usprawniać migrację między technologiami.
Najbardziej imponujące są wyniki - dla jednego z klientów skrócili czas analizy legacy z 6 do 2 tygodni. Przy dużych projektach migracyjnych to ogromna oszczędność.
Ten artykuł pokazuje, że AI to nie tylko generowanie kodu - może też pomóc nam lepiej zrozumieć istniejące systemy.
https://martinfowler.com/articles/legacy-modernization-gen-ai.html
3. Simon Brown - C4 model
O co chodzi? Przecież Model C4 od dawna jest znany w Internecie? 🤔
16 września Simon, twórca modelu C4, opublikował nową stronę internetową C4. Znajdziecie tam:
Bardziej przystępną strukturę pozwalającą łatwiej wprowadzać nowe osoby.
Większą ilość materiałów o zastosowaniu modelu C4.
Mnóstwo nowych zasobów – narzędzia, diagramy, nagrania.
Z racji, że to mój domyślny sposób dokumentowania architektury to nie mogłem tej aktualizacji pominąć 😉
https://c4model.com/
4. Vercel Functions z in-function concurrency
Jeśli ktoś mnie zna, to wie, że w moim sercu jest specjalne miejsce na serverless. Dlatego ucieszyłem się tak bardzo na tę wieść od Vercel.
Firma właśnie ogłosiła publiczną betę swojego nowego rozwiązania, które może zmienić podejście do funkcji serverless. Kluczowe punkty to:
Wprowadzenie in-function concurrency - jedna instancja funkcji może obsługiwać wiele wywołań
20-50% redukcji w wykorzystaniu zasobów i kosztach bez wpływu na opóźnienia
Optymalizacja szczególnie dla interaktywnych workloadów (server-rendering, API, aplikacje AI)
Jak to działa:
Tradycyjny model Lambda - jedna instancja = jedno wywołanie.
Nowy model Vercel - wykorzystanie "czasu bezczynności" do obsługi kolejnych requestów.
Przykład: żądanie trwające 100ms (50ms compute + 50ms czekanie) może być współdzielone.
Dzięki temu uzyskamy wyższą efektywność wykorzystania zasobów = niższe koszty bez zmian w kodzie. Dodatkowo w pełni wykorzystamy możliwości Node.js w zakresie współbieżności.
Ciekawi mnie jak odpowie na to AWS 🔎
https://vercel.com/blog/serverless-servers-node-js-with-in-function-concurrency
5. DHH on Competency, Coding, Children
Można DHH nie lubić, ale nie można zaprzeczyć, że jest jedną z najbardziej wpływowych osób w świecie oprogramowania.
W ramach podcastu u Prime’a otrzymujemy ponad 2-godzinną rozmowę poruszającą przekrojowe tematy programistyczne:
Sceptycyzm wobec nowych technologii i wykorzystywaniu stabilnych, dojrzałych rozwiązań
Podejście „no-build” na frontendzie – dlaczego np. nie potrzebujemy tych wszystkich bundlerów.
Sztucznej inteligencji w rozwoju i utrudnieniu w nabieraniu kompetencji.
Rola open-source jako wyróżnika dla juniorów przy rozpoczynaniu kariery.
DHH porusza także miękkie tematy, takie jak wpływ rodzicielstwa na bycie lepszym programistą.
Niezwykle ciekawie się tego słucha – DHH ma sinusoidalny ton odpowiedzi i niekiedy mówi z tak ogromną pasją, że prawie krzyczy. Nie sposób się od tego oderwać – nawet jak się nie zgadzamy 😅
Procesy
1. Why context and culture matter in leading with objectives - Afonso Franco
Często wprowadzając zmiany mamy duże założenia. Niestety ostatecznie wszystko rozbija się o czynnik ludzki. Alfonso podaje powody, dla których tak może się dziać.
Główny winowajca to różnice w kontekstach i kulturze. Mamy inne poziomy seniorstwa, kompetencje, doświadczenie. Byliśmy wychowywani w różnych normach. Inne aspekty i cele są dla nas istotne.
Praca w grupie to nawigowanie pomiędzy tymi różnicami i dochodzenie do konsensusu.
2. Friction can be your friend – John Cutler
Krótki wpis od Johna o tym jak friction - „opór rzeczywistości” pozwala nam lepiej pracować nad dostarczaniem produktów cyfrowych.
Widzę tutaj dużo odniesień do mechanizmów pracy zespołowej:
Jak minimalizować WiP przez zmuszanie do kończenia zadań.
Jak unikać zaciągania długu technologicznego przez stały punkt w dyskusji o kosztach długoterminowych.
Jak dodatkowa kolumna na analizę wpływu funkcji każe nam się zastanowić, czy to co dowieźliśmy w ogóle ma sens.
3. The Myth of the 'Missing' Remote Work Culture – Erin Casali
Podobno nie da się zbudować kultury w firmie zdalnej. Erin przekonuje nas jednak, że jest inaczej.
Autor, na podstawie wielu lat doświadczeń, pokazuje, że jest to możliwe, ale wymaga zmiany podejścia. W strukturach firmy zdalnej wiele aspektów kulturowych trzeba robić nieco „na siłę” – z racji, że nie tworzą się naturalnie, jak to ma miejsce w firmie całkowicie pracującej na miejscu.
Przytaczam kilka praktycznych wskazówek jak budować kulturę w zespołach zdalnych:
Organizowanie warsztatów zespołowych ustalających zasady i wartości
Wyraźne rozdzielenie czasu na pracę i socjalizację.
Automatyzacja "społecznych" wiadomości (np. przez Donut).
Regularne aktywności integracyjne (np. miesięczne "Connect").
Spotkania 1:1 budujące relacje.
Organizacja spotkań na żywo (np. kwartalnych).
Świetny artykuł dla managerów zespołów zdalnych - konkretne porady i realistyczne podejście do tematu. Sam niedawno pomagałem zespołowi 100% zdalnemu i wiem, że kulturę da się tworzyć, ale trzeba to robić celowo.
https://intenseminimalism.com/2024/the-myth-of-the-missing-remote-work-culture/
4. The Science Behind Team Cognitive Load and Why It Matters - Laura Weis & Aleix Morgadas
Na YouTube pojawiły się nagrania z FastFlowConf, w tym świeżynka z Laurą i Aleix.
Autorzy przedstawiają naukowe założenia stojące za przeładowaniem kognitywnym. Następnie przechodzą do praktyki, omawiając sposób, w jaki wpływa to na zespół.
Podoba mi się tu szczególnie kategoryzacja od Laury odnośnie różnych driverów zwiększających cognitive load.
Ważne wnioski od Aleix – o tych problemach trudno mówić w sposób czysto techniczny. Potrzebny jest pierwiastek ludzki i ocena prywatna tego, jakie problemy odczuwamy pracując w zespole.
Zauważysz pewnie logo Teamperature - parafrazując klasyka „zawsze się trochę sprzedaje” 😉
Produkt
1. The Role of Engineering in Product Transformation - Mirek Stanek
Treść na styku produktu i inżynierii 😃
Mirek na swoim substacku opisuje przemyślenia po przeczytaniu książki Transformed Martiego Cagana.
Bardzo spójne i wnikliwe przeniesienie kwestii produktowych na świat inżynierski, czyli jak musimy zmienić nasze podejście do:
Budowania rozwiązań
Rozwiązywania problemów biznesowych na podstawie technologii
Podejmowania decyzji, które problemy należy rozwiązać
Masa polecanych praktyk jak Continuous Delivery, Staged Rollout, Observability, Tech Strategy.
Po raz kolejny pokazuje, że aby dobrze dowozić produkt trzeba być 10/10 w kwestiach inżynierskich.
2. Are Product Owners Too Much Overhead? - Maarten Dalmijn
Po swoim viralowym artykule o Scrum Masterach, Maarten Dalmijn analizuje tym razem rolę Product Ownerów. Wskazuje 3 sytuacje, gdzie PO mogą być zbędnym balastem:
PO i Product Manager pracujący razem - dodatkowa warstwa komunikacji zamiast rozwiązania problemów.
Jeden PO na zespół - albo się nudzi, albo świadczy o problemach wymagających ciągłego "trzymania za rękę".
PO dla zespołu komponentowego - techniczny komponent to nie produkt.
Główne tezy Maartena:
Nie potrzebujemy Product Ownerów, potrzebujemy Product Managerów.
Dodawanie warstw zarządzania utrudnia zespołom przejęcie odpowiedzialności.
Należy zmniejszać dystans między zespołami a klientem/biznesem.
Bardzo mocno rezonuje to ze mną przez bliskość do tematów dookoła Large-Scale-Scrum i poszerzania zakresu produktu. Krzysiek Niewiński pewnie by przyklasnął 😃
