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