Dlaczego czasem nie myślenie o błędzie pomaga ci go rozwiązać? [Zamknięte]

Wczoraj spędziłem dużą część popołudnia, próbując naprawić błąd, co uważałem za trywialne. Krążyłem w kółko, nie mając pojęcia, co było nie tak. Przepisywanie dużych części kodu. Sprawdzanie SO. Wciąż nie ma radości.

Więc poszedłem do domu, wyprowadziłem psa, oglądałem mały telewizor i tuż przed snem bingo uświadomiłem sobie oczywisty błąd, który popełniłem. Dziś rano zajęło to około 10 minut.

Gdy byłem w domu, nie myślałem aktywnie o tym problemie. Jednak wyrwanie się z sytuacji pozwoliło mi ją rozwiązać.

To nie jest pierwszy raz i wiem, że jest to dość powszechny sposób rozwiązania problemu programistycznego. Słyszałem nawet, że ludzie marzą o odpowiedziach.

Dlaczego to działa?

Być może, co ważniejsze, czy istnieje dobry przewodnik, kiedy należy zrobić przerwę od problemu, jak długo powinna być przerwa i po jakim czasie pozostawienie problemu przestaje być skuteczne?

Podejrzewam, że próbuję opracować sposób optymalizacji tego podświadomego przetwarzania (lub cokolwiek się dzieje)

Zbyt skoncentrowanie się na problemie uniemożliwia cofnięcie się o krok. Podczas debugowania kodu niepotrzebnie powtarzasz te same testy.

Im więcej próbujesz, tym bardziej nie udaje ci się i jesteś bardzo sfrustrowany. Zwiększony stres i frustracja pogarszają sytuację.

Dlatego dość często kolega może przypadkiem spojrzeć przez ramię i wskazać problem (i rozwiązanie) w ciągu kilku sekund.

Nie są w tym samym stanie psychicznym co ty.

Często próbuję przestać dbać o pewien okres czasu i wracać ze spokojniejszym umysłem kilka godzin później.

Ale najpotężniejszą techniką jest po prostu ... proszenie o pomoc .

Jeśli pracujesz nad jakimś problemem od jakiegoś czasu, twój umysł podąża za wzorcami, które ustawiłeś podczas programowania. Innymi słowy, rozwijasz tymczasowe „czarne plamy” dla rzeczy poza mentalną konfiguracją.

Oderwanie się od problemu na chwilę pomaga usunąć ten filtr i pozwala rozmyślać bez filtra.

To, co często pomogło mi w takich przypadkach, to wyjaśnienie komuś innemu, dlaczego to powinno zadziałać (kiedy nie działa) - zwykle w połowie wyjaśnienia zdasz sobie sprawę, gdzie popełniłeś błąd w swoim rozumowaniu lub który krok pominąłeś.

Poza opracowaniem filtra mentalnego podczas prac rozwojowych, mózg jest masowo wielowątkowy i często przechodzi problem w ramach nieświadomych procesów. Czasami używam tego, ucząc się wszystkiego, co mogę na temat problemu po południu, a następnie pozwalając, aby problem leżał przez dzień lub 2, zanim zacznę pracować nad rozwiązaniem.

Nie jestem psychologiem, ale kiedy jesteś zbyt skoncentrowany na jednym problemie (znajdowaniu błędu), masz tendencję do utraty widoku dla większego systemu. Ale często odpowiedź nie brzmi „tam, gdzie jej teraz szukasz”, ale w innym miejscu - którego w tym momencie nie możesz zobaczyć.

Więc tak naprawdę musisz wyjść z rowów i zacząć patrzeć na cały system z bardziej ogólnego punktu widzenia - ponownie. Zazwyczaj ignoruje się ten fakt, myśląc: „Naprawdę wiem, że to tutaj, po prostu go jeszcze nie znalazłem”. Cały czas zdarza się nam wszystkim. Doszedłem nawet do momentu, w którym wiem, że „nie mogę znaleźć błędu za pomocą dobrej techniki debugowania, więc musi być gdzie indziej” i nadal nie robię tego, co należy, i robię sobie przerwę - ludzki mózg jest taki zabawna rzecz.

Jednak tak naprawdę nie ma to większego znaczenia dla tego, co robisz - czy to chodzi do łazienki, rozmawiasz ze współpracownikiem, czy wyprowadzasz psa. Kiedy utknąłem, chodziłem do pobliskiego sklepu, żeby kupić cukierki, i jak tylko włożyłem kurtkę na roztwór, wpadało mi do głowy - prawie za każdym razem. Warto również pić dużo wody podczas programowania. Zmusza cię to do zrobienia sobie przerwy co jakiś czas, by odwiedzić łazienkę i zapaść, jest powód, który zmusza cię do wyrwania się z rowów.

