CTO Morning Coffee

Dzień dobry.

Dzień dobry.

Wszystkiego dobrego.

Udało się zebrać na kolejne brew.

Ja mam kawę jak zwykle w tym szarym kubku po maratonie.

Tomek Onyszko, gość rozprowadzający, Sebastian Gębski, człowiek, który wie wszystko i ma opinie, Wojtek Ptak.

Wojtek, ty jesteś na sali szpitalnej?

Nie, dzisiaj z biura, bo mam mieszkanie w mini remoncie.

Ale ładna zasłonka.

City of Morning Brew, miejsce gdzie wyrażamy opinie, komentujemy.

Dzisiaj będziemy komentować kilka rzeczy.

Jak ktoś jest pierwszy raz, niech sprawdzi opis na dole.

Tam mamy jakieś linki, prowadzimy też sobie podcast City of Morning Coffee.

A tutaj nieuczasane, niepoukładane własne i czasami niepoprawne opinie na rzeczy bardziej bieżące.

Panowie już się szykują.

To może tak o rzeczach bardzo bieżących zacznijmy.

Apple miały event taki.

Oni mają takie eventy, raz mają taki event, potem taki, potem taki.

W pierwszym evencie rozmawialiśmy w pierwszym brewu.

I dalej nie widać nic z tym produktem.

O właśnie, nic się nie pokazali więcej.

Chociaż trochę pokazali.

O właśnie, to jest to trochę, taki mały glimps.

Bo był event odnośnie iPhona i nawet nie chcę was spytać o iPhona, ale chciałem was zanim przejdziemy dalej o jedną taką rzecz, bo wszyscy narzekają, że ten nowy iPhone to taki sam jak poprzedni.

I że Apple się skończył na Killemall albo na iPhone X. I że w ogóle po roku R&D ucięli 1 mm i że ekran ma nie takie herce i tak dalej.

I że w ogóle Android to tam jest lepszy.

Ale to tych odetniemy.

Ja tak to obserwowałem trochę.

Jakby nie patrzeć, Apple jest jednak tą firmą, która coś tam robi, ma dużą waluację, jakoś kształtuje rynek.

To co myślicie?

Czy oni jeszcze muszą produkować lepsze iPhony?

No zawsze będą musieli.

Bo mimo wszystko przyzwyczaiłeś do czegoś użytkowników, więc jakieś oczekiwania będą.

Ludzie oczekują tego, że kolejna super fajna rzecz po prostu pojawi się od właśnie takiej firmy jak Apple.

Przy czym wydaje mi się, że teraz większy nacisk i więcej innowacji jest w samym iPhone OS-ie, czyli systemie operacyjnym telefonu i jego funkcjonalnościach.

I w Earbooth, które są coraz bardziej zaawansowane niż w samym hardware'ze telefonu.

Ten telefon już naprawdę jest całkiem dobrym urządzeniem.

No i w końcu obsługuje standardowy port ładowania.

No to Unia Europejska jak zmusiła to tam wiesz.

Dzięki temu powstała kolejna najdroższa przejściówka z Lightning na USB-C.

No dobrze, to ja trochę wyrażę swoją opinię, a trochę was pociągnę jeszcze dosłownie moment.

Bo to jest dla mnie ciekawe, bo według mnie oni już nie muszą produkować lepszego sprzętu, aczkolwiek tak go produkują.

Nie wiem, czy widzieliście takie zestawienie, że nowy, bo oni jak zwykle mają nowy chip w iPhone'ie, że nowy chip ma wydajność single core i tam jeszcze taką samą jak MacBook Air na M1.

I że wstawili lepsze GPU'ów to wszystko.

Czyli generalnie mamy komputer na poziomie MacBook Air'a z M1 z 2020 roku, który mamy w kieszeni.

I dla mnie ciekawa rzecz jest, gdzie oni to pociągną.

No właśnie, bo tam jeszcze rozmawialiśmy przy okazji kilku innych rozmów, że Apple bardzo mocno w hardware inwestuje, jeżeli chodzi o neural engines i tak naprawdę neural cores.

Więc jestem bardzo ciekaw, w którą stronę software'owo się rozwinie ten ich sprzęt, bo oni już mają drugą czy trzecią generację telefonów, które są tak naprawdę bardzo mocnymi urządzeniami edge'owymi, jeżeli chodzi o sztuczną inteligencję.

Jestem bardzo ciekaw, jakie dodatkowe funkcje zobaczymy w tych telefonach.

No właśnie, bo chip to jest trochę mało.

Dlatego, że tą moc zobliczeniają musi się do czegoś wykorzystać.

Więc w przypadku tego telefonu to ograniczenia, to jest jednak kwestia interakcji z nim, że nie wszystko robi się wygodnie na telefonie.

To jest jedna kwestia.

Druga kwestia to jest taka, że iPhone nie jest też w oderwaniu od całej reszty jako systemu Apple'a.

I dlatego widać, to chyba akurat to chciałeś Tomek zachintować na początku odnośnie właśnie tego Vision Pro, że już pojawiają się pewne małe synergie, czy to robienie zdjęć, oni chyba je nazywają zdjęciami stereoskopowymi, czy spatial, przepraszam, czyli zdjęcia przestrzenne, czyli że możesz zrobić już takie zdjęcia, które na Vision Pro będą potem trójwymiarowe, czy tam pseudo trójwymiarowe.

Filmy nawet niż zdjęcia.

Tak, i to już się jakieś takie pierwsze synergie, które się pojawiają.

No, jestem ciekawy, bo podejrzewam, że oni mają przez cały czas x różnych, nazwijmy to streamów produktowych, nad którymi pracują, no ale wypuszczają dopiero wtedy, kiedy mają prawdziwy efekt wow.

Też nie chcą się spalić, nie chcą poddać jakiejś takiej przesadnej krytyce zbyt wcześnie wylisowanych produktów.

To, co mnie interesuje, to jest faktycznie to, co dalej będzie z tymi chipami.

To, czy one zostają dobrze wykorzystane, to jest jedna rzecz, a druga rzecz, w jakim kierunku dalej to pójdzie, bo już jesteśmy na etapie 3 nanometrów.

I to rzeczywiście na tym etapie odprowadzenie ciepła jest już bardzo dużym wyzwaniem.

Jestem ciekawy, co oni pokażą za rok w tym temacie.

I też mnie interesuje to, o czym powiedziałeś, co zagaiłeś, czyli właśnie, skoro już mają teraz ten zreinżynierowany, odświeżony zupełnie GPU, to do czego to wykorzystają?

Do takiego samodzielnej pracy, czyli do wypuszczenia tytułów, które oferują coś więcej na telefonie, czy może będą chcieli to spinać z czymś większym?

Może z jakąś dużą konsolą, może jeszcze z jakimś partnerem?

Sam jestem ciekawy.

Dobra, zobaczymy, jak będzie za rok.

Dla mnie to jest jedna rzecz, po prostu, jak obserwuję ich od dłuższego czasu, używam, nie jestem jakimś tam fanboyem, ale tam jest długoterminowa strategia i to mnie fascynuje w tym wszystkim.

