Budowanie rusztowań

Dziś na LinkedIn ktoś zadał pytanie co by ludzie zrobili mając do wyboru dwie alternatywy:

• duża podwyżka i praca z Cobolem,
• średnia pensja i praca z nowoczesnymi technologiami

Dla mnie oczywista była bramka numer 3 ;-) czyli średnia pensja z nowoczesnymi technologiami jako sposób na zdobycie wiedzy by móc za jakiś czas szukać lepiej płatnej pracy.

Mój cel tu to "dobrze zarabiać i robić fajne rzeczy" i jak nie ma takiej opcji to wybieram "najkrótszą drogę" do tego celu z krokiem pośrednim. Wybór średniej pensji z nowoczesnymi technologiami to taki bootcamp gdzie mi jeszcze zapłacą za nauczenie się czegoś co mi pozwoli na kolejny krok. 
Ale to nie jest nawet tak, że ja ten cel "dobrze zarabiać i robić fajne rzeczy" mam jakoś jasno określony, on mi tu naturalnie wychodzi z opcji i że nie jest osiągalny wprost to myślę o tym jak go osiągnąć etapami.

To samo gdy buduję coś to za naturalne uważam robienie tego wersjami, mogę mieć oczywiście ideę jak to ma wyglądać na końcu, ale zwykle nie mam pojęcia i dlatego zaczynam od wersji minimum, od MVP i dodaję do tego rzeczy i przebudowywuję.

Buduję raz na jakiś czas rusztowania, które wspierają całą budowlę w czasie gdy to jest potrzebne.

Gdy w poprzedniej firmie budowaliśmy nasz produkt to zamiast wybierać bazę danych, projektować struktury danych i tak dalej, zaczęliśmy od prostego narysowania drzewa, później zrobiłem in-memory wersję "bazy danych" i kodowaliśmy resztę.
Wsparcie dla prawdziwej bazy danych zrobiłem siedząc w hotelu w Warszawie, ale przez blisko 2 miesiące kodowaliśmy wszystko bez bazy danych i działało.

Ten in-memory coś to było takie rusztowanie, które pozwoliło nam developować, sprawdzić koncepcję i w końcu wystarczyło dodać konkretną implementację. Co ciekawe to coś pozwoliło nam przeskoczyć później jedno z założeń, które okazało się błędne. 

Z drugiej strony nieraz nie mogłem dojść do porozumienia z kimś kto zakłada, że jak coś jest to ma być. Nie wiem, coś w stylu, mamy nowe API i proxy które tłumaczy nowe API na stare... starego API używa masa ludzi i będzie używać przez wiele lat w przyszłości. Dla mnie jakby naturalne jest uznanie, że "OK, klientów nie zmusimy, więc weźmy to na klatę" i wrzucenie tego proxy z czasem do codebase głównego API (bo proxy napisał inny team, w innej technologii). Ale słyszałem stwierdzenia w stylu "nie po to płaciliśmy za zrobienie tego proxy żeby teraz to włączać do naszego kodu" i ogólnie narzekanie, że "to takie nieporządne będzie". 

Podobne posty^beta
Pierwsza zasada wyboru pracodawcy - rozumieć co robi jego firma ;-)
Cukierki, radosny chaos i takie tam, czyli Przemkowe rojenia ;-)
Raport z emigracji ;-)
W tworzeniu softu droga od tego jak jest do tego jak ma być jest ważniejsza od tego jak ma być
O wyższości aplikacji natywnych nad tymi w HTML5 - od strony developera

Najwięcej kodu != najlepszy developer

Z serii prawdy nieoczywiste ;-)

A wiesz, że jak masz w zespole developera, który pisze kodu więcej niż inni to jest duża szansa, że jest ten developer najmniej potrzebnym developerem? ;-)

W tej branży wszyscy lubimy pisać kod. Programiści, architekci, managerowie, nawet niektórzy PMowie.

