Witajcie w kolejnym odcinku Microsoft Knowledge Nugget na M365FM. Nazywam się Mirco Peters i jestem Waszym gospodarzem. Dzisiejszy temat to coś, o czym prawie każdy słyszał, ale mało kto naprawdę rozumie, inżynieria platformy. Prawdopodobnie słyszeliście o DevOps, idei płynnej współpracy programistów i zespołów operacyjnych, ale po drodze ta obietnica stała się problematyczna. Programiści zaczęli wykonywać pracę operacyjną, co doprowadziło do załamania systemu. Pod koniec tego odcinka zrozumiecie, co poszło nie tak z DevOps, czym właściwie jest wewnętrzna platforma programistyczna, jak złote ścieżki wyznaczają zespołom jasny kierunek i dlaczego najzdolniejsze zespoły inżynierskie już je tworzą. Bałagan, który pozostawił po sobie DevOps. Wróćmy do początków. DevOps był świetnym pomysłem z prostym celem zburzyć mury między programistami a zespołami operacyjnymi. Koniec z przerzucaniem kodu przez płot i liczeniem na najlepsze.

Przesunięcie w lewo, wdrożenie testów bezpieczeństwa i operacji na wcześniejszy etap procesu. Szybsze dostarczanie, mniej przekazywania zadań, większa odpowiedzialność. Na papierze wyglądało to idealnie. W praktyce coś poszło nie tak. Przesunięcie w lewo nie tylko zmieniło zakres obowiązków, ale wręcz je przytłoczyło. Programista, który kiedyś pisał kod i zgłaszał ticket, teraz odpowiada za infrastrukturę, bezpieczeństwo, monitoring, kubernetes, potoki C, CD, zarządzanie sekretami i około 15 usług chmurowych, o których wcześniej nie słyszał. Jedna osoba zajmuje się tym wszystkim, jednocześnie tworząc właściwy produkt. Oto jak wygląda to w prawdziwym życiu. Zespół chce uruchomić nowe środowisko, aby przetestować funkcje. Przed DevOps zgłosiliby ticket i czekali. Po DevOps zajmują się tym sami, co w teorii brzmi świetnie, ale teraz muszą pisać moduły Terraform, konfigurować klaster kubernetes, ustawiać reguły sieciowe, podłączać monitoring, ogarniać zarządzanie sekretami i pilnować stosowania polityk bezpieczeństwa.

To, co kiedyś było zgłoszeniem zajmującym komuś godzinę, teraz pochłania trzy dni pracy programisty. Trzy dni, podczas których nie piszą kodu produktu. Walczą z plikami YAML i debugują, dlaczego load balancer nie kieruje ruchu prawidłowo. Obciążenie psychiczne jest ogromne. Każdy zespół kończy budowaniem własnych potoków, skryptów wdrożeniowych i pulpitów monitoringu. A ponieważ wszyscy są przeciążeni, zaczynają iść na skróty. Bezpieczeństwo jest pomijane, bo termin mija w piątek. Rachunki za chmurę podwajają się niezauważenie, bo nikt nie pamiętał o wyłączeniu środowiska testowego. A gdy coś zepsuje się o drugiej w nocy, tylko programista, który to zbudował, jest w stanie to naprawić. To nie jest zrównoważone i oto, dlaczego ma to dziś większe znaczenie niż kiedykolwiek. Złożoność chmury stale rośnie. Z każdym rokiem przybywa usług, narzędzi i decyzji do podjęcia. Narzędzia i pozwalają programistom tworzyć kod szybciej niż kiedykolwiek, 10, 20, a nawet 30 razy szybciej każdego dnia.

Jednak cały ten kod nadal wymaga infrastruktury, bezpieczeństwa i monitorowania. Więcej kodu bez lepszego systemu oznacza tylko szybszy chaos. Jeśli czujesz, że toniesz w plikach YAML i Terraform, nie jesteś sam. To nie jest Twoja osobista porażka. To problem systemowy. Ten model zepsuł to, czym faktycznie jest inżynieria platformy. Więc jak to naprawić? Rozwiązaniem jest inżynieria platformy, a oto najprostszy sposób, by o tym myśleć. Ta dyscyplina tworzy wewnętrzną warstwę, która przejmuje złożoność za programistów. Wyobraź sobie, że wchodzisz do dużego biurowca. Nie musisz się martwić, kto ma dostęp do którego piętra, która karta dostępu działa, ani gdzie są wyjścia ewakuacyjne. Recepcja zajmuje się tym za Ciebie, a Ty po prostu wchodzisz i bierzesz się do pracy. Dokładnie to inżynieria platformy robi dla Twoich programistów. Zamiast wymagać od każdego programisty bycia ekspertem od Kubernetes, Terraform, sieci i bezpieczeństwa, centralny zespół tworzy warstwę zarządzającą tą złożonością.