Długoterminowa, spokojna strategia, robimy swoje.

Są dwa ruchy właśnie w tym wszystkim, co się pokazały.

To GPU, to jest interesujące i wiesz, pytanie, czy będziemy mieli atak na konsolę, czy właśnie, tak jak powiedziałaś, sprzymierzenie się z kimś, bo oni jednak potrafią w partnershipy.

Jeszcze może tak dodam tylko szybciutko do tego, co Sebastian powiedziałeś, że poza odpowiedzianiem ciepła jeszcze bardzo szybko dodam wątek, jest bardzo ciekawy wątek baterii, bo ten sprzęt zużywa naprawdę sporo prądu i iPhone 14 bardzo szybko się starzeje, jeżeli chodzi o tak naprawdę baterię.

To tam jest dyskutowane, to w tą stronę nie idźmy, to jest chyba po prostu problem sprzętowy, to nie jest łatwe.

Nie?

Już tylko kończąc, nie wiem, czy pamiętacie, bo to trochę archeologia, był taki koncept Windows Continuum.

Ktoś z was rings the bell, czy nie?

Mike tam zrobił w którymś momencie, jak był taki archaiczny dla młodszych oglądaczy potencjalnych, archaiczny system już w tej chwili, Windows Phone i oni zrobili takie coś, co się nazywało Windows Continuum, czyli miałeś telefon, podpinałeś go do monitora, podpinałeś po nim bluetoothem myszkę i klawiaturę i miałeś pełnochodzący Windows.

I to literalnie pełnochodzący Windows.

Ja jestem bardzo ciekaw, czy w którymś momencie zobaczymy, czy widzisz iPhona w roli po prostu podpinam go do monitora, podpinam do tego, mamy AirPlay, nie?

I to jest to, co powiedziałeś, Sebastian, nie?

Myślę, że oni to ćwiczą, bo iPhona możesz wykorzystywać jako kamerę i w bardzo prosty sposób go podpinać, więc tam, gdzie to już taka bariera wejścia była niska, a intuicyjność była wysoka, to to już jest.

A jak będzie dalej, no zobaczymy.

Albo tak naprawdę zobaczymy coś jeszcze innego, czyli wiecie, iPhona i okulary i będzie troszeczkę inne wydanie.

Także no, obstawiamy.

Dobra, zobaczymy.

Apple się na pewno zmienia w bardziej firmę, która buduje usługi i ma długoterminową strategię.

Według mnie nowe iPhony już nie będą miały wow, wow, wow, nie?

Ale będą miały wow gdzie indziej, czyli te integracje.

Ale to moja opinia.

Wojtek powiedział, że może zobaczymy użycie, jeżeli chodzi o AI.

AI wraca.

W każdym brew rozmawiamy o AI ostatnio.

Kiedyś zrobimy taki no AI brew i będziemy przez 10 minut mówić.

Kto powie AI, to muszę zapłacić na jakieś czarce.

Mamy właśnie 5 PLN za Elona.

5 PLN wpadło.

Gdzieś licznik zrobię.

AI się rozwija, tam różne firmy różne rzeczy robią, ale jest kilka rzeczy, które są potencjalnym zagrożeniem i w ogóle problemem, jeżeli chodzi o wdrożenie AI jako takie.

I tutaj rozmawialiśmy w zeszłym odcinku, jak ktoś nie widział to polecam, czy nawet dwa odcinki temu, to się gdzieś tam przewija o podejściu open versus closed, jeżeli chodzi o AI.

I mamy OpenAI, gdzie powiedzieliśmy, że oni idą bardzo w stronę open, mają partnera Microsoft.

I zrobili dość ciekawe ruchy, bo ja pracuję głównie na rynku Enterprise.

Teraz wy jeszcze, Sebastian też, Wojtek.

Znaczy Sebastian, nie wiem czy, ale pewnie tam firma gdzieś dotyka.

It's complicated.

Tak, it's complicated.

Na rynku Enterprise to jest zawsze skomplikowane.

Zostaw do danych, bezpieczeństwo i tak dalej.

No i tutaj są dwa zagrożenia, które tak naprawdę nie są technologiczne, a bardziej legal albo user, czyli po pierwsze chat GPT Enterprise, czyli OpenAI zrobiło wersję chat GPT, która jest przystosowana albo daje safeguard firmie, bo normalnie jak firma chciała dotąd to używać, to odpalała sobie Azure, odpalała OpenAI Services i budowała całą otoczkę dookoła tego.

A druga rzecz to Microsoft przy okazji, bo Microsoft buduje na tej samej technologii, odpala swoje kopajloty i wypuścił taki dość ciekawy legal statement, w którym tak naprawdę wziął na siebie odpowiedzialność za potencjalne naruszenia copyrights i tak dalej, jeżeli to dobrze czytam, swoich użytkowników.

To jak to widzicie i jaki według was to będzie miało wpływ na adopcję AI w Enterprise?

To jest ciekawy temat, bo tam się pojawiło parę magicznych słów albo magicznych zaklęć.

Pierwsze magiczne zaklęcie to jest SOC2.

On otwiera bardzo wiele drzwi, no bo to jest po prostu standard, jeżeli chodzi o zabezpieczanie danych.

To jest jakiś standard powiedziałbym nawet wielowymiarowy.

Powiedz chwilę co to znaczy SOC2 i czy się to stosuje.

Wszyscy pewnie wiedzą.

Czy będę w stanie to rozwinąć, to jest mi ciężko powiedzieć, bo chyba nigdzie sobie akurat nie zapisałem.

W każdym razie SOC2 jako standard compliance on definiuje kryteria, jeżeli chodzi o zarządzanie danymi użytkownika.

Czyli właśnie tam jest tak zwane pięć pryncypów zaufania, security, availability, processing integrity, confidentiality, privacy.

Więc to można powiedzieć, że to jest taki złoty standard, jeżeli chodzi o to w jaki sposób traktujemy te dane użytkownika i w jaki sposób je zabezpieczamy.

I to jest taki najbardziej chyba znany protokół.

Nie, protokół to jest powiedziałbym standard compliance.

Jest standard, to jest framework po prostu o zgodności.

Który jest wymagany jako powiedziałbym taki level one, zwłaszcza jeżeli chodzi o enterprisy.

Tak, bo tutaj jest zawsze...

Ja jeszcze dodam, że tam jest kilka dodatkowych bardzo ciekawych rzeczy, bo przede wszystkim wiemy, że...

Głośno, bo to pewnie nikt nie przeczytał, terms of conditions.

Natomiast używając GPT oddajemy wszystkie dane do OpenAI, całą historię i tak naprawdę wspomagamy trenowanie przyszłych wersji tego modelu i analiza zachowania użytkowników.

To samo dotyczy API, więc wszystkie produkty, z których korzystamy, może to jest warto też powiedzieć, które są oparte od ChargeGPT, tak naprawdę oddajemy absolutnie wszystko od ChargeGPT.

Jeżeli ktoś analizuje przy pomocy jakiejś platformy, która korzysta z ChargeGPT swoje maile i dzięki temu na przykład automatyzuje część swoich rzeczy, również oddaje te maile do ChargeGPT.

