What do you think?
Rate this book
Getting Things Programmed. Droga do efektywności
Na pracę programisty składa się bardzo wiele zadań. Nawet jeżeli 90% czasu spędzamy na „klepaniu w klawiaturę”, to w trakcie tych działań wykonujemy całą gamę najróżniejszych czynności.
Sprawne sterowanie swoją uwagą, planowanie zadań czy umiejętność ich oszacowania to wiedza, której brakuje większości programistów. Często nie zdajemy sobie nawet sprawy z istnienia problemów spowalniających naszą pracę.
W niniejszej książce Autor przedstawia bogaty wachlarz wyzwań stojących przed świadomym programistą. Nie poprzestaje na tym: wysuwa propozycje samodoskonalenia. Opisuje sprawdzone recepty pomagające zrozumieć codzienne problemy, rozbija je na czynniki pierwsze i przygotowuje do walki o lepszą organizację czasu.
Sprawne sterowanie swoją uwagą, planowanie zadań czy umiejętność ich oszacowania to wiedza, której brakuje większości programistów. Często nie zdajemy sobie nawet sprawy z istnienia problemów spowalniających naszą pracę.
W niniejszej książce Autor przedstawia bogaty wachlarz wyzwań stojących przed świadomym programistą. Nie poprzestaje na tym: wysuwa propozycje samodoskonalenia. Opisuje sprawdzone recepty pomagające zrozumieć codzienne problemy, rozbija je na czynniki pierwsze i przygotowuje do walki o lepszą organizację czasu.
184 pages, Paperback
Published June 22, 2016
7 people are currently reading
61 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 7 of 7 reviews
September 10, 2017
Dla mnie to książka, która mimo że ma parę ciekawych fragmentów i wiedzy z której warto skorzystać jak np o estymowaniu tasków, jest mocno przereklamowana. Składa się z kompilacji znanych książek a w zasadzie ich fragmentów czytanych przez autora. Wiele rzeczy nie jest odkrywczych. Z drugiej strony patrząc na statystycznego Polskiego czytelnika, który zwyczajnie niewiele czyta to może być dobra pozycja. Bo jest krótka i coś tam próbuje przemycić, więc dla totalnych nowicjuszy w poruszanych tematach może być interesująca. Jak zwykle parę bardziej interesujących cytatów:
Już kilka spraw czekających na podjęcie decyzji skutkuje poczuciem, że masz dużo do zrobienia. Niestety jest to tylko poczucie, a nie rzeczywistość. Rzeczywistość jest często taka, że masz do zrobienia przeciętną ilość rzeczy oraz jednocześnie dużo drobnych decyzji do podjęcia, które Cię rozpraszają.
Zrób cokolwiek. Piszę to całkowicie poważnie. Podejmij jakiekolwiek działanie zmierzające w kierunku realizacji danego przedsięwzięcia. I nie ma żadnego znaczenia, co konkretnie zrobisz. Zrób cokolwiek. Im dłużej się zastanawiasz nad niedoprecyzowanym pomysłem, tym bardziej w procesie myślenia komplikujesz to zagadnienie. Jest tak dlatego, że niedoprecyzowane pomysły zawierają w sobie wiele potencjalnych możliwości rozwiązania i wiele ścieżek, którymi można podążyć. Im dłużej się zastanawiasz, tym więcej pojawia się pytań i dylematów. W końcu zrezygnowany stwierdzasz, że po kilku godzinach spędzonych nad tematem wiesz o wiele mniej niż na początku. Podjęcie jakiegokolwiek działania redukuje liczbę możliwości, które jednocześnie rozważasz. Skupią Twoją uwagę na jednym konkretnym aspekcie zagadnienia.
Gdy zaczynasz pisać, musisz skonkretyzować swoje myśli, zadać sobie dodatkowe pytania doprecyzowujące. Pisząc pełne zdanie, przekładasz swoje uczucia (patrz opis na początku tego rozdziału) w rzeczy, które da się wykonać.
>> Ten fragment bardzo mi się podoba bo odpowiada, jak czasami podchodzę do problemu zamiast w nieskończoność analizować co mam w zasadzie zrobić, czasami warto rozpoznać problem bojem i stopniowo się w niego zagłębiać.
Dalsze cytaty:
To znaczy, że im precyzyjniej dekomponujesz zadania, tym większa jest szansa, iż wystarczająco przewidywalnie je oszacujesz
Wielki niekończący się projekt to jedna z rzeczy, które najbardziej demotywują programistów.
Spike to działania rozpoznawcze, których celem jest pozyskanie wiedzy na temat zadania. Chodzi o to, aby się dowiedzieć, jak w ogóle zabrać się do implementowania funkcjonalności, jak ją zdekomponować, jak oszacować.
Mimo stosowania tej metody wciąż najbardziej irytującym pytaniem, które przełożony może zadać programiście, jest: Ile Ci to jeszcze zajmie?.
Dokładność wzrasta, ponieważ redukowana jest zmienność w projekcie poprzez podejmowanie wiążących decyzji co do wymagań, architektury, przepływów sterowania itd. Brak tych decyzji lub ich zmiany mogą sprawić, że przez cały okres prac będziemy mieli do czynienia nie ze stożkiem niepewności, lecz z prostokątem niepewności
Dokładność szacowania wzrasta wyłącznie wraz z ograniczaniem zmienności podczas prac oraz podejmowaniem wiążących decyzji. Czy ochłonąłeś już po tej niewygodnej informacji, że stożek nie zwęża się sam z siebie?
W naturze zleceniodawców[10] drzemie niepohamowana chęć do przewidywania przyszłości. Oni chcą po prostu wiedzieć, ile zajmie dana praca i ile trzeba będzie za nią zapłacić
Po pierwsze: dekompozycja. Jeśli przed oszacowaniem zdekomponujesz zadanie, a następnie oszacujesz podzadania, wpłynie to na zmniejszenie końcowego błędu oszacowania dla całego zadania (McConnell, 2006). Dlatego zanim przystąpisz do szacowania, w pierwszej kolejności zdekomponuj zadanie[13]. Dekomponowanie zadania jest ujemnie skorelowane z błędem oszacowania. Pierwszą trudnością,
Moje propozycje do zamieszczenia na liście kontrolnej szacowania: Czy uwzględniłeś aktualizację dokumentacji użytkownika? Czy uwzględniłeś czas na aktualizację dokumentacji technicznej? Czy uwzględniłeś testy deweloperskie? Czy uwzględniłeś zadanie przygotowania skryptów migracyjnych? Czy uwzględniłeś czas na odtworzenie (o ile to konieczne) testów do istniejącego kodu? Czy uwzględniłeś czas na wykonanie niewielkiej, ale koniecznej refaktoryzacji kodu? Czy spisałeś założenia przyjęte na potrzeby szacowania? Czy w związku z tym zadaniem wymagana jest zmiana konfiguracji serwera? Czy uwzględniłeś czas na przygotowanie krótkiego podsumowania zadania?
Gdy spotykasz zadanie, którego „nie da się” oszacować, natychmiast je zdekomponuj.
Okazuje się, że brak wiedzy na temat jednego podzadania w jakiś sposób sprawia, iż zadanie wydaje się nie do oszacowania. Gdy już wyizolujesz część, której naprawdę nie potrafisz oszacować, załóż jakiś czas na pracę nad nią. Przyjmij na przykład, że „dowiadywanie się, jak działa mechanizm timerów” zajmie dwie godziny. Ostatecznie nie ma żadnego znaczenia, czy to zajmie akurat dwie godziny, czy może pięć, czy może jedną. Przyjęcie jakiejś wartości ma następujące skutki: odblokowuje Twoją pracę — po prostu możesz rozpocząć wgłębianie się w zadanie, zamiast zastanawiać się, jak je oszacować; zmienia perspektywę szacowania z „Ile czasu to zajmie?” na „Ile czasu chcę na to przeznaczyć?”. Gdy nie potrafisz oszacować, ile czasu zajmie zadanie, zastanów się, ile czasu chcesz na nie przeznaczyć.
analityczną metodę szacowania trzypunktowego PERT, w której podpierając się nieco statystyką, wyliczamy oszacowanie dla zadania według metody: Zdekomponuj zadanie. Oszacuj za pomocą trzech wielkości: optymistycznej, prawdopodobnej i pesymistycznej. Zweryfikuj oszacowanie z listą kontrolną szacowania. (Jeśli się okaże, że powinieneś dodać nowe podzadanie do dekompozycji — dodaj je, a następnie idź do 1). Oblicz wartość oszacowania. Uwzględnij odchylenie standardowe wynikające z przyjętej przez Ciebie pewności oszacowania.
Wyraźne oddzielanie pracy od odpoczynku to element higieny w pracy programisty.
>> No i totalna bzdura w tej książce z jednej strony pisze o FLOW i byciu w strefie:
Mihály Csíkszentmihályi, psycholog węgierskiego pochodzenia, opisał stan psychiczny, który nazwał „przepływem” (ang. flow) (Csíkszentmihályi, 2005). Autor nazywa to zjawisko „doświadczeniem stanu optymalnego” i określa je jako maksymalne skupienie i całkowite oddanie się wykonywanej czynności.
>> co jest prawdą i jest zasadniczo tym o co chodzi i autor pomieszał to z tym, że programista w takim stanie często zrobi za dużo, zasada m.in YAGNI i że trzeba się ze stanu FLOW wybijać BZDURA
Już kilka spraw czekających na podjęcie decyzji skutkuje poczuciem, że masz dużo do zrobienia. Niestety jest to tylko poczucie, a nie rzeczywistość. Rzeczywistość jest często taka, że masz do zrobienia przeciętną ilość rzeczy oraz jednocześnie dużo drobnych decyzji do podjęcia, które Cię rozpraszają.
Zrób cokolwiek. Piszę to całkowicie poważnie. Podejmij jakiekolwiek działanie zmierzające w kierunku realizacji danego przedsięwzięcia. I nie ma żadnego znaczenia, co konkretnie zrobisz. Zrób cokolwiek. Im dłużej się zastanawiasz nad niedoprecyzowanym pomysłem, tym bardziej w procesie myślenia komplikujesz to zagadnienie. Jest tak dlatego, że niedoprecyzowane pomysły zawierają w sobie wiele potencjalnych możliwości rozwiązania i wiele ścieżek, którymi można podążyć. Im dłużej się zastanawiasz, tym więcej pojawia się pytań i dylematów. W końcu zrezygnowany stwierdzasz, że po kilku godzinach spędzonych nad tematem wiesz o wiele mniej niż na początku. Podjęcie jakiegokolwiek działania redukuje liczbę możliwości, które jednocześnie rozważasz. Skupią Twoją uwagę na jednym konkretnym aspekcie zagadnienia.
Gdy zaczynasz pisać, musisz skonkretyzować swoje myśli, zadać sobie dodatkowe pytania doprecyzowujące. Pisząc pełne zdanie, przekładasz swoje uczucia (patrz opis na początku tego rozdziału) w rzeczy, które da się wykonać.
>> Ten fragment bardzo mi się podoba bo odpowiada, jak czasami podchodzę do problemu zamiast w nieskończoność analizować co mam w zasadzie zrobić, czasami warto rozpoznać problem bojem i stopniowo się w niego zagłębiać.
Dalsze cytaty:
To znaczy, że im precyzyjniej dekomponujesz zadania, tym większa jest szansa, iż wystarczająco przewidywalnie je oszacujesz
Wielki niekończący się projekt to jedna z rzeczy, które najbardziej demotywują programistów.
Spike to działania rozpoznawcze, których celem jest pozyskanie wiedzy na temat zadania. Chodzi o to, aby się dowiedzieć, jak w ogóle zabrać się do implementowania funkcjonalności, jak ją zdekomponować, jak oszacować.
Mimo stosowania tej metody wciąż najbardziej irytującym pytaniem, które przełożony może zadać programiście, jest: Ile Ci to jeszcze zajmie?.
Dokładność wzrasta, ponieważ redukowana jest zmienność w projekcie poprzez podejmowanie wiążących decyzji co do wymagań, architektury, przepływów sterowania itd. Brak tych decyzji lub ich zmiany mogą sprawić, że przez cały okres prac będziemy mieli do czynienia nie ze stożkiem niepewności, lecz z prostokątem niepewności
Dokładność szacowania wzrasta wyłącznie wraz z ograniczaniem zmienności podczas prac oraz podejmowaniem wiążących decyzji. Czy ochłonąłeś już po tej niewygodnej informacji, że stożek nie zwęża się sam z siebie?
W naturze zleceniodawców[10] drzemie niepohamowana chęć do przewidywania przyszłości. Oni chcą po prostu wiedzieć, ile zajmie dana praca i ile trzeba będzie za nią zapłacić
Po pierwsze: dekompozycja. Jeśli przed oszacowaniem zdekomponujesz zadanie, a następnie oszacujesz podzadania, wpłynie to na zmniejszenie końcowego błędu oszacowania dla całego zadania (McConnell, 2006). Dlatego zanim przystąpisz do szacowania, w pierwszej kolejności zdekomponuj zadanie[13]. Dekomponowanie zadania jest ujemnie skorelowane z błędem oszacowania. Pierwszą trudnością,
Moje propozycje do zamieszczenia na liście kontrolnej szacowania: Czy uwzględniłeś aktualizację dokumentacji użytkownika? Czy uwzględniłeś czas na aktualizację dokumentacji technicznej? Czy uwzględniłeś testy deweloperskie? Czy uwzględniłeś zadanie przygotowania skryptów migracyjnych? Czy uwzględniłeś czas na odtworzenie (o ile to konieczne) testów do istniejącego kodu? Czy uwzględniłeś czas na wykonanie niewielkiej, ale koniecznej refaktoryzacji kodu? Czy spisałeś założenia przyjęte na potrzeby szacowania? Czy w związku z tym zadaniem wymagana jest zmiana konfiguracji serwera? Czy uwzględniłeś czas na przygotowanie krótkiego podsumowania zadania?
Gdy spotykasz zadanie, którego „nie da się” oszacować, natychmiast je zdekomponuj.
Okazuje się, że brak wiedzy na temat jednego podzadania w jakiś sposób sprawia, iż zadanie wydaje się nie do oszacowania. Gdy już wyizolujesz część, której naprawdę nie potrafisz oszacować, załóż jakiś czas na pracę nad nią. Przyjmij na przykład, że „dowiadywanie się, jak działa mechanizm timerów” zajmie dwie godziny. Ostatecznie nie ma żadnego znaczenia, czy to zajmie akurat dwie godziny, czy może pięć, czy może jedną. Przyjęcie jakiejś wartości ma następujące skutki: odblokowuje Twoją pracę — po prostu możesz rozpocząć wgłębianie się w zadanie, zamiast zastanawiać się, jak je oszacować; zmienia perspektywę szacowania z „Ile czasu to zajmie?” na „Ile czasu chcę na to przeznaczyć?”. Gdy nie potrafisz oszacować, ile czasu zajmie zadanie, zastanów się, ile czasu chcesz na nie przeznaczyć.
analityczną metodę szacowania trzypunktowego PERT, w której podpierając się nieco statystyką, wyliczamy oszacowanie dla zadania według metody: Zdekomponuj zadanie. Oszacuj za pomocą trzech wielkości: optymistycznej, prawdopodobnej i pesymistycznej. Zweryfikuj oszacowanie z listą kontrolną szacowania. (Jeśli się okaże, że powinieneś dodać nowe podzadanie do dekompozycji — dodaj je, a następnie idź do 1). Oblicz wartość oszacowania. Uwzględnij odchylenie standardowe wynikające z przyjętej przez Ciebie pewności oszacowania.
Wyraźne oddzielanie pracy od odpoczynku to element higieny w pracy programisty.
>> No i totalna bzdura w tej książce z jednej strony pisze o FLOW i byciu w strefie:
Mihály Csíkszentmihályi, psycholog węgierskiego pochodzenia, opisał stan psychiczny, który nazwał „przepływem” (ang. flow) (Csíkszentmihályi, 2005). Autor nazywa to zjawisko „doświadczeniem stanu optymalnego” i określa je jako maksymalne skupienie i całkowite oddanie się wykonywanej czynności.
>> co jest prawdą i jest zasadniczo tym o co chodzi i autor pomieszał to z tym, że programista w takim stanie często zrobi za dużo, zasada m.in YAGNI i że trzeba się ze stanu FLOW wybijać BZDURA
July 22, 2020
Chyba do tej pory najlepsza książka o organizacji własnego czasu, jaką czytałem. Szybka, prosta, bez zbędnych opisów czy filozofowania. To nie jest książka TYLKO dla programistów - jasne, jest tam dużo że świata IT, za to porady są uniwersalne i dla każdego. Po "10 kroków do produktywności" autorstwa Team Nozbe to najlepsza pozycja o GTD, jaką czytałem.
April 1, 2020
Mix technik z innych książek o efektywności dostosowany do ujęcia programistycznego i zgrabnie skondensowany w pigułce. Bez zbędnej rozwlekłości, książeczka na 1 dzień. Mało wartości dodanej własnoręcznie przez autora.
March 20, 2017
Książka o metodach prowadzących do zwiększenia efektywności pracy programisty. Wśród omówionych technik znajdują się m.in. GTD, Agile, Kanban. Jest też domieszka psychologii z zakresu teorii Flow i Mindfulness. Wszystko na podstawie osobistych doświadczeń autora.
Więcej o książce i o tym, czego można się z niej nauczyć: http://mariuszbartosik.com/books/gett...
Więcej o książce i o tym, czego można się z niej nauczyć: http://mariuszbartosik.com/books/gett...
January 22, 2017
Przeczytałem zachęcony bardzo pozytywnymi opiniami, niestety bardzo się zawiodłem. Spodziewałem się jakiejś autorskiej metody na zwiększenie jakości w pracy lub chociaż podzielenie się swoimi doświadczeniami w temacie. Ta książka to zlepek metod i wiedzy o których jeśli pracujesz przynajmniej pół roku już dawno słyszałeś. Dowiesz się tutaj po łebkach o takich rzeczach jak GTD, Kanban, Mindfulness, Agile czy Pommodoro. Jeśli jakimś cudem o nich nie słyszałeś to może to być ciekawy wstęp, jednak jeśli o nich wiesz to polecam sięgąć raczej do książek wymienionych w bogatej bibliografii.
Najbardziej w całej książce zezłościł mnie fragment o metodzie Disneya: "Metoda ta jest znana i szeroko opisywana, lecz nigdy nie zadałemsobie trudu, aby sprawdzić, czy Walt Disney rzeczywiście się nią posługiwał.", myślę że jest on doskonałym podsumowaniem całej książki.
Książka nie wiem dla kogo bo raczej nie dla ludzi którzy mieli styczność z zawodowym programowaniem więc raczej nie polecam, ewentualnie czytać metodą Balcerowicza:)
Najbardziej w całej książce zezłościł mnie fragment o metodzie Disneya: "Metoda ta jest znana i szeroko opisywana, lecz nigdy nie zadałemsobie trudu, aby sprawdzić, czy Walt Disney rzeczywiście się nią posługiwał.", myślę że jest on doskonałym podsumowaniem całej książki.
Książka nie wiem dla kogo bo raczej nie dla ludzi którzy mieli styczność z zawodowym programowaniem więc raczej nie polecam, ewentualnie czytać metodą Balcerowicza:)
September 3, 2016
Ksiazka przeznaczona glownie dla studentow i poczatkujacych programistow, chyba ze ... jestes doswiadczonym programista ktory nigdy nie slyszal o Pomodoro i Kanban - wtedy powinienes przeczytac ta ksizake. Wiedza podana jest w sposob zwiezly i przystepny. Wartoscia dodana
tej ksiazki jest bibliografia - naprawde ciekawy zestaw pozycji do przeczytania.
tej ksiazki jest bibliografia - naprawde ciekawy zestaw pozycji do przeczytania.
August 16, 2016
Great for not so experienced developer
Displaying 1 - 7 of 7 reviews