Programista otrzymuje prosty interfejs, klika przycisk, uruchamia polecenie, wypełnia formularz, a platforma zajmuje się resztą. Ale jest pewien haczyk, to nie to samo co DevOps. DevOps zakładał, że każdy zespół odpowiada za własną infrastrukturę, ale inżynieria platformy ostrzega, że to prosta droga do wypalenia. Zamiast tego zespół platformowy zapewnia wybrukowane ścieżki, standardowe, przetestowane i bezpieczne sposoby obsługi typowych zadań. Oni budują i utrzymują drogę, a zespoły produktowe po prostu nią jadą. Głównym efektem inżynierii platformy jest tak zwana wewnętrzna platforma programistyczna, w skrócie IDP. Pomyśl o niej jako o samoobsługowym systemie, który automatyzuje powtarzalną pracę. Provisioning infrastruktury, potoki C, CD, testy bezpieczeństwa, monitoring, wszystko wbudowane i ustandaryzowane. Oto konkretny przykład, gdy programista chce wdrożyć nową usługę bez platformy, spędza dni na konfiguracji infrastruktury, pisaniu potoków i ustawianiu monitoringu.

Dzięki IDP wystarczy kliknąć wdroż lub wpisać jedno polecenie, a platforma zajmuje się wszystkim provisioningiem, testami i deploymentem w minuty zamiast dni. Co to oznacza dla Ciebie? Przestajesz być specem od wszystkiego w infrastrukturze i stajesz się specjalistą od swojego produktu. Twoja praca wraca do tworzenia funkcji ważnych dla klientów zamiast debugowania błędów w plikach Terraform. Oto właśnie w tym wszystkim chodzi. Wewnętrzna platforma programistyczna w prostych słowach. Rozbijmy więc na części pierwsze, czym właściwie jest wewnętrzna platforma programistyczna. To silnik, który łączy wszystko w jeden system. Twoje potoki C, CD, szablony infrastruktury, zasady bezpieczeństwa, monitoring i logowanie. Zamiast sześciu osobnych narzędzi, które musisz łączyć. Oto pewna analogia. Pomyśl o tym, jak o gotowaniu od podstaw w porównaniu do korzystania z automatu z przekąskami. Gotowanie od podstaw to kupowanie składników, krojenie warzyw, odmierzanie przypraw, pilnowanie kuchenki.

Mnóstwo decyzji, mnóstwo kroków, mnóstwo sposobów, by coś zepsuć. Automat z przekąskami daje Ci wynik za naciśnięciem jednego przycisku. Mniej decyzji, szybszy rezultat, stała jakość. IDP to właśnie taki automat. Deweloper nie musi wiedzieć, jak udostępniana jest infrastruktura, ani gdzie przechowywane są sekrety. Po prostu naciska przycisk. Co znajduje się w tym automacie? Główne komponenty są dość standardowe. Szablony Ci, CD dla spójnych kompilacji, udostępnianie infrastruktury do automatycznego tworzenia środowisk, bezpieczne przechowywanie danych, by hasła nie krążyły w plikach konfiguracyjnych oraz logowanie z wbudowaną obserwowalnością, dzięki czemu możesz rozwiązywać problemy bez paniki. Wszystko to jest wstępnie skonfigurowane, przetestowane i utrzymywane przez zespół platformy. Oto konkretny przykład. Deweloper wpisuje utwórz nową usługę w wierszu poleceń lub klika przycisk w portalu.

W tle IDP uruchamia nowe repozytorium z odpowiednią strukturą, ustawia potok kompilacji, który automatycznie uruchamia testy, wdraża usługę w środowisku programistycznym i dodaje punkty końcowe kontroli stanu z logowaniem. Wszystko to dzieje się w kilka minut. Deweloper nie dotknął ani jednego pliku Terraform, ani nie skonfigurował manifestu Kubernetes. Po prostu wpisał polecenie i otrzymał działającą usługę. Dlaczego to jest ważne? Kluczowym powodem jest spójność. Kiedy każdy zespół buduje własne potoki i pisze własne skrypty wdrożeniowe, kończysz z unikalnymi konfiguracjami. 50 różnych usług, 50 różnych sposobów działania. Gdy coś się psuje, nikt nie może tego naprawić poza osobą, która to stworzyła. A jeśli ta osoba odeszła z firmy, życzymy powodzenia. IDP eliminuje to, sprawiając, że każda usługa podąża za tymi samymi wzorcami, każde wdrożenie używa tego samego potoku, a każdy zespół otrzymuje te same ustawienia domyślne.