I warto dodać, że tak naprawdę jedną z głównych obietnic OpenAI jest to, że nie wykorzystuje danych w modelu Enterprise do trenowania i tak naprawdę nie są one jakkolwiek przechowywane podobno, bo poza tym, że ewentualnie są kodowane i całkowicie zaszyfrowane.

Tomek.

Wiesz co, dwa takie trochę luźniejsze komentarze może na początek.

Po pierwsze, z oddawania maili do procesowania to wszyscy użytkownicy Gmaila przełknęli już dawno i nie mają z tym żadnego problemu jak widać.

Druga rzecz to taki komentarz, który usłyszałem od jednego ze znajomych w jego podcaście niedawno, że to, że procesują nasze maile jest odpowiedzialne za degenerację tego modelu i obniżenie jego jakości.

No ale to jest żartobliwe.

Natomiast wiesz, nie można tak naprawdę, jeżeli byłaś instytucją, która się szanuje jeżeli chodzi o podejście do danych użytkowników, no to tak naprawdę oficjalnie nie mogłeś korzystać z ChargePT bez odpowiedniej opuskacji tych danych.

Ja nawet szerzej powiem, bo ja trochę już nie mam złudzeń na temat jak instytucje do tego podchodzą, przepraszam instytucje, ale w większości wypadków nawet jeżeli firmy nie są tego świadomie, nie potrafią tego robić, nie stosują nawet tych standardów, to jak widzą coś takiego jak AI, ChargePT, cokolwiek, to mówią ola Boga, macie dostęp do moich danych i będziecie wiedzieć o czym piszę.

To jest ciekawy ruch, bo to jest po prostu usunięcie bariery adopcji.

Bo tak szczerze powiem, przynajmniej moja opinia, możecie mnie tam kopnąć pod kostkę, a potem widzowie też, większość ludzi nie jest w stanie merytorycznie sprawdzić co OpenAI Charge robi z ich danymi, w jaki sposób je przechowuje, czy one gdzieś wyciekają czy nie.

I teraz tak naprawdę to co dodaje, to daje po pierwsze papierek lakmusowy pod tytułem OpenAI mówi, że to jest zgodne, więc generalnie ktoś może zrobić krosczek na checkliście pod tytułem używamy i oni powiedzieli, że to jest zgodne.

To jest to samo co jest w chmurze.

Próbujesz zgodność ze standardami na data center, AWS, Azure czegolwiek.

No i to jest dobry, to będzie naprawdę duży boost do adopcji po stronie Enterprise według mnie albo usuwanie tej bariery.

Jeszcze jak dostarczą gotowe takie, nie wiem jak inni profiderzy to mają, ale Microsoft ma takie coś, co się nazywa Trust Center i tam są gotowe papierki lakmusowe na wszystkie wymagania legal, czyli jesteśmy zgodni z tym, z tym, z tym.

I jeden mały aspekt, który jest dla mnie ciekawy, bo ja gdzieś w tym świecie istniałem czy istnieje dalej, to jest to, że dotąd taki czat GPT Enterprise to robili partnerzy.

Czyli my braliśmy OpenAI API i robiliśmy to wszystko dla klienta.

I to jest naprawdę bardzo krótki okres, w którym OpenAI z Microsoftem zdecydowali się zamknąć tą ścieżkę dla partnerów i wystarczy coś gotowego, to też bardzo szybko poszło.

I tam też są smaczki.

Ja zwróciłem uwagę na dwie rzeczy.

Po pierwsze, czat GPT Enterprise nie jest produktem Microsoftu.

Tak, tak, to wiem.

To jest taka ciekawostka, bo to koło pilotów sobie pewnie za chwilę przejdziemy, tam jest inna sytuacja.

A druga ciekawa rzecz jest taka, że owszem, jest jasno powiedziane w tej licencji, że nie trenują swoich modeli w oparciu o dane i te modele nie uczą się, też ze sposobu użycia tych modeli w aktualnej wersji.

Natomiast to należy oczekiwać chyba, że następnym krokiem właśnie będzie customizacja, czyli że OpenAI zaoferuje pewnego rodzaju kontenery, silosy, pojemniki, gdzie właśnie będziemy wpuszczać swoje dane.

Ale to już jest trochę, wiesz?

Ale jeszcze nie w tym oferingu, nie w GPT Enterprise.

Nie, ale to jest w postaci, zapomniałem jak ten plugin się nazywa, taki prywatny store.

Jest taki plugin w OpenAI, w ChartGPT nawet teraz, gdzie możesz mieć po prostu wtyczkę, która sięga do twoich prywatnych danych.

Ale to jeszcze nie jest customizacja modelu, to nie jest uczenie naszego, tylko własne wektory i tak dalej.

Tak, bo tutaj jest bardzo ważne.

Rozróżnijmy GPT i ChartGPT, bo wtyczka do ChartGPT to jest troszeczkę coś innego niż GPT.

ChartGPT Enterprise jest przede wszystkim dostępny przez API i to też warto powiedzieć, że tam mamy usunięte jakiekolwiek ograniczenia z ilości promptów, nie pamiętam dokładnie, chyba dwa czy trzy razy szybszy silnik i dużo dłuższy kompleks Windows.

Tak, z tego co pamiętam.

Więc tak naprawdę to oznacza, że będziemy w stanie budować dosyć zaawansowane rozwiązania w oparciu o ChartGPT Enterprise.

Słuchajcie, a co do tego populota?

Bo tam jest dopiero grube zagranie Microsoftu, słuchajcie.

Czy to nie jest zbyt grube zagranie?

No nie, bo według mnie to jest trochę to samo.

To znaczy wiesz, jednym wątek jest ten, który ty już zagaiłeś Sebastian, pod tytułem OpenAI pracuje z Microsoftem, oferta i tak dalej, ale z drugiej strony ChartGPT idzie trochę w poprzek.

Tylko znowu, ChartGPT to jest bardziej Enterprise, to jest, chcesz coś customizować, budować, a Copiloty to jest coś, co dostajesz out of the box.

Dostajesz działający na Office, Copiloty są wszędzie.

Niektóre są widoczne, niektóre są w preview, które ja tam gdzieś widzę jeszcze w ogóle, że wyjdą, ale tak, wiesz, Microsoft musi też to samo, jesteśmy trochę na tym samym etapie jak była chmura.

Microsoft, czyli inny vendor, musi przekonać firmę, żeby zaufała temu narzędziu, żeby zaczęła go używać.

I pytanie, jak może to zrobić?

Ale zobacz, nie masz jeszcze precedensów legalowych, jeszcze nie było żadnego dużego tak naprawdę procesu wytyczonego, a już wiadomo, że są chociażby te procesy scenarzystów, zresztą to jest nie tylko jedyne środowisko, które się oburzyło, to się wydarzy, a Microsoft uprzedza trochę ten ruch i mówi, jeżeli cokolwiek, co jest produktem któregoś z Copilotów zostanie zaskarżone przez kogoś jako złamanie praw, to w tym momencie my bierzemy na siebie bycie stroną w takim procesie.

