Gutek niedawno napisał o swoich przemyśleniach odnośnie programowania podczas jazdy samochodem. Takie myśli mogą nas dopaść wszędzie. Od tego naprawdę nie ma ucieczki… o ile jesteśmy faktycznie odpowiednio zaangażowani.
Mnie ostatnio dopadły one podczas grania w doskonałe NFS: Most Wanted na Androida. Jeszcze p…asja? Czy już p…ierdolec?
Dla tych którzy nie grali: są to wyścigi samochodowe;). Gracz otrzymuje kilka trybów wyścigów. Jest tam oczywiście standardowe “dojedź pierwszy do mety”, jest “dojedź do mety w określonym czasie”… Ale tryb, który wywołał we mnie programistyczne myśli, to: “Speed run”.
Speed Run polega na przejechaniu całej trasy uzyskując jak najwyższą średnią prędkość od startu do mety. Zdobycie złotych medali w tej kategorii sprawiało mi spore kłopoty dopóki nie zauważyłem, że do problemu trzeba podejść w inny niż zwykle sposób.
W każdym wyścigu da się wykonać masę interesujących czynności. A to efektownie podriftować na zakrętach. A to wycisnąć z fury maksymalnego kopa doładowując “nitro”. A to rozwalić konkurenta albo radiowóz. W Speed Run trzeba jednak zapomnieć o większości z tych możliwości. Tam nie ścinamy zakrętów, bo nikt nas nie ściga. Można pokonywać pętle po zewnętrznej stronie, bo nie zależy nam na czasie. Nie staramy się wchodzić w zakręty driftem, bo na kilka sekund obniża to aktualną prędkość. Liczy się tylko i wyłącznie wysoka prędkość, o którą łatwiej przy zewnętrznej bandzie nawet jeśli przez to przejedziemy te kilkadziesiąt metrów więcej w skali całej trasy. Nie odpalamy też nitro jadąc z wystarczającą szybkością tylko po to, żeby jechać przez chwilę jeszcze szybciej. Nitro zostawiamy na sytuacje, w których ta prędkość znacznie spadnie, na przykład z powodu stłuczki – aby jak najszybciej powrócić do podbijania średniej.
Nie staramy się przywalić goniącego nas radiowozu. Co z tego że fajnie się roztrzaska dodając bonusowe nitro, skoro na istotną chwilę nas to spowolni?
Efekt jest taki, że dojeżdżamy do mety ze średnio imponującym czasem. Podczas jazdy nie rozwalimy policji i się nie poślizgamy. Nie zwracamy uwagi na skracanie trasy, bo tu nie liczy się każdy metr. Generalnie: w normalnym wyścigu tym sposobem jazdy dojechalibyśmy pewnie na ostatnim miejscu.
Ale tutaj się to sprawdza.
I dochodzimy do sedna. My, jako programiści, też mamy cały wachlarz opcji do wykorzystania podczas codziennej pracy. Czym w Twoim zespole jest drift – może próbą wdrożenia nowego pomysłu do projektu, potencjalnie zakończoną porażką? Czym jest nitro – może zostaniem przez kilka dni po godzinach? Czym jest ścięcie zakrętu – może jakimś refactoringiem czekającym aż ktoś się wreszcie za niego weźmie?
Jak często podczas pracy zastanawiasz się w jakim “trybie” pracujesz, a w jakim pracować powinieneś? Czy w skali całego zespołu ustalacie co jest aktualnie priorytetem? Jakie asy z programistycznego rękawa wyciągać podczas aktualnego sprintu…bo nie każdy z nich zawsze znajduje zastosowanie? Jakie jest Wasz cel w danym momencie? Efektowna jazda? Średnia prędkość? Najkrótsza trasa? Imponujący czas?
Jeśli wszyscy pracujący nad projektem mieliby ten sam wspólny cel i zdefiniowali techniki oraz czynności nadające się do osiągnięcia właśnie jego, być może organizacja pracy uległaby poprawie? Być może dałoby się uniknąć nieporozumień i konfliktów? Być może więcej projektów kończyłoby się sukcesem?
świetne porównanie!
Hehe :) Na chłopski rozum :D
Porównanie jak najbardziej trafne, natomiast “bo nie zależy nam na czasie” i “dojeżdżamy do mety ze średnio imponującym czasem” – nie prawda. Jak najbardziej zależy nam na czasie, ponieważ średnia prędkość jest ilorazem drogi i czasu. Droga jest stała natomiast jedyną zmienną w równaniu jest czas, na podstawie którego później jest obliczana średnia prędkość – im krótszy czas tym większa średnia prędkość. Średnią prędkością może być produktywność (chwilowa). Długa jazda na wysokich obrotach zwykle źle się kończy :)
Czytając artykuł bardzo szybko przywołała mi się w pamięci książka Orsona Scotta Carda “Gra Endera” (http://lubimyczytac.pl/ksiazka/47898/gra-endera) – bardzo polecam jeśli ktoś nie czytał (ktoś nie czytał???). Wychodzenie poza ramy standarodwego – bezpiecznego – myślenia, podejmowanie nieszablonowych decyzji. Być może część okaże się porażką, inne doprowadzą nas do zwycięstwa i przetrą nowe szlaki, którymi będziemy mogli (nawiązując do poprzedniego posta) podzielić się ze społecznością.
hexcrafter,
Przytoczone równanie nie jest trafne – tutaj droga nie jest stała. Tak jak pisałem – można jechać zewnętrznym pasem przy zakrętach, sporo się przy tym nadrabia. Do tego dochodzą różne skróty, w tym trybie zbędne, ale nie chciałem zbytnio wnikać w szczegóły:).
Sebastian,
Nie czytałem Gry Endera, zapiszę sobie na przyszłość, thx:).
Start i meta nie zmieniają się w trakcie gry. Dystans od A do B zawsze jest stały. Droga którą pokonasz nie ma znaczenia. Jaki jest sens średniej prędkości jeśli ostateczny czas jest dłuższy a na dodatek mogłeś kołować lub jechać w przeciwnym kierunku ?? Odnośnie tego przypomniał mi się dowcip:
Na budowie Kowalski lata w te i z powrotem z pustą taczką.
Widząc to kierownik pyta:
- Co tak z tą pustą taczką latacie?
- Panie kierowniku – mówi Kowalski – taki zapi3&|)0I, że nie ma kiedy załadować.
// no offence
Pingback: dotnetomaniak.pl
hexcrafter,
Start i meta się nie zmieniają, ale trasa między nimi – tak. Trasa minimalna to pokonywanie zakrętów po wewnętrznej stronie. Trasa maksymalna – po zewnętrznej. Jechanie po wewnętrznej stronie skraca trasę, ale przez to pokonuję ostrzej zakręt i spada prędkość. Pokonując zakręty po zewnętrznej stronie zwiększam dystans utrzymując wysoką prędkość.
O żadnym offence nie ma tu mowy, ale chyba mówimy o różnych rzeczach… bo zupełnie nie rozumiem. Ja piszę konkretnie o zasadach gdy NFS – moge krążyć i godzinę po trasie, jeśli w trakcie tej godziny utrzymam wysoką średnią prędkość to wygrałem.
Takie podejście sprawdza się tylko w grze (chociaż może to być rozwiązane na kilka sposobów). Nie mogę sobie wyobrazić zastosowania trybu średniej prędkości w pracy nad projektem.
Porownanie mi sie bardzo podoba. Procent, co do Gry Endera, to zanotuj koniecznie i najlepiej podbij troche priorytet, bo ksiazka jest genialna. Pierwsze miejsce na mojej liscie od lat. Polecam tez kolejne czesci i w ogole zadna ksiazka O. S. Card’a nie byla dla mnie strata czasu.
A co do NFSa na andku, to z kolei ja bede musial sprobowac ;)
zabanet,
ciesze się, że spotykam tu takiego fana twórczości Carda jak ja :) Nie chciałem ciągnąć – jakby nie patrzeć pobocznego – wątku ale faktycznie “Gra Endera” to książka którą można i trzeba wpisać na listę “Must Read”.
A nawiązując do wątku to ja zdecydowanie dzisiaj snuje leniwie po zewnętrznej krawędzi jezdni podziwiając wystawy mijanych sklepów. Taki dzień… może to zmiana pogody. Jutro będę musiał zapewne ściąć pare zakrętów. Tutaj dochodzi coś takiego jak czynnik ludzki. W skali całego projektu mogą się wydarzyć różne rzeczy na które nie mamy żadnego wpływu – ktoś się rozchoruje, ktoś źle się czuje czy zwyczajnie zabrnął w jakiś zaułek (i nie może wcisnąć R żeby wrócić na tor). Ale jako programiści mamy różne narzędzia, o których wspomniał % dzięki którym możemy utrzymać dobrą średnią.
zabanet, Sebastian,
OK podbijam priorytet w takim razie:). Jest teraz na 4 miejscu – więc w moim tempie wezmę się za nią w okolicach Bożego Narodzenia.
Dla mnie wniosek z postu jest jeden: jesli nad czyms pracujemy, powinniśmy się skupiać tylko na tej jednej rzeczy (można pójść w coś w stylu Pomodoro). I wtedy osiągniemy lepszą prędkość. Z mojego doświadczenia, takie podejście naprawdę się sprawdza.