# Jak zajść daleko, stawiając małe kroki Wszyscy czasem bierzemy na siebie zadania, które przekraczają nasze możliwości – wynika to z naszej niezdolności do prawidłowej oceny złożonych zadań. Zastanówmy się, co z tym zrobić w odniesieniu do Twojej przygody programistycznej. ## Iteracja Niewielkie posunięcia, które nie wymykają się spod kontroli, są podstawą wielu metodologii popularnych w naszej branży, na przykład: * Agile – opiera się całkowicie na nieustannym wprowadzaniu zmian w produkcie w celu odkrycia potrzeb klienta, * produkt o kluczowej funkcjonalności (ang. _minimum viable product – MVP_) – zakłada wydanie pierwszej funkcjonalnej wersji produktu, aby umożliwić sprawdzenie jej przez rynek, a następnie wprowadzanie kolejnych zmian. Zobaczmy, jak wykorzystać podobne podejście w życiu codziennym. ### W nauce Najlepszym pomysłem byłoby: * nauczenie się części materiału, a następnie * zastosowanie go w praktyce. ![Image description](https://cdn.hashnode.com/res/hashnode/image/upload/v1646924444700/UEh9wlq4JI.jpeg) W dobrym kursie lub w dobrej książce będziesz regularnie dostawał wyzwania, które pozwolą Ci sprawdzić Twoje postępy. Jeśli uczysz się bez takich luksusów, tego rodzaju zadania będziesz musiał tworzyć sobie sam. W obu przypadkach najlepszą informacją zwrotną będzie to, czy Twój kod działa, jak należy – więc powinieneś albo wykorzystać to, czego uczysz się przy swoim dodatkowym projekcie, albo zacząć nowy. ### W pracy nad ticketem Czy często zdarza Ci się utknąć nad ticketem? Możliwe, że próbujesz robić zbyt wiele rzeczy naraz. Poszczególne zadania można zwykle podzielić na kilka części: * refaktoryzacja kodu, nad którym masz zacząć pracować, * dodanie infrastruktury kodu – helperów, różnych rodzajów aktualizacji itd., * wprowadzanie zmian w logice aplikacji, * dodanie testów integracyjnych do nowej funkcji. W większości przypadków warto zrobić osobną rewizję z każdą z tych zmian: nie ma sensu weryfikować lub cofać refaktoryzacji razem z implementacją zmian w logice. Podział na osobne rewizje, a nawet propozycje zmian pozwalają na szybszą weryfikację kodu, co przyspieszy Twoje postępy. A co jeśli nie jesteś zaznajomiony z kodem wystarczająco dobrze, aby zaplanować działania z wyprzedzeniem, albo po prostu zapomniałeś i wprowadziłeś wszystkie zmiany jednocześnie? Nie martw się: wiedza, którą zdobyłeś przy pierwszej próbie, nie pójdzie na marne – daj sobie chwilę oddechu, zacznij nową gałąź i zastosuj lub przerób część tej dużej rewizji, nad którą zacząłeś pracować. ![Image description](https://cdn.hashnode.com/res/hashnode/image/upload/v1646924446545/YEPZhQmCj.jpeg) ### W pracy nad projektami Niezależnie od tego, czy pracujesz w projektach komercyjnych, czy open source – wszędzie usłyszysz to samo: * „wydawaj szybko, wydawaj często”, * „działaj szybko i popełniaj błędy”. Możesz to zastosować nawet w pracy nad swoim osobistym projektem do nauki. Zamiast planować dużą, końcową wersję produktu, spróbuj jak najbardziej uprościć to, co budujesz. Kilka rad w tej kwestii znajdziesz w moim artykule na temat tego, [jak uczyć się podczas pracy nad własnymi projektami](https://poznaj.dev/jak-uczyc-sie-podczas-pracy-nad-wlasnymi-projektami). ## Unikaj utykania nad problemem Twoim głównym celem w pracy na podstawie iteracji jest unikanie utknięcia z problemem. Dobrze jest przeznaczyć czas na zbadanie nowego tematu; jako programista musisz być odporny na frustrację wynikającą z niewiedzy na temat tego, jak coś działa albo jak naprawić bug. Odporność ta jednak jest jak miecz obosieczny i może zwrócić się przeciwko Tobie. Korzyści ze zgłębiania tematu będą coraz mniejsze, aż w końcu takie dokształcanie się stanie się zwyczajnym marnotrawstwem czasu. A kiedy do tego dojdzie, będziesz już dobrze obeznany w temacie i na dobrej drodze do naprawienia problemu, a co za tym idzie – niełatwo będzie Ci odpuścić. Zobaczmy, jak uniknąć takich pułapek! ![Image description](https://cdn.hashnode.com/res/hashnode/image/upload/v1646924448442/rvgKqUdag.jpeg) ### Nie jesteś sam Najczęściej nie pracujesz sam: w Twoim środowisku znajdują się ludzie, którzy mogą Ci pomóc. Jako początkujący programista możesz tu popełnić błąd w dwojaki sposób: * poprosić o pomoc zbyt szybko, * poprosić o pomoc zbyt późno. Co to znaczy „zbyt szybko”, a co „zbyt późno”? To zależy od sytuacji Twojego zespołu. Na myśl od razu przychodzą mi dwie sytuacje: * zespół pracuje pod dużą presją – trzeba zażegnać kryzys, więc żaden bardziej doświadczony programista nie ma czasu, żeby Ci pomóc; * przejmujesz projekt po programiście, który kończy pracę za dwa tygodnie, więc Twoim głównym zadaniem jest uzyskanie od niego jak najwięcej informacji. Radzę określić w zespole konkretne zasady, a potem się ich trzymać. Jeżeli ustalicie, że cztery godziny walki z ticketem bez żadnych rezultatów to za dużo, to po bezskutecznym upływie tych czterech godzin poproś o pomoc. ![Image description](https://cdn.hashnode.com/res/hashnode/image/upload/v1646924450174/NvrVNxNJB.jpeg) ### Czasem lepiej odpuścić Pomysł nie stanie się nagle lepszy tylko dlatego, że przeznaczyłeś na jego wprowadzenie bardzo dużo czasu. Wręcz przeciwnie: takim działaniem tylko pokażesz, że nie jest wykonalny albo że nie jest tak prosty, jak zakładałeś. Miej świadomość efektu utopionych kosztów – najlepiej będzie z wyprzedzeniem określić czas, jaki chcesz przeznaczyć na zadanie, zanim odpuścisz jego realizację, a następnie porzucić zadanie, jeśli zajmie Ci ono więcej czasu, niż chciałeś na nie przeznaczyć. Odpuszczenie ticketu w zależności od jego rodzaju może znaczyć pozostawienie go innemu programiście lub całkowite zaniechanie pracy nad nim, przynajmniej w danym momencie. ![Image description](https://cdn.hashnode.com/res/hashnode/image/upload/v1646924451902/-s1xvBoi9e.jpeg) ## Wypatruj informacji zwrotnej w każdej sytuacji Każdy etap interakcji jest momentem, w którym możemy – i powinniśmy – uzyskać feedback. Dzięki niemu wprowadzimy potrzebne korekty i upewnimy się, że zmierzamy w dobrą stronę. Istnieje bardzo dużo rodzajów informacji zwrotnej, na które można zwrócić uwagę: * testy automatyczne wykonywane lokalnie lub w ramach CI, * weryfikacja kodu przez bardziej doświadczonego kolegę po fachu lub mentora, * zebranie informacji zwrotnej po prezentacji produktu na zewnątrz. Chcesz dowiedzieć się więcej? Przeczytaj artykuł o [pętlach informacji zwrotnej](https://poznaj.dev/jak-przyspieszyc-prace-dzieki-informacji-zwrotnej).