Analizowanie problemów i poszukiwanie rozwiązań to chleb powszedni każdego programisty. Jednak spore poczucie zagubienia pojawia się u mnie głównie w momentach, kiedy problemy nie dotyczą pisanego przeze mnie kodu, a np. kodu innego modułu w projekcie lub dotyczą narzędzia, którego używam i nie zagłębiam się w jego działanie. Wtedy poszukiwanie rozwiązania zwykle nie ogranicza się do StackOverflow i nierzadko wymaga zaprzęgnięcia do walki cięższej broni.
Co rozumiem przez problemy techniczne?
Przez sformułowanie „problemy techniczne” w tym wpisie rozumiem wszelkie kłopoty z nieprawidłowym działaniem aplikacji, nad którą pracuję, a które nie wynikają bezpośrednio z kodu, który piszę. W moim obecnym przypadku to błędy wynikające np. z nieaktualnych modułów składających się na środowisko, w którym pracuję, błędy narzędzi, z których korzystam (takich jak Docker), problemów z bazami danych innych modułów czy kłopotów z korzystaniem z różnych VPNów.
Czego nie rozumiem przez problemy techniczne?
Do moich obowiązków należy rozwijanie i konserwacja kodu pisanego w TypeScript, więc zagadnienia związane z front-endową warstwą mojej aplikacji nie są wg mnie problemami technicznymi. Przez ostatni rok na tyle poznałam back-endowe API, z którym się komunikuję, że jestem w stanie wyłapać niektóre z niezgodności (np. stwierdzić że back-end zwraca coś w innej formie niż zakładano na froncie). Takich sytuacji nie klasyfikuję jako problemy techniczne, ot, codzienna praca w projekcie.
Dokumentacja projektu
O korzystaniu z dokumentacji projektu wspomniałam już we wpisie dotyczącym instalacji projektu (tutaj). Szczególnie w początkowej fazie wdrażania, dokumentacja była dla mnie sporym wsparciem. Okazało się bowiem, że pewne etapy instalacji muszą być powtarzane przy każdej aktualizacji projektu (np. budowanie projektu czy uruchamianie kontenerów).
Dokumentacja narzędzia
Jednym z większych problemów w moim obecnym projekcie była (i czasami nadal bywa) obsługa Dockera. Dokumentacja, a szczególnie lista komend pomogły mi nie raz wyjść z opresji. W tej chwili mam już opracowane konkretne procedury, które krok po kroku opisują działania niezbędne do naprawienia problemu.
Wujek Google
Samo „wyguglanie” treści nieznanego błędu potrafi czasami sprawić, że jestem w stanie samodzielnie naprawić problem. W wynikach wyszukiwania najczęściej znajduję linki do zgłoszeń w StackOverflow lub na GitHubie, gdzie z treści konwersacji mogę wiele dowiedzieć się o zaistniałym problemie i sposobach rozwiązania.
Oficjalne kanały zgłaszania problemów technicznych
W moim projekcie funkcjonuje coś na kształt oficjalnego miejsca do zgłaszania błędów. To po prostu wydzielony kanał w komunikatorze Slack dedykowany problemom technicznym. Korzystanie z takiego rozwiązania ma dwa zasadnicze plusy: po pierwsze można szybko uzyskać pomoc, a po drugie taka forma współpracy wymaga precyzyjnego sformułowania swojego problemu i wyartykułowania podjętych kroków do jego rozwiązania. Niejednokrotnie zdarza mi się, że taka analiza problemu pomaga mi samodzielnie rozwiązać problem lub znacznie zbliża mnie do jego rozwiązania.
Proszenie o pomoc osób z zespołu
Tutaj rzecz ma się podobnie jak z kanałami dedykowanymi do rozwiązywania problemów technicznych: kiedy chcę poprosić o pomoc kogoś z zespołu, staram się najpierw wyczerpać znane mi sposoby rozwiązywania problemów i dokładnie przeanalizować kiedy problem występuje, co go wywołuje, etc. Również często efektem tej analizy jest samodzielne poradzenie sobie z problemem. Jeśli pomimo szczegółowej analizy nadal sama nie potrafię rozwiązać problemu, to przynajmniej jestem pewna, że wypróbowałam wszystkie znane możliwości rozwiązania (oczywiście bez przesady: nie poświęcam na rozwiązanie problemu, którego nie rozumiem 2 dni, to stanowczo zbyt duże marnowanie czasu, zwłaszcza jeśli w zespole są osoby, które poradziłyby sobie z rozwiązaniem o wiele szybciej).
Procedury
Procedury to mój własny sposób radzenia sobie z problemami technicznymi. Najczęściej błędy, które napotykam prędzej czy później do mnie powrócą i istnieje spora szansa, że nie będę pamiętać jak go rozwiązałam w przeszłości. Dlatego właśnie rozpisuję sobie pewne sekwencje działań aby wiedzieć co pomogło mi rozwiązać dany problem. To scenariusze co należy wykonać krok po kroku żeby poradzić sobie z daną sytuacją.
A może olej?
Czasami zdarzają mi się problemy, których nie opłaca się naprawiać. Na przykład niedziałający moduł informuje mnie o swoim stanie za pomocą komunikatu błędu, jednak może to nie mieć wpływu na działanie całej aplikacji. W takiej sytuacji nie widzę konieczności na siłę naprawiać błąd dla tylko samego naprawiania. Taka decyzja może jednak „zemścić się” na mnie w przyszłości, ponieważ moduł albo narzędzie może się okazać niezbędne w najbliższym czasie 
Dobro wraca!
Z każdym naprawionym błędem moje doświadczenie i wiedza rosną. Oczywistym jest fakt, że z tymi samymi lub podobnymi problemami technicznymi borykam się zarówno ja jak i moi koledzy. Staram się zatem w miarę możliwości dzielić zgromadzonymi zasobami i pomagać innym. Kiedy problem jest mi znany to udzielam się na kanale poświęconym problemom technicznym. Wspieram też kolegów, którzy są specjalistami od back-endu i zawsze mogę liczyć na ich pomoc w tej materii, ale o Angularze mają niewielkie pojęcie i potrzebują pomocy kogoś z frontu. Dzięki temu sama wiele się uczę i szlifuję swoje umiejętności komunikacyjne.