Nie wiem, czy to wszystko wyraziłem precyzyjnie, prawniczo, pewnie nie do końca, tak to interpretuję, natomiast jak dla mnie to jest bold move.

Nie, to jest bold move, to jest bardzo bold move.

Ja oczywiście wiesz, nie jestem prawnikiem, podejrzewam, że jak prawnik by wziął tę umowę, to tam się zaczyna, a kiedy nie wezmą na siebie tej odpowiedzialności, bo to na pewno nie jest blanket case na wszystko, ale on jest tym powodowany, że oni muszą się upewnić, że znając Microsoft, działając z tą firmą, zresztą wszystkie firmy tak działają, Microsoft ma klientów na Copilot już w tej chwili i rozmawiają z nimi.

Jak mają w tej chwili, to znaczy, że przynajmniej rok, pół roku nad tym już siedzą klienci prawdziwi.

Oni zbierają obiekcje i wiedzą jakie obiekcje ma klient i teraz idą na mass market, mają licencję, która poszła w świat, można ją kupić i oni wiedzą jakie pytania będą na mass market.

Ktoś doszedł do wniosku, że to pytanie jest tak bold, że musi być bold statement, bo inaczej nikt tego nie kupi.

To jest to komercyjnie, ale faktycznie patrząc na rozmiar firmy, jej kasę, wielkość skrzynek, to potencjał do pozłów będzie duży.

Pewnie w Microsoftie teraz jest zatrudnienie prawników na potęgę, na zapas.

Myślę, że byli tam tak czy inaczej.

A jak prawnicy?

Do tego też dojdzie, ale jest to wyzwanie.

Tam jest kilka wyzwań, bo w tej chwili Microsoft adresuje jedną, czyli ktoś pozwie klienta za coś, co wyprodukował Copilot, ale drugie wyzwanie jest takie, ktoś zobaczy czyjś kawałek tekstu.

To się też zdarzy i wtedy Microsoft będzie pozwany.

Zobaczymy.

To jest bardzo ciekawe, bo w kodzie to jest dosyć trudne.

Jeżeli pomyślisz, to udowodnienie komuś, że kod danego produktu zawiera twój kod, jest niesamowicie trudne.

To jest bardzo ciekawe w ogóle, co tu się zdarzyło.

Ja tu patrzę na inny, bo ty patrzysz na kod, a dla mnie Copilot to głównie będzie M365, O365.

Copilot i BigHabit jest jeden z wielu.

Wiesz o co chodzi.

Chodzi o to, że jednak wiemy jak te modele działają.

Sebastian pisze e-mail, wysyła e-mail.

Jest bardzo mała szansa, że ten kto odbierze ten e-mail patrzy i mówi, kurde, to jest mój dokument.

Jest pytanie, na ile on jest podobny do faktycznego dokumentu.

Na ile model wziął coś od innego użytkownika.

Prawnicy będą się tam stukać strasznie.

Zobaczymy.

Na pewno to pomoże w adopcji w Enterprise, dlatego jestem pewien, i na to jest nakierowany ten ruch.

Jeżeli chodzi o dane, to jeszcze jest ciekawe oczywiście, jaki ruch wykonają te regulatorzy jak w Unii Europejskiej, jak to zacznie wchodzić, bo jak to zacznie wchodzić, to ktoś podniesie głos w Unii Europejskiej na pewno, regulatorzy zaczną siadać na Copilot, ale swoją drogą Google też odpala to samo.

Czyli Google odpalił podobną usługę, to nie wiem czy wiecie czy nie, ale odpalają dokładnie to samo, tak jakby to się duet nazywa, duet for workspace i nie mają takiego statement, więc to też jest kwestia już w tej chwili, wiesz, competitive advantage.

AI w Enterprise, zobaczymy gdzie nas doprowadzi.

Przeskoczmy trochę na inne tory.

Wojtek wspomniał o Copilocie, wszyscy w kodzie Copilot AI koduje, nie?

Większa produktywność?

Tak, produktywność traderów.

Jakiś czas temu rozmawialiśmy o takiej aplikacji.

CFO od razu idzie do CTO i mówi, a po co nam tyle programistów, otnijmy o 20%.

Tym bardziej, że otworzył specyficzny raport, który niedawno się okazał w światu.

Dobrze, no właśnie, pojawił się raport, który jest wytworzony przez jedną z wielkich firm o nazwie McKinsey, który zaproponował takiego ciekawego tematu jak jak mierzyć produktywność deweloperów.

Sebastian się uśmiecha, Wojtek się uśmiecha.

Wojtek, powiesz nam o co chodzi w raporcie i w temacie?

Uśmiechamy się, bo czujemy się oświeceni.

Tak, tak, oczywiście.

To jest bardzo ciekawa rzecz, bo oczywiście pokazuje jak działają firmy consultingowe, czyli bierzemy coś, co ma bardzo duży sens i ma dużo researchu, a jak je miksujemy, to dodajemy swoje 3-4 grosze i sprzedajemy to jako nowe opakowanie.

Więc produktywność inżynierów to jest niesamowicie ciekawy temat.

W ogóle myślę, że możemy kiedyś jeszcze głębiej sobie w niego wejść, może przy okazji naszego drugiego kanału.

Natomiast jak wiemy, produktywność jest szczególnie razem z całym tak naprawdę DevOps, to jest bardzo szeroki temat, jest dosyć mocno poruszany.

Czyli mieliśmy kilka podejść do tak zwanej produktywności całych zespołów, jak porównywać zespoły między sobą, jak porównywać firmy, więc pojawiły się tak zwane metryki DORA, później pojawiły się też chyba 2-3 lata temu metryki Space, które tak naprawdę rozbudowały dosyć mocno.

Tam poszliśmy w 5 wymiarów, Satisfaction and Well-Being, Performance, Activity, Communication and Collaboration, Efficiency and Flow, stąd Space.

Mackinsley to wziął, ładnie opowiedział mniej więcej o co chodzi, dodał bardzo brzydki i może nie do końca prawdziwy model, jak wygląda praca programisty, który jeżeli jest właśnie egzekutywem, czyta się świetnie i człowiek myśli, no kurczę, oni mają rację, który powiedział, że tak naprawdę w wkładowaniu chodzi o napierdzielanie tego kodu i jak najmniej spędzenia czasu na rzeczach, które tego kodu na mnie nie produkują i zaproponował metryki, metryki, które się nazywają Developer Velocity Index Benchmark, Contribution Analysis i później jeszcze Talent Capability Score i oczywiście to sprzedaje jako swoją usługę, żeby doradzić jak zwiększyć produktywność.

Wypuszczono to i spowodowało to ogromne zamieszanie wśród naszej społeczności i wielkie oburzenie.

No właśnie, teraz pytanie do was, dlaczego?

Jakąś zanim Sebastian odpowie na pytanie dlaczego, to uczę się delegacji, ale wiesz, taki trochę kij w mrówisko, albo może nawet nie kij w mrówisko.

Dlaczego oni to wypuścili?