Kiedy coś się psuje, wzorce są znane, a rozwiązanie jest udokumentowane. Więc oto co to oznacza dla Ciebie. Jeśli Twoja organizacja ma 50 zespołów robiących wdrożenia na 50 różnych sposobów, IDP jest rozwiązaniem. Nie oznacza to, że zespoły tracą autonomię. Oznacza to, że nudne, powtarzalne i podatne na błędy elementy są standaryzowane, więc interesująca, kreatywna praca może być zróżnicowana. To kompromis, który warto podjąć. Złote ścieżki to kierunek, a nie klatka. Porozmawiajmy o złotych ścieżkach. Prawdopodobnie słyszałeś tę nazwę, ale idea jest prosta. Złota ścieżka to zalecany, gotowy przepływ pracy, który sprawia, że właściwe działanie jest najłatwiejsze do wykonania. Twój zespół platformy mówi o to, jak sugerujemy to zrobić. Przetestowaliśmy to, działa i usprzemy Cię, jeśli coś pójdzie nie tak. Zwróć uwagę na słowo, sugerujemy. Złote ścieżki nie są obowiązkowe. Programiści mogą zejść ze ścieżki, jeśli muszą, ale to ona jest szybkim i bezpiecznym domyślnym wyborem.

Jest już uruchomiona, wspierana i udokumentowana. Nie musisz wymyślać wszystkiego od zera. Pomyśl o tym, jak o torach kolejowych, a nie barierkach ochronnych. Barierki łapią Cię, gdy masz wypadek. Reagują, chronią przed upadkiem w przepaść, ale nie pomagają w sterowaniu. Tory kolejowe prowadzą Cię płynnie wzdłuż trasy, więc nie musisz decydować, gdzie skręcić. Złote ścieżki to właśnie te tory. Popychają Cię do przodu, zamiast tylko łapać, gdy popełnisz błąd. W tym miejscu wiele zespołów popełnia błąd. Tworzą złote ścieżki dla zespołu platformy, a nie dla programistów. Optymalizują pod kątem czystości architektury, zgodności z wymogami bezpieczeństwa lub wewnętrznych zasad, których nikt spoza zespołu platformy nie rozumie. Efekt wygląda świetnie na tablicy, ale używa się go fatalnie. Programiści po cichu szukają obejść adopcja, spada, a zespół platformy zastanawia się, dlaczego nikt nie docenia ich wysiłku.

Rozwiązanie jest proste, ale trudne do wdrożenia. Potrzebujesz wyjść awaryjnych. Jeśli ścieżka nie pasuje do potrzeb programisty, musi mieć on drogę ucieczki. Sposób na nadpisanie ustawień domyślnych, użycie własnego potoku lub całkowite wyjście poza platformę. I to jest najważniejsza część. Kiedy ktoś schodzi ze ścieżki, to nie porażka, to informacja zwrotna. Za każdym razem, gdy programista opuszcza złotą ścieżkę, mówi Ci coś istotnego. Albo ścieżce brakuje funkcji, którą powinna mieć, albo dany przypadek użycia tam po prostu nie pasuje. Oba sygnały są wartościowe. Dobra złota ścieżka w praktyce wygląda tak. Zespół chce wdrożyć nową usługę back-endową. Korzystają ze ścieżki. Dostają repozytorium z szablonem o właściwej strukturze, standardowy potok C-CD, który jest już przetestowany, wbudowane logowanie i monitorowanie oraz wycofywanie zmian jednym kliknięciem. Całość zajmuje minuty zamiast dni, a ponieważ zespół platformy utrzymuje ścieżkę, gdy coś się zepsuje, oni to naprawiają.