Kodowanie jest fajne... ale sam fakt tego, że pisze się dużo kodu niczego nie dowodzi. Tzn. tak ma się lepszą technikę pisania, ale to tyle.

Jeśli w zespole jest ktoś kto pisze dużo kodu to często jest tak, że ten ktoś "pisze pod siebie", pisze dużo i inni muszą się do tego jakoś dopasowywać. 
Większość ludzi chce współpracować i nie ma tendencji do przepisywania "cudzego kodu", więc próbują się dopasować. Mamy wtedy sprzężenie zwrotne. X pisze na początku dużo kodu, narzuca swój styl, który jest "dziwny", inni próbują się przystosować więc piszą wolniej... a X pisze jeszcze więcej i szybciej.

Widziałem to 2 razy i 2 razy nie było to dobre. Reszta teamu się robiła smutna, byli sfrustrowani, zniechęceni, ale nie do końca wiedzieli czemu. 

Oczywiście to nie jest tak, że każdy taki przypadek jest zły.... ale zwykle o czymś mówi.

Jak masz zespół nierówny bo kogoś z dużym doświadczeniem i reszta ludzi jest młoda to to jest możliwe, i usunięcie tej osoby nie przejdzie bez problemów.... ale lepiej takiego kogoś zachęcić do oddania części pracy, bo inni będą mogli urosnąć, a ten ktoś zajmie się większymi rzeczami.
Jednak jak masz zespół, który jest w miarę równy jeśli chodzi o lata doświadczenia i nie ma tam jednej osoby, która wyraźnie odstaje umiejętnościami na plus, to masz duże szanse na problem. 
To nie jest wina tej osoby, pewnie team nie jest dopasowany. W dopasowanym teamie ludzie sobie patrzą na ręce i sobie pomagają. Jak ktoś się obsuwa to mu pomagają, jak ktoś umie coś nowego to uczy innych. Jak team jest niedopasowany to osoba, która ma najmniejsze opory przed pisaniem kodu (czyli jest najmniej podatny na bycie perfekcjonistą (w tej branży chyba wszyscy mają problem, tylko różni się intensywnością ;-)) zaczyna pisać tego kodu więcej, jeśli reszta teamu jest taka bardziej w trybie follow niż lead to się nie stawiają... 
Tu się przydaje radical candor, idealnie w wersji "Hej X, daj się innym bawić", też dobrze w wersji "X, weź k... zostaw ten kod i daj nam coś napisać, bo znów spartolisz"... niestety często jest mówienie managerowi "nie ma ticketów, bo X bierze".... albo jeszcze gorzej zamknięcie się w sobie.
Dodajmy do tego nietechnicznego PO, który chce szybko zbudować produkt i problem się będzie nakręcał... aż X się znudzi i postanowi sobie poodpoczywać i wtedy spada wydajność całego zespołu, bo inni się przyzwyczajali do wyjadanie resztek po X.... X nic nie je i jest problem.

Stąd ja zawsze próbuję zrobić test ważności przez "a co będzie jeśli Y zniknie z zespołu". I ten test dziwnie często potrafi wskazać, że osoba pisząca najwięcej kodu swoim zniknięciem może zrobić nawet więcej dobrego bo w jej miejsce wskoczą inne osoby.. To widać np. jak X jest na urlopie i nagle za kodowanie biorą się inni ludzie i fajnie to wychodzi.

Podobne posty^beta
Nie lenistwo, a strach. Prawdziwe źródło długu technicznego
Kiedy zmieniać pracę i po co? (w IT)
Kwietniowe książki
Głosowanie korespondencyjne jest tak dziurawe, że aż szkoda gadać - z perspektywy IT
Nie lejmy betonu na kod....

Nie lejmy betonu na kod....

Jak można zdefiniować gentlemana? Jako mężczyznę który jest w stanie opisać piękną i zgrabną kobietę nie używając rąk...