To jest zasadne pytanie i mi się spodobało, George, kto powie to węgierskie nazwisko?

Orosz.

On napisał dobrą odpowiedź na to, możemy o tym porozmawiać.

Jakiem warto dodać?

Ale na początku jest tak, to, że się wkurzyli, myślę, że się wkurzyli, a potem przemyśleli.

Potem mi się spodobał w tej odpowiedzi początek, który upraszczając mówi, słuchajcie, to jest dobre pytanie.

Wszyscy się mierzą, tam oni używają przykładów Sales, HR itd.

To dlaczego wy się macie nie mierzyć?

To jest tylko pytanie jak, no bo faktycznie wiesz, ja nawet jak prowadziłem firmę, to mieliśmy Sales, faktycznie masz po prostu konkretne wyniki itd.

HR ma targety na rekrutację, ma SLA na dostarczenie kandydata, itd.

Deweloperzy mają dowieść projekt.

I teraz...

Dotykasz bardzo zasadnych pytań.

Pytanie jest zasadne.

Teraz pytanie, dlaczego akurat to, co zrobił McKinsey, nie zeszło w Kijów Mrowisko?

Sebastian.

A ja będę bronił McKinsey, to proszę sobie zanotować.

A ja go nie zaatakowałem.

Ja powiedziałem, że ludzie się oburzyli, bo pytanie według mnie jest zasadne i oni wiedząc, że pytanie jest zasadne, zrzucili swój sposób robienia tego po prostu.

Pytanie jest zasadne.

To, co oni zrobili, to zagrali dosyć sprytnie.

Po pierwsze, nie wyskoczyli z jakąś metryką zupełnie nie wiadomo skąd, taką stricte twardą metryką typu ilość commitów na przykład, tylko zaproponowali tak naprawdę cały framework.

To nie jest głupie.

Po drugie, uderzyli w problem, który jest problemem faktycznym i witalnym, czyli zapewniają pewną gapę, pewną niższą dziurę rynkową, co też nie jest głupie.

Po trzecie, zanim zaproponowali jakieś szczegóły konkretne, to zaproponowali jakiś model mentalny.

Na przykład podzielili tam właśnie na wymiary system level, team level itd. i jeszcze dodatkowo podzielili na pewnego rodzaju focus, jeżeli chodzi o produktywność.

Tam outcome z optimization.

Szczerze mówiąc, wydaje mi się, że nie ma sensu.

Te wymiary są ze space, od razu dodam.

Wydaje mi się, że te focusy akurat nie mają sensu, natomiast zaproponowali coś.

Kolejna rzecz.

Proponując ten framework, uczyli się z tych frameworków, które zostały zaadaptowane.

Na przykład Accelerate, który uzyskał bardzo duże popularity, też jest skonstruowany w dosyć podobny sposób, czyli jakieś surveje, interwiowanie organizacji.

Tu nie są jakieś mega twarde metryki, więc po prostu stwierdzili, że pójdą zachowawczo i zrobili coś podobnego.

To wszystko ma ręce i nogi.

Moim zdaniem to spada się od złej strony, to pewnie jeszcze o tym pogadamy.

Natomiast to, co rzeczywiście tak wytriggerowało całą społeczność, to jest kilka rzeczy.

Po pierwsze, że tu się pojawiła produktywność na poziomie indywidualnym, a to zawsze triggeruje ludzi, bo tak to już wygląda.

Po drugie, rzeczywiście to, co powiedział Wojtek.

To są dwa czy trzy takie sformułowania, które świadczą, że osoby, które to pisały, to chyba w ogóle nie rozumieją, na czym polega development.

Ja tam gdzieś tam miałem sobie wypisane, że ludzie spędzają ekscesywny czas na niekodujących czynnościach, takich jak jakieś sesje, projektowania, zarządzanie z zależnościami.

To są niesatysfakcjonujące, tłumaczę.

Dokładnie.

Albo jeszcze jest takie chyba stwierdzenie, które miało być one-linerem, które wszyscy będą cytować, żeby to enable those highest value developers to do what they do best.

Kod.

To się nie przyjęło.

To teraz tutaj wejdę ci tylko z jednym komentarzem, bo ty też to powiedziałeś.

McKinsey knows their audience.

Oni wiedzą tego, kogo piszą.

Te słowa, które powiedziałeś, to jest wiesz, idziesz do CFO, CEO i mówisz, słuchaj, twoi deweloperzy nie developują, nie piszą kodu.

Tak?

Ale przecież McKinsey to świetnie rozegrał.

Oni w ogóle nie weszli w polemikę z Kentem Beckiem.

Oni w ogóle nie weszli w polemikę z Eroszem.

Oni jadą dalej po swojemu.

Jest cisza, artykuł dalej sobie wisi.

Podejrzewam, że jest w wielu deckach, które są już wykorzystywane na całym świecie i biznes się kręci.

Także oni doskonale wiedzą, co robią.

Bynajmniej nie uważają, że to jest jakiś problem.

Tam jest jeszcze taki ciekawych rzeczy, o których nie wspomnieliśmy, a które też trochę triggerują ludzi, to jest tam podział pracy dewelopera, inżyniera na inner loop i outer loop.

Jest tam też parę takich rzeczy, co do których aż zęby zgrzytają.

Tak, pewnie tych smatków.

Jest to na pewno bardzo ciekawy raport, natomiast tak jak, Tomek, mówisz, ciekawe, co się będzie działo wokół tego raportu, myślę, że to jest tak, jak mówisz.

Kim jest klasyczna firma odbiorca tego raportu?

To jest firma, która tak naprawdę, wiecie, chodzi o productivity score według DORA, które polecamy, taki jest self-assessment, można zrobić na stronie DORA, żeby sobie zobaczyć na przykład, jak nasza firma, nasz zespół wypada, jeżeli chodzi o produktywność.

Tam odpowiada się na takie pięć podstawowych wymiarów i na przykład nam pokazuje, że jesteśmy w 60, 80, 95 top procentach organizacji.

Między innymi te słynne metryki DevOpsowe, czyli jak szybko potrafimy naprawić nasz system, jak często mamy deployment, jaki procent naszych buildów tak naprawdę psuje nam produkcję.

I okazuje się, że, wiecie, tak naprawdę, wracając do tej klienteli Markin's Lay, ja myślę, że oni nie targetują tych top 20 procent firm, tylko tak naprawdę te enterprisy biedne, które mają kwartalny release sprint, czyli raz na sprint jest dwa tygodnie, zabraniamy wszystkim iść na urlop, bo wszyscy naraz integrujemy się i w krwi i poczcie wypluwamy ten nasz nowy inkrement na produkcję i wtedy wszyscy rzucają prawdopodobnie inżynierowie papierami po tym właśnie cyklu, bo mają tego dość i wszyscy sobie zadają pytanie, co my robimy źle.

I przychodzi Markin's Lay i mówi, no mamy tutaj dla was taką propozycję, zastanówcie się, przyglądnijcie się i dla tych osób ma to sens.