Programista nie musi stawać się ekspertem od debugowania potoków. Co to oznacza dla Ciebie? Mniej niespodzianek. Dostarczasz szybciej, ponieważ ścieżka jest przetestowana. Dostarczasz bezpieczniej, ponieważ bezpieczeństwo i monitorowanie są wbudowane. Dostarczasz z pewnością, ponieważ wycofanie zmian to jedno kliknięcie. Ścieżka istnieje, by Ci pomóc, a nie Cię ograniczać. Używaj jej. Zmniejszenie obciążenia poznawczego. Tutaj pojawiają się prawdziwe korzyści. Kiedy platforma przejmuje najcięższą pracę, programiści mogą wreszcie skupić się na kodzie. Nie muszą wiedzieć, jaka wersja Kubernetes jest aktualnie uruchomiona. Nie muszą aktualizować modułów Terraform za każdym razem, gdy dostawca chmury zmienia API. Po prostu tworzą funkcjonalności. Inżynierowie platformy przejmują na siebie tę złożoność. Decydują, co programiści muszą widzieć, a co powinno pozostać ukryte. To świadoma decyzja projektowa, a nie tylko techniczna.

Chodzi o ustalenie, które szczegóły są ważne dla użytkownika platformy, a które tylko wprowadzają zamęt. Oto konkretny przykład. Programista wdrażający nową usługę nie przejmuje się rozmiarem węzłów klastra, typami instancji czy progami autoskalowania. Interesuje go tylko to, czy jego usługa działa i jak szybko odpowiada. Dlatego platforma wstępnie konfiguruje to wszystko w oparciu o poziom aplikacji. Mała usługa oto odpowiednia konfiguracja. Usługa o dużym natężeniu ruchu oto inna konfiguracja. Programista nie dokonuje tych wyborów, bo po prostu nie musi. Dlaczego to jest ważne? Ponieważ ryzyko wypalenia spada, gdy programiści nie muszą żonglować 15 sprawami naraz. Niektóre dojrzałe zespoły platformowe zmniejszyły obciążenie poznawcze o prawie połowę. O 40-50% mniejszy wysiłek umysłowy. To ogromna zmiana. To różnica między wyjściem z pracy z energią, a wpatrywaniem się w terminal o 22 i zastanawianiem się, dlaczego potok zawiódł.

Ale uwaga! Nie twórzcie iluzji. Niektóre zespoły platformowe wpadają w pułapkę. Ukrywają ustawienia, nie dając programistom żadnego sposobu na zrozumienie tego, co dzieje się pod maską. To nie jest abstrakcja. To sztuczka, która mści się, gdy tylko coś pójdzie nie tak. Programiści trafiają na mur, przez który nie widzą i nagle platforma staje się czarną skrzynką działającą przeciwko nim. Termin na to to nieszczelna abstrakcja. Ukrywasz złożoność, ale w końcu ta złożoność i tak wypływa na wierzch. Baza danych zwalnia, wdrożenie kończy się niepowodzeniem, polityka bezpieczeństwa blokuje coś niespodziewanego. A programista nie ma modelu mentalnego tego, co się dzieje, bo platforma nigdy mu go nie dostarczyła. Przejrzystość ma znaczenie. Pokazuj programistom to, co muszą wiedzieć dokładnie wtedy, gdy muszą to wiedzieć. Nie ukrywaj wszystkiego, licząc na łód szczęścia. Co to oznacza dla ciebie?

Mniej przełączania kontekstu i więcej stanu flowu. Nie zaczynasz dnia od zastanawiania się, czy klaster Kubernetes wymaga aktualizacji, tylko pracujesz nad funkcją, która ma być gotowa za tydzień. Twoja praca staje się na powrót twoją prawdziwą pracą. Traktowanie platformy jak produktu. Dzisiaj rozmawiamy o czymś, co zmienia sposób działania wewnętrznych narzędzi. Większość ludzi myśli, że zespół platformowy to tylko zespół infrastruktury. Tak nie jest. Zespół platformowy to zespół produktowy, a programiści korzystający z tej platformy to ich klienci, a nie osoby zgłaszające tikety. To zmienia wszystko. Zespół produktowy rozmawia ze swoimi klientami, odkrywa co jest dla nich prawdziwym problemem, priorytetyzuje funkcje w oparciu o realne potrzeby, mierzy adopcję, nie budują czegoś, by potem o tym zapomnieć. Oni ciągle iterują. Jak więc zespół produktowy wygląda w praktyce? Nie działają jak helpdesk.