Z mojego osobistego doświadczenia i tego, czego byłem świadkiem w szkoleniu młodszych programistów, wszyscy podchodzimy do problemu z założeniami i oczekiwaniami. Zakładamy, że funkcja x wykonuje zadanie y w celu uzyskania wyniku z. Zawsze tak jest, więc dlaczego miałoby się to zmieniać? Ponieważ coraz bardziej koncentrujemy się na problemie, zakładamy, że omówiliśmy podstawy i problem musi być o wiele bardziej skomplikowany niż wtedy, gdy pierwotnie go rozwiązaliśmy. Dołącz zmęczenie do rosnącej listy rzeczy, które zakładamy, że są prawdziwe, ale w rzeczywistości nie zostały zweryfikowane, a chwilę później przygotujesz się na pełne „WTF”.

Dopiero później, gdy odłączysz się od problemu, założenia można wyrzucić i prześledzić. Ponadto zwykle rozwiązujemy problem związany z innym problemem, który właśnie rozwiązaliśmy. Naprawiłem A, ale pękło B, teraz muszę naprawić B. Więc mamy już pęd i kierunek, w którym podróżujemy (co sprawia, że ​​nasze założenia są jeszcze trudniejsze do rozłączenia). Kiedy wrócisz do rozwiązania problemu B, problem A nie jest już w twoim umyśle blokujący potencjalne możliwości. Jesteś w stanie rozwiązać problem bez uprzedzeń, a to otwiera nowe ścieżki myślenia i nowe perspektywy patrzenia na problem.

Teraz, gdy junior prosi mnie o pomoc, wiedzą, że pierwsze pytanie, na które muszą odpowiedzieć, brzmi: „Jakie są twoje założenia?”. Nawet próba rozwiązania tego problemu może pomóc usunąć cię z twoich mentalnych bloków.

Chyba twój mózg, podobnie jak mięśnie, męczy się. Zrobienie przerwy pozwala jej odpocząć, uzupełnić tlenem / paliwem itp. I zacząć od nowa.

Chodzenie na spacer lub ćwiczenia to często dobre podejście, gdy naprawdę się czegoś utkniesz. Nawet jeśli nie masz momentu „eureka”, często pozwala ci wrócić i zastosować nowe podejście do rozwiązania problemu.

Lubię nazywać to czasem inkubacji pomysłów i problemów.

Twoje podświadomość nadal przetwarza problem z twojej świadomości w podejściu nieliniowym. Jest to bardzo podobne do tego, co dzieje się, gdy uczysz się czegoś nowego przed drzemką. Twój umysł ma czas na „defragmentację” informacji na sposoby, do których można podejść z większą elastycznością.

Kolejna pomocna wskazówka, jak przezwyciężyć utknięcie w błędzie, nazywa się konfesjonałem . To tutaj podchodzisz do innej osoby, która nie zna problemu i zaczynasz wyjaśniać problem. Często stwierdzam, że mówiąc głośno o problemie, przychodzi mi na myśl rozwiązanie.

sprawdź te linki psychiczne: wskazówki dotyczące kreatywności i drzemki

„Wszyscy czasami kłują nas róże . Niestety, kiedy tak bardzo koncentrujemy się na bólu , zapominamy o pięknie róży”.

Naprawiłem kilka krytycznych błędów w mojej karierze podczas prysznica.

Nie jestem psychologiem, ale myślę, że różnica polega na:

• siedząc przed komputerem widzę kody źródłowe, punkty przerwania, printfwyjścia ...

• w łazience kody działają w mojej głowie.

Doświadczyłem tego samego zjawiska i przypisałem je spojrzeniu na problem z innej perspektywy, ponieważ spędzam z niego więcej czasu (więcej czasu oznacza w przybliżeniu dalszą perspektywę).

Ale jest też inna sztuczka, która przez większość czasu pozwala osiągnąć to samo: wyjaśnić kod współpracownikowi. To nie oni łapią twój błąd, chociaż mogą; zmusza cię do wycofania się i wyjaśnienia logiki kodu na wszystkich odpowiednich poziomach. Nigdy (choć uczciwe ostrzeżenie - wielkość próby jest ograniczona) nie udało mi się podświadomie rozwiązać błędu, który uniknął tego traktowania opisywanego współpracownikowi.

Ostatnio korzystam z techniki pomodoro dzięki sugestii kogoś na tej stronie i myślę, że zapewnia ona dobrą odpowiedź na twoje pytanie dotyczące czasu i długości przerw. Zasadniczo, przez 25 minut pracujesz nad problemem, po czym następuje krótka przerwa 3-5 minut, a następnie dłuższa przerwa po każdych 4 cyklach. Przytaczają niektóre badania, aby to poprzeć, ale anegdotycznie stwierdziłem, że te interwały są bardzo skuteczne.

Myślałem, że 25-minutowe okresy powstrzymają mnie przed „wejściem w strefę”, co, jak twierdzą ludzie, zajmuje około 15 minut. Wręcz przeciwnie, z tym wyczuciem prawie natychmiast wchodzę do strefy. Myślę, że dzieje się tak, ponieważ o wiele łatwiej jest uniknąć rozproszenia, gdy wiem, że muszę to robić tylko przez 25 minut. Łatwiej jest także odłożyć zewnętrzne zakłócenia na zaledwie 25 minut. Było to o wiele trudniejsze, kiedy próbowałem zapiąć pasy na 4 godziny pracy przed lunchem.