Wiesz co Wojtek, myślę, że w Enterprise ludzie nie rzucają papierem po czymś takim, to chyba przeceniasz albo dawno nie widziałeś środowiska, ale wiesz, to trochę adwokat diabła, bo na początku przynajmniej ja powiedziałem, Sebastian opakiwał głową, a teraz temat istnieje.

Ktoś się pyta w końcu za co ja płacę, za tych deweloperów.

Jest sprint, znowu coś nie poszło, system nie działa, to jest bardzo ważne pytanie, bo też na przykład mając załóżmy 25 zespołów, chciałbyś zrozumieć, jakie praktyki mają twoje top performujące zespoły.

Nie zdążyłem jeszcze cię walnąć w głowę do tego co powiedziałeś.

I wiesz, jesteś sobie w takim Enterprise przysłowiowym, którym powiedziałeś, no i mówisz, kurde, no to faktycznie powinniśmy wiedzieć, czy to jest to co robimy, to jest dobrze robimy.

I przychodzi taki przysłowiowy Wojtek, nic ad voctem, i mówi, nie, tu mam metrykę DORA i w ogóle tutaj velocity itd.

I ten CFO tak patrzy i mówi, a oni to przeliczają na dolara.

I to jest trochę tak, że jak ciebie słuchałem, to tak do mnie dotarło, że to wszystko co powiedziałeś jest prawdopodobnie dobrze, tylko to jest kompletnie niezrozumiałe dla tych odbiorców, do których traktowany jest ten raport, który może MacKenzie wypuścił.

I tu na przykład spodobało mi się to co Oroż pisał z tym drugim człowiekiem, Kent Beckiem, że oni zaczęli tam dyskutować w tych swoich artykułach, jak zrobić jakieś metryki, które są tak naprawdę related to the business, pod tytułem, że wypuściliśmy coś użytkownika na przykład, taka bardzo prosta albo coś takiego, bo tutaj mamy problem, że mamy tak naprawdę, próbujemy rozmawiać o czymś, co ktoś uważa za wysoką sztukę, high end, tutaj wiesz, kapłan kodu, Druid Visual Studio Code.

Przepraszam, bo to jest uderzenie w jedną firmę, która używa takiej nomenklatury w Polsce.

Ok, nie wiedziałem, to przepraszam firmę, moja ignorancja jest straszna.

Z drugiej strony mamy ludzi, którzy za to płacą, albo widzą numery tak naprawdę, oni nie rozumieją tego co ci druidzi robią.

No i teraz pytanie jak to zadresować.

Sebastian.

Ja mam jeszcze kilka takich drobnych uwag.

Pierwsza taka, powiedziałaś, że oni zaproponowali jakąś alternatywę, w sensie Beck z Orożem, ale nie wiem czy zwróciliście uwagę, ale zaproponowali różne alternatywy, oni się nie zgodzili.

A końcu się rozjechali, zrobili dwie końcowki artykułów.

Tak, więc to jakby jedna rzecz.

Druga rzecz, która jest ciekawa, to jest to, że w tym artykule, zresztą Wojtek też wspomniał na samym początku, jest powoływanie się na takie metryki, które zdobyły jakąś popularność.

No więc jest Dora, która ma moim zdaniem dużo sensu, natomiast ona jest ściśle DevOpsowa.

Jest ten Space, który moim zdaniem ma średni sens, bo tam są metryki typu satisfaction and well-being.

O, mierzenie tego to naprawdę nie jest… Story points też jest w Space, by the way.

No właśnie.

No, więc kończąc ten mój przydługi wywód, to chciałem tylko powiedzieć, że temat mierzenia wydajności będzie wracał, będzie wracał jeszcze mocniej, natomiast moim zdaniem podejście, które tutaj trzeba będzie przyjąć, to jest podejście zgoła inne.

A tu akurat bym się powołał na Amazonowe Working Backwards.

Czyli spójrzmy na siebie, spójrzmy na swoje biurko i zobacz, czy jesteś w stanie naciągnąć indywidualnie, czy jesteś produktywna, kiedy nie.

Moim zdaniem jesteś, bo wiesz, że na przykład w danym momencie przerwa wynika z tego, że ty czekasz na kompilację, albo że w danym momencie na przykład to, że nie tworzysz artefaktów wynika z tego, że musisz z kimś coś dogadać, bo brakuje ci jakiejś informacji.

I tu uwaga, teraz pojadę już w ogóle takim buzzwordem i to będzie w ogóle przezabawne.

Zaczekaj, ja ustawię tutaj buzzword warning taki czerwony.

Uważam, że tu w dużej mierze pomoże nam Gen AI.

Dlaczego?

Dlatego, że pojawią się narzędzia, które będziemy wpinać, które będą nam pomagały w klasyfikacji pracy lepiej niż do tej pory.

Czy do tej pory mieliśmy te swoje harwesty, toggle itd., gdzie ręcznie oznaczaliśmy pewne rzeczy, a teraz będziemy mieli narzędzia, które bardziej holistycznie będą patrzyły na te nasze aktywności i będą nam pomagały ustawić, w którym momencie faktycznie byliśmy produktywni, a w którym nie.

I to nie będzie proste.

Będą iteracje tych narzędzi, ale moim zdaniem to, co jest najbardziej kluczowe, to jest właśnie odpowiedzenie sobie szczerze na to pytanie.

Czy my indywidualnie, subiektywnie jesteśmy w stanie powiedzieć, kiedy byliśmy produktywni, a kiedy nie.

Więc moim zdaniem tak, więc skoro tak, to da się to zautomatyzować.

Widzisz, i tutaj o tym nie pomyślałem wcześniej, jak to powiedziałeś teraz, to według mnie jest valid point.

To jest dobre podejście.

To jest faktycznie coś, co może działać.

Może dlatego, że trochę z mojego doświadczenia, jak prowadziłem firmę z chłopakami i my zbieraliśmy dane, to zbieraliśmy dane wszędzie.

I faktycznie kategoryzowaliśmy czas ludzi.

I to pomaga, bo wtedy wychwytujesz paterny.

I patrzysz, coś ci się obniża, coś ci się podnosi, możesz zacząć szukać dlaczego.

Bez tych danych tego nie ma.

Togle, te wszystkie inne rzeczy, tak jak mówisz, one są subiektywne.

Dlatego my na przykład unikając subiektywności używaliśmy kodów, że aktywności oznaczałeś kodami i te kody były standardyzowane w firmie.

Żeby się nie bajesować.

De facto daję.

I tutaj dla drugi obraz, który mi się pojawił w głowie, jest taki film Matrix, kiedyś taki stary Keanu Reeves.

On tam zaczyna w takim kubiku i koduje tam.

I tam coś jest chyba nawet na początku, o wydajności tak mi się wydaje.

I jego work behavior pojawia mi się w pracy.

Więc wiesz, i tutaj to będzie według mnie ciekawe, bo gdybyś wyszedł w tej chwili z takim podejściem, jak powiedziałeś, to według mnie będziesz miał backlash większy niż raport McKinseya, bo to będzie pod tytułem dlaczego nas AI będzie nadzorować i tak dalej.

Więc będę to robił po cichu i będę inaczej inną narrację sprzedawał.