Programista wysyła zgłoszenie, a zespół platformy wykonuje je ręcznie. To nie jest inżynieria platformy, to tylko scentralizowane operacje pod nową nazwą. To się nie skaluje, nie zmniejsza obciążenia poznawczego, jedynie przenosi wąskie gardło z jednego zespołu do drugiego. Oto co robią zamiast tego. Mierzą właściwe rzeczy. Czas do pierwszego wdrożenia, szybkość onboardingu nowych członków zespołu, wskaźniki satysfakcji programistów. To metryki, które mówią, czy platforma faktycznie pomaga ludziom, czy tylko dodaje kolejną warstwę złożoności. Spotify jest dobrym przykładem. Ich zespół platformy działa jak prawdziwa organizacja produktowa. Mają mapy drogowe, cele okr, rozmawiają z programistami o tym, co działa, a co nie. Traktują platformę jako coś, co musi zasłużyć na adopcję każdego dnia i to jest główna idea. Platforma, której nikt nie używa, to tylko projekt, który zbiera kurz w koncie.

Adopcja jest ostatecznym sprawdzianem. Jeśli programiści wybierają Twoją platformę, zamiast tworzyć własne narzędzia, udało Ci się. Jeśli jej unikają, żadna techniczna doskonałość tego nie naprawi. Co to oznacza dla Ciebie? Oznacza to, że jeśli budujesz platformę, nie zaczynaj od diagramów architektury, plastrów Kubernetes czy modułów Terraform. Zacznij od wywiadów z użytkownikami, porozmawiaj z programistami, którzy będą z niej korzystać. Dowiedz się, co jest naprawdę bolesne. Zbuduj jedną rzecz, która rozwiązuje realny problem, a potem iteruj. W ten sposób buduje się coś, czego ludzie rzeczywiście chcą używać. Dlaczego właśnie teraz? Fala AI. Dlaczego więc rozmawiamy o tym właśnie teraz? Dlaczego nie 5 lat temu? Odpowiedzią jest sztuczna inteligencja. Narzędzia AI do kodowania, jak GitHub Copilot, pozwalają programistom dostarczać kod w tempie, którego nigdy wcześniej nie widzieliśmy. 10-20 razy więcej kodu dziennie niż to, co było możliwe jeszcze kilka lat temu.

Brzmi to niesamowicie i tak jest. Ale jest haczyk. Cały ten kod wciąż potrzebuje infrastruktury. Wciąż potrzebuje bezpieczeństwa. Wciąż musi być wdrażany, testowany i obsługiwany. Więcej kodu bez lepszego systemu nie czyni Cię szybszym. Po prostu przyspiesza chaos. Jeśli Twoi programiści już toną w plikach YAML i Terraform, a i tego nie naprawi. Oznacza to tylko, że toną szybciej, tworząc jednocześnie więcej kodu, który wymaga wsparcia. Obecnie około 55% organizacji wdrożyło już inżynierię platform w jakiejś formie. Gartner przewiduje, że do końca 2026 roku Litbata osiągnie 80%. To nie jest powolny trend. To zmiana, która dzieje się właśnie teraz. Firmy zdają sobie sprawę, że nie mogą skalować zespołów inżynierskich bez warstwy platformowej. Stare podejście, w którym każdy zespół robi wszystko sam, nie sprawdza się przy dostarczaniu kodu w tempie AI. Oto coś, co wielu ludziom umyka. AI nie tylko stwarza potrzebę posiadania platform.

Pomaga też w ich budowaniu. Zespoły platformowe używają AI do generowania modułów Terraform, pisania dokumentacji i debugowania potoków. Ta sama technologia, która wywołuje pilną potrzebę, dostarcza też narzędzi do jej zaspokojenia. Teraz słowo ostrzeżenia. AI wzmacnia wszystko, co już posiadasz. Jeśli Twoje fundamenty są solidne, jak dobra architektura i dobrze zaprojektowana platforma, AI zwiększa produktywność dwu- lub trzykrotnie. Ale jeśli fundamenty są słabe, AI tylko pomaga szybciej popełniać większe błędy. Złe konfiguracje, luki w zabezpieczeniach, niedziałająca infrastruktura, wszystko trafia na produkcję, zanim ktokolwiek to zauważy. AI nie naprawia słabych fundamentów. Ona je obnaża. Oto prawdziwy przykład. Firma z dobrą wewnętrzną platformą programistyczną pozwala nieinżynierom bezpiecznie wdrażać narzędzia AI. Platforma zapewnia zabezpieczenia. Wymusza politykę bezpieczeństwa.

