Jak zajść daleko, stawiając małe kroki
Tags: beginners, polish
Published: 2022-03-10 11:21:02

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://dev-to-uploads.s3.amazonaws.com/uploads/articles/5jsed4sh5qi56pfswowj.jpg)

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://dev-to-uploads.s3.amazonaws.com/uploads/articles/9n86la9ftbdjg8hqloiw.jpg)

### 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://dev-to-uploads.s3.amazonaws.com/uploads/articles/fxrlxdtxyfzavttkp3o8.jpg)

### 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://dev-to-uploads.s3.amazonaws.com/uploads/articles/0zc8h19ivzc60bya6fbl.jpg)

### 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://dev-to-uploads.s3.amazonaws.com/uploads/articles/o837xgwltfkkmmz7hqod.jpg)

## 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).