Będę sprzedawał taką narrację, że pomagam ludziom być bardziej produktywnym, a nie, że ich mierzę na przykład.

A to, że management będzie miał dashboard, to już jest inna kwestia.

No i widzisz, i tutaj wracamy do copilotów Microsoftu, bo oni według mnie to w miarę szybko coś takiego wytkminią i wypuszczą copilot for developer, coś takiego.

Wiesz, reasumując, jest to...

Kent Beck chyba w ogóle tak zaczął wypowiedź, że jak on się przedstawia w tym artykule, to ma 40 lat doświadczenia na rynku pracy i od 40 lat zadaje sobie dokładnie to pytanie.

Zresztą notabene on w mecie odpowiadał między innymi za bardzo podobny tak naprawdę zakres obowiązków, czyli jak zwiększać produktywność, praktyki dobre itd.

Jest to absolutnie właściwe pytanie, więc tutaj myślę, że ciekawie się podziała.

Tutaj...

Skoro zahaczyliśmy...

Dobrze wyszło w ogóle, nie?

Znaczy tak sobie teraz miałem taką refleksję, że dobrze wyszło, bo nie rzuciliśmy się na McKinseya i nie rozszarpaliśmy, a tendencja taka bywa.

W szczególności u mnie, nie ukrywam.

Jest problem, zobaczymy kto go rozwiąże, ale faktycznie będę dotknął się dwóch rzeczy, produktywności i mety.

Jeden z tematów, który nawet sobie na dzisiaj przygotowaliśmy, to jest Threads.

Wspominaliśmy o tej aplikacji jakiś czas temu.

Wspomniany już wcześniej Oroż napisał artykuł, wywiad taki z ludźmi, którzy to dewelopowali.

Tam się dość ciekawy taki obraz też pokazał, który trochę jest w linii z tym, co taki człowiek, za którego nie zapłacę 5 złotych dzisiaj, zrobił z inną aplikacją EX.

Oni chyba zrobili w miarę szybko, w miarę dużą rzecz, w miarę efektywnie, Sebastian.

Może właśnie zacznijmy od tego, że ten artykuł ma charakter skupa, to znaczy to jest pewnego rodzaju kontrolowany przeciek, jest ekskluzyw.

W związku z tym zachęcamy jednocześnie właśnie do tego, żeby zapoznać się z Pragmatic Programmer, czyli newsleterem Gergelego Oroża.

Można znaleźć więcej szczegółów.

My się tutaj na pewne rzeczy, pewne szczegóły powołamy, natomiast nie ukrywamy, że to są szczegóły, które właśnie wyciągnęliśmy od kolegi Oroża.

Tak, więc jak wszyscy pewnie wiedzą, aplikacja Threads, która jest podobna do Twittera, została wypuszczona w bardzo krótki sposób, krótki sposób, w krótkim czasie, przez ekipę instagramową.

I ten krótki czas, co to w praktyce oznacza?

Jest dużo ciekawych szczegółów, jak się pojawiają w tym artykule.

Krótki czas to jest od stycznia do czerwca, czyli 5 miesięcy, czy tak długo, możemy sobie tam oceniać.

Kolejny ciekawy szczegół, aplikacja była dewelopowana w secrecy, to znaczy wewnętrznie niewiele osób o tym wiedziało.

Była dewelopowana na początku bardzo małym zespołem, to jest tam 12 osób, potem ten zespół się chyba rozrósł bodajże do 60.

Tam było bardzo ciekawe ratio, normalnie byli inżynierowie tylko i wyłącznie mocno senior.

Było ciekawe ratio, bo na przykład jeden product manager na 20 inżynierów, to jest takie ratio, o którym można tutaj podyskutować.

Ciekawe były również wybory technologiczne, tu można trochę skonfrontować ze swoim sposobem myślenia.

Przede wszystkim pojechali bardzo, mimo tego, że zajęło to wszystko 5 miesięcy, ale pojechali bardzo zachowawczo, dlatego że przede wszystkim wykorzystywali teksty, które mają już w Instagramie.

To oznacza, że na przykład aplikacja została zdewelopowana na Django, wykorzystywali swoje biblioteki i gotowe komponenty do natywnych aplikacji klienckich.

Tu niewiele pojawiło się nowego.

Skupili się tak naprawdę na tym, co jest specyficznego dla tej aplikacji.

Jak sobie spojrzymy, klon Twittera to chyba nie są zbyt jakieś sophisticated aplikacje, więc i tak możemy się zastanawiać, czemu zajęło to aż 5 miesięcy.

Natomiast później, kiedy spojrzymy sobie na metryki i zobaczymy, że ta aplikacja wyskalowała się do 100 milionów użytkowników w ciągu 5 dni, to wtedy zaczyna to wszystko mieć większy sens.

Czy na przykład wchodząc w nowy stack, stack nawet z najlepszymi opiniami w internecie, to czy dali byśmy sobie rękę uciąć, że to się przeskaluje do 100 milionów użytkowników w sposób niezauważalny dla user experience w ciągu 5 dni.

A więc ta decyzja wydaje się brać.

No właśnie, bo ja nie mam doświadczenia z takimi aplikacjami.

W ogóle, bo ja się szczerze nie pisałem takiej aplikacji, jakiś portal internetowy w większej ilości robiłem, ale tam w jakieś grube setki tysięcy ludzi szło może.

No właśnie, bo oni podeszli do tego bardzo pragmatycznie.

Mamy do odpalenia aplikację, mamy do jej do zrobienia.

Tu jest bardzo ciekawy aspekt, bo normalnie tego typu aplikacje, one mają właśnie bootstrap taki, zaczynają zdobywać użytkowników cokolwiek, a oni wiedzieli, że oni to dadzą na istniejący user base i zamiast takiego bardzo popularnego podejścia do tego, że weźmy najnowsze tutaj, fancy, flashy i tak dalej, to oni tak czytając ten skup to tak wychodzi, popatrzyli pragmatycznie, wzięli co mają.

Tam chyba nawet się pojawia, że zastanawiali się, czy nie użyć istniejącego kodu Instagrama i go dostosować.

Pomasowali to, popatrzyli gdzie się muszą pointegrować, jaki będzie user flow i tak dalej i po prostu zbudowali coś, co jakbyśmy weszli na rynek i pokazali, że tam Django i tak dalej, to wszyscy byli, Boże, w czym to napisaliście, po prostu wzięli to, co działa i zrobili z tego ciasto.

Czy tam tort czy zakalec, to już jest inne pytanie, ale wypaliło to ciasto na końcu.

Największe wrażenie chyba robi faktycznie ta skalowalność, o której Sebastian powiedziałeś, bo tam 100 milionów w 5 dni, ale powiedzmy 50 milionów w 1,5 dnia, więc te pierwsze dni to musiały wyglądać interesująco na metodach.

Tylko jak czytasz, to też jest ciekawe, że oni tam wprost mówią, że oni sami się zdziwili i musieli przerobić rzeczy, żeby dostosować się do tej skali, bo oni tam wprost mówią, że nie zakładali takiej adopcji.