Jak można zdefiniować dobrego inżyniera? Jako kogoś kto potrafi opisać złożony system bez machania rękami ;-)

Mnie się wydaje, że sztuka polega na tym by widząc problem dokonać jego rozebrania na mniejsze problemy i patrzeć na te problemy jak klocki, z których można budować rozwiazanie. 

Może niektóre klocki są niepotrzebne, a znów inne przydadzą się do czegoś jeszcze? Wtedy nie budujemy ficzera X, budujemy środki do osiągnięcia tego co ma robić ficzer X i zwiększamy ilość dostępnych klocków.

W komputerach zwykle nie rozwiązujemy za każdym razem nowych problemów, a raczej inną wersję tego samego problemu.

Nagle celem staje się nie tyle tworzenie tych klocków, a używanie tych klocków do budowania czegoś większego.

Nie znasz pełnych wymagań? Nie musisz na nie czekać, identyfikujesz kluczowe problemy i je rozwiązujesz tak, że w razie czego chociaż część z nich z niedużymi modyfikacjami pozwoli rozwiązać prawdziwy problem.

Przeszedłem w życiu przez kilka firm ;-) i widzę, że często popularne jest budowanie ficzera w którym sam ficzer staje się ważny. Wydaje mi się, że ja od pewnego momentu patrzę na kawałki i znając historię umiem mniej lub więcej przewidzieć, że ten kawałek przyda się jeszcze w innych miejscach. 

Patrzę na kod (bo kod jest wg mnie nadal ważny) ale bardziej patrzę na powierzchnie styku. Co jest w środku to szczegół implementacyjny. Ważne jest co jest na zewnątrz, jaki jest interfejs. 

Do tego patrzę na kod i staram się myśleć jak on się będzie mógł zmienić, większej zmiany nie zrobimy "na raz" ale na raty się może udać. Nawet nie wiedziałem, dowiedziałem się, że to jest Strangler Fig Pattern ;-)

Żeby nie było ja potrafię napisać brzydki kod ;-) ale zwykle potrafię też zbudować coś co można dalej modyfikować i rozwijać, nie zalewam tego betonem. Zawsze gdzieś można włożyć "coś pomiędzy" i ukryć zmianę przed resztą kodu... fakt czasem jest to trudne, ale zwykle się daje.

Ogólnie lubię robić to tak, żeby komponenty zbytnio o sobie nie wiedziały.... i też nie piszę jednak za bardzo OOP kodu bo u mine class members jako zmienne to głównie jakieś "serwisy" czyli instancje klas robiących coś... zwykle jak spojrzeć to moje klasy są takie semi-bezstanowe.... choć fakt nie jest idealnie bo zdarza mi się, że metoda może modyfikować swój input.... to jest jednak inżynieria nie religia ;-)

To samo podejście próbuję stosować do większych komponentów. W moim idealnym świecie zmiana jednego komponentu jest niewidzialna dla pozostałych... Tak, to znaczy, że może jak gdzieś jest np. pipeline który dostaje format A, pierwszy kawałek przerabia na B, drugi pracuje na B i go ulepsza i w końcu publikuje...  to ja bym wolał wejście A, ale pierwszy robi (A,B) i drugi pracuje na (A,B) i produkuje A... więc z czasem mogę funkcjonalności z pierwszego przenieść do drugiego i go później zabić.

Czyli ogólnie architektura czy kod to jest tylko snapshot całego rozwiązania tu i teraz. Nie musi być doskonały, musi robić tylko to czego od niego na dziś wymagamy, a do nowych wyzwań zawsze może urosnąć.

Podobne posty^beta
W tworzeniu softu droga od tego jak jest do tego jak ma być jest ważniejsza od tego jak ma być
Rozdzielanie dwóch światów ;-)
Tagowanie postów MLem - trzeba to przepisać ;p
Struktury danych vs algorytmy
Najwięcej kodu != najlepszy developer