Zarządza infrastrukturą. Dzięki temu Product Manager może uruchomić prototyp oparty na AI bez potrzeby rozumienia Kubernetes czy sieci chmurowych. To potężne narzędzie. To właśnie odróżnia zespoły gotowe na era i od tych, które zostaną w tyle. Co to oznacza dla Ciebie? Okazja do zbudowania platformy właśnie się zamyka. Nie dlatego, że technologia znika, ale dlatego, że przepaść między zespołami z platformami, a tymi bez nich szybko się powiększa. Z każdym miesiącem zwłoki zespoły posiadające platformy zyskują coraz większą przewagę. Wdrażają szybciej, mniej się wypalają i szybciej adaptują nowe narzędzia. Zespoły bez platform zostają coraz dalej w tyle. Wybór należy do Ciebie. Zacznij od jednej, złotej ścieżki. Więc od czego właściwie zacząć? Jeśli myślisz, że musisz zbudować całą wewnętrzną platformę programistyczną od zera, przestań. To najszybszy sposób, by zabić projekt, zanim się zacznie.

Największym błędem zespołów jest próba zbudowania wszystkiego naraz. Spędzają miesiące na projektowaniu idealnej platformy, upychając w niej każdą możliwą funkcję. Potem ją uruchamiają i panuje cisza. Nikt jej nie używa. Dlaczego? Bo rozwiązuje problemy, o które nikt nie prosił, a rozpoczęcie pracy wymaga przeczytania małego podręcznika. Oto rada, nie rób tego. Zamiast tego zacznij od małych kroków. Rozmawiaj z programistami, nie z architektami, menedżerami czy własnymi założeniami. Znajdź osoby, które każdego dnia tworzą nowe funkcje. Zapytaj ich, co sprawia im trudność. Znajdź proces, który trwa najdłużej i rytuje najwięcej osób lub jest zbyt często pomijany. Następnie zbuduj jedną, w pełni funkcjonalną, złotą ścieżkę. Może to tworzenie i wdrażanie nowego mikroserwisu. Może to konfiguracja środowiska programistycznego od zera. Może to szybka poprawka na produkcji bez psucia czegokolwiek.

Wybierz to, co najbardziej doskwiera i zbuduj ścieżkę, która usunie ten problem. Zbuduj to, przetestuj z użytkownikami, zbierz opinię i ulepszaj. Potem dodaj kolejną ścieżkę i następną po niej. Nie próbuj rozwiązywać wszystkich problemów naraz. Rozwiąż jeden problem naprawdę dobrze i pozwól, by rozpęd poniósł cię dalej. Skąd wiadomo, że to działa? Mierz właściwe rzeczy. Czas od pomysłu do wdrożenia, liczbę wyeliminowanych kroków ręcznych i wskaźniki dobrowolnej adopcji. Jeśli programiści wybierają twoją ścieżkę zamiast własnych rozwiązań, wygrywasz. Jeśli jej unikają, posłuchaj ich i zmień kierunek. Oto pułapka, której należy unikać. Nie sprawiaj, by platforma była obowiązkowa. Zmuszaj programistów do korzystania ze ścieżki, a poczują niechęć. Znajdą sposoby, by ją obejść. Stworzą własne skrypty i będą je przed tobą ukrywać. Zamiast tego spraw, by ścieżka była łatwa. Niech będzie szybsza niż alternatywy.

Spraw, by była oczywistym wyborem, ale nigdy jedynym. Pierwsza ścieżka jest zawsze najtrudniejsza. Uczy cię wszystkiego o myśleniu produktowym. Uczysz się rozmawiać z użytkownikami, priorytetyzować i rozumiesz, że tworzenie czegoś, czego ludzie chcą, jest trudniejsze niż tworzenie czegoś, co po prostu działa. Gdy zrobisz to raz, druga ścieżka będzie łatwiejsza, a trzecia jeszcze bardziej. Nie budujesz platformy za jednym zamachem. Budujesz ją krok po kroku, ścieżka po ścieżce. Oto cały system. Inżynieria platformy polega na utwardzaniu drogi, by programiści mogli skupić się na jeździe, a nie na łataniu dziur. Jeśli masz dość walki z infrastrukturą, zacznij od znalezienia jednej złotej ścieżki w swoim zespole, tylko jednej. Udostępnij to komuś, kto musi to usłyszeć i zasubskrybuj, aby otrzymywać więcej takich analiz.