Ja jestem bardzo ciekaw tego, co Sebastian dotknął, czyli ja z chęcią bym przeczytał, i to tutaj wracając do naszej rozmowy o produktywności, z chęcią bym przeczytał faktycznie wspomnienia albo jakieś lessons learned osób, które pracowały w tym zespole.

Tutaj myślę o tym, że to ratio, o którym mówiłeś, to przede wszystkim robi wrażenie, czyli zrobiliśmy zespół superkomandosów doświadczonych na EBCS.

Daliśmy tak naprawdę ludzi, którzy… Jeden product manager na 20 inżynierów robi troszeczkę inną pracę niż jeden na 5, więc ten zespół był bardzo autonomiczny, był tak naprawdę, jak widać, bardzo skupiony i jestem bardzo ciekaw, jak to wyglądało.

I jeszcze jedną rzecz.

W firmie, która nie jest już przyzwyczajona do tak szybkiego wypuszczenia tak szybkich produktów o tak szybkim wzroście, czyli jeżeli o tym pomyślimy, to Facebook już od dłuższego czasu nie miał wypuszczonego produktu z taką skalą wzrostu, więc to jest dla mnie o tyle też ciekawe, jak zrobiono coś wbrew kulturze istniejącej inżynieringu w firmie.

Wiesz co, nie wiem, czy oni to zrobili wbrew kulturze, bo tam jest taki bardzo fajny trend, że zanim oni cokolwiek wypuścili, to mieli już przygotowane wewnętrzne frameworki takie, które mierzą różne krytyczne aspekty performance'owe od bardzo różnych stron.

Więc jakby oni już tu mieli wszystko naprawdę bardzo dobrze unarzędziowione.

Oni dokładnie znali, jak wiedzieli, jak to będzie wyglądało, charakterystyka trafiku, jak wtedy się ten stack będzie zachowywał.

Jeszcze dwie takie ciekawe uwagi.

Jedna ciekawa uwaga jest trochę niezwiązana, ale przy okazji innej aplikacji, też dla takiej społecznościowej, czyli RChat'a, której jednym z founderów jest Naval Ravikant.

Jest dużo różnych fajnych stwierdzeń Nawala i nie tylko całego zespołu odnośnie produktywności, odnośnie tego, jak się buduje produkcję na dużym velocity.

I tam jest taka jedna bardzo fajna uwaga, która się odnosi dokładnie do tego case'u, do case'u Fredsów.

Sobie pozwolę ją zacytować w oryginale.

Try to do the most with the least number of people.

People are the most expensive way to scale.

Ja tylko po prostu mogę tu zacząć bić brawo i tak dalej.

My naprawdę tego nie doceniamy.

Godzimy się z jakimiś nieefektywnościami, czy brakami efektywności, czy to w komunikacji, czy to w współpracy, czy to ogólnie w zarządzaniu zależnościami i po prostu dorzucamy ludzi jak węgiel do pieca, gdy właśnie, bardzo mi się to podoba, że ludzie są najbardziej drogim sposobem skalowania.

To jest według mnie bardzo ciekawe.

Inne takie ciekawe już tak na zakończenie wtrenty to są odnośnie na przykład jakości i automatyzacji.

Oni tam mówią wprost, sorry, ale w naszej aplikacji krytyczny był user experience.

Wiedzieliśmy, że tu będziemy bardzo dużo zmieniać.

Więc w ogóle nie zawracaliśmy sobie głowy z automatyzacją interfejsu użytkownika, z automatyzacją tych aplikacji klienckich, zupełnie zero, nul.

Tak, tam jest early do użytkownika i niech klikają.

Tak i dockfooding, dokładnie tak.

Natomiast tam gdzie wiedzieli, że mają na przykład API i tamten API normalnie budowali za pomocą TDD, czyli praktyki, która tak naprawdę niekoniecznie wspiera jakość, ale wspiera jakość designu, czyli to jest praktyka, która wspiera tak naprawdę design i tam rzeczywiście te testy pisali od początku.

Czy to też według mnie była taka ciekawa, taki ciekawy lesson learned odnośnie tego, jak czasami wygląda teoria versus praktyka?

To tak trochę nie od inżynieryjskiej strony, kodu i tak dalej.

Dla mnie to pokazuje kolejny lesson learned z tej mamy X, który pokazuje, że da się robić ship it małą ilością ludzi albo inaczej skrojoną ilością ludzi bardzo dynamicznie, bardzo szybko.

Threads pokazało de facto, nie wiem czy pamiętacie, bo o tym trochę zahaczyliśmy, że tam było oskarżenie o podebranie ludzi, którzy zbudowali Twittera i know-how, ale co oni pokazali na końcu?

Pokazali, że w sześć miesięcy byli w stanie zrobić, shipnąć produkt nowy w całości w sposób, który wypalił.

Potem już usage to już jest kolejna rzecz, bo tam z tego co widziałem statystyka idzie w dół, ale pokazali, że po prostu ograniczony zespół ludzi w dużej organizacji jest w stanie coś zrobić, bo gdyby robili to w dużej organizacji, kilkaset osób to pewnie by tego nie dowieźli, ale aplikacja by była dużo bardziej rozbudowana.

Tu kiedyś możemy… Ja chcę podkreślić Tomek, to jest firma, która jeszcze trzy lata temu stawiała na zatrudnienie 10 tysięcy inżynierów, żeby zbudować Metaverse.

To jest dla mnie bardzo ciekawe, jak bardzo odmienny model mentalny przyjął ten zespół.

To jest naprawdę ciekawe.

I tutaj pojawia się takie zagadnienie, którego ja jestem fanem, a czasami gdzieś możemy kiedyś porozmawiać, czyli Theory of Constraints, czyli generalnie budujesz pod ograniczenia i no właśnie, zamiast się tam współudowywać.

Mówiąc o ograniczeniach, czas nam dobiega końca, przynajmniej ten zaplanowany.

Widzimy się tutaj jak co dwa tygodnie w BRU, więc jeżeli ktoś jeszcze nie zasubskrybował, to na taki dzwoneczek czy inna rzecz kliknijcie.

Poniżej w linkach macie kilka informacji, gdzie jeszcze można nas znaleźć.

Co drugi tydzień zamiast naszych trzech gadających głów, pojawiają się nasze trzy gadające głosy, czasami z czwartym lub piątym, czyli CTO Morning Coffee, to też tam zajrzyjcie, jeżeli nie znacie.

Uwagi, komentarze, tematy, o których chcielibyście, żebyśmy porozmawiali, mile widziane.

Sebastian Gębski jak zawsze przygotowany, z tego okoła widać wzrok biegający po dziesięciu monitorach.

Czterech.

Cztery monitory też dadzą radę.

Tak jak mówiłem, musimy zrobić geek out na temat naszych setupów.

Dajcie znać w komentarzach, czy chcecie geek out.

Wojtek Ptak na sali szpitalnej, Tomek Onyszko z niebieskim tłom w nowym miejscu.

Do zobaczenia za dwa tygodnie.

Dzięki bardzo.

Macie się hej.

Napisy stworzone przez społeczność Amara.org KONIEC!