Lubię rzeczy, które można rozłożyć na części, obejrzeć z bliska i spróbować naprawić. Czasem jest to podłoga w VW Transporterze, czasem rzadki brązowy element z serii LEGO Jungle, a czasem fragment wtyczki do WordPressa albo lokalny model językowy, który zachowuje się inaczej, niż się spodziewałem.
Na pierwszy rzut oka te światy nie mają ze sobą wiele wspólnego. Mnie łączy w nich ten sam odruch: nie zaczynam od siły ani od szybkiej poprawki. Najpierw próbuję zrozumieć objaw.
Najpierw diagnoza, potem narzędzia
Przy renowacji podłogi w samochodzie łatwo skupić się na tym, co widać. Ale nowa warstwa na wierzchu nie pomoże, jeśli nie wiemy, co dzieje się pod nią. Przy naprawie aplikacji podobnie: komunikat o błędzie jest wskazówką, nie diagnozą. Zanim zmienię kod, próbuję ustalić, kiedy problem się pojawia, co go poprzedza i kogo dotyczy.
Pomagają mi pytania, które są proste i trochę nudne — właśnie dlatego skuteczne:
- Co dokładnie miało się wydarzyć?
- Jaki jest najmniejszy przypadek, w którym błąd da się powtórzyć?
- Co zmieniło się od chwili, gdy wszystko działało?
- Jak sprawdzę, że naprawa nie popsuła czegoś obok?
Kruche elementy przypominają, żeby nie używać siły
Niektóre starsze, brązowe elementy LEGO są w moim doświadczeniu na tyle kruche, że wolę obchodzić się z nimi ostrożniej niż z typowym klockiem. To drobiazg, ale dobra lekcja: kiedy materiał jest delikatny albo nie znamy jego historii, większy nacisk nie daje większej kontroli. Najpierw oglądam połączenie, szukam miejsca, które można bezpiecznie zwolnić, i dopiero potem próbuję rozdzielić elementy.
W kodzie odpowiednikiem „użycia siły” jest duża poprawka wprowadzona bez testu. Czasem trzeba przebudować większy fragment, ale najpierw chcę wiedzieć, dlaczego mała zmiana nie wystarczy. Mały, odwracalny krok pozwala szybciej nauczyć się czegoś o problemie — i łatwiej wrócić, jeśli hipoteza była błędna.
Mały eksperyment daje więcej niż zgadywanie
Gdy testuję lokalny model LLM albo nową funkcję wtyczki do WordPressa, staram się oddzielić jedną zmianę od reszty. Zapisuję, czego się spodziewam, uruchamiam krótki test i sprawdzam wynik. Jeśli zmienię pięć rzeczy jednocześnie, mogę zobaczyć poprawę, ale nie będę wiedział, co ją spowodowało.
Ta sama metoda działa przy pracach ręcznych. Najpierw sprawdzam niewielki fragment, zanim przejdę do całej powierzchni. Dobrze jest mieć plan, ale warto zostawić sobie miejsce na to, że po odsłonięciu kolejnej warstwy sytuacja okaże się inna.
Naprawa to także szacunek do ograniczeń
W samochodzie ograniczeniem może być dostęp do elementu, w aplikacji — stary system, czas zespołu albo sposób, w jaki użytkownicy naprawdę pracują. Nie zawsze opłaca się dążyć do rozwiązania idealnego na papierze. Czasem lepsza jest poprawka, którą można utrzymać, niż efektowna przebudowa, której nikt nie rozumie.
Dlatego przed pracą lubię ustalić, co musi pozostać bez zmian, co można poprawić teraz, a co warto zostawić na później. To chroni przed zakresem, który rośnie szybciej niż korzyść.
Ten sam sposób myślenia przydaje się w pracy z ludźmi
Najważniejsza część inżynierskiego podejścia nie dotyczy narzędzi. Chodzi o cierpliwość, ciekawość i gotowość do sprawdzenia własnego założenia. Jeśli ktoś zgłasza problem z aplikacją, nie zakładam od razu, że „źle klika”. Jeśli uczestnik szkolenia nie rozumie ćwiczenia, nie powtarzam głośniej tej samej instrukcji. Szukam miejsca, w którym proces przestał być jasny.
To właśnie łączy dla mnie pracę przy samochodzie, klockach, WordPressie i AI: patrzę na stan rzeczy, formułuję małą hipotezę, sprawdzam ją i dopiero wtedy wybieram następny krok. Nie zawsze jest najszybciej. Zwykle jest za to mniej przypadkowo.
A Ty? Co ostatnio naprawiałeś lub usprawniałeś — i czego nauczył Cię sam proces?