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.

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ć.

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.

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!

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.

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.

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.