To nie jest tekst motywacyjny. I nie jest to tekst psychologiczny czy jakkolwiek go nazwać. Jest to tekst techniczny. Przeznaczony dla każdego dev – tego seniora (staruszka co ledwo co chodzi, albo może ma on 20 lat? Kto wie…) tego juniora co dopiero zaczął pierwszą pracę (albo może się przekwalifikował), w ogóle co to znaczy junior i senior teraz? Ale nie o tym.
Jeżeli pracujemy nad jakimś problemem i za nic nie możemy go rozwiązać czy też go obejść to zaczynamy łuc naszą głową o ścianę. Próbujemy na przykład rozwiązać problem wywołania jednej metody w bibliotece zewnętrznej/API które trwa 10s i blokuje wszystko. Z biblioteki/api trzeba skorzystać i z metody też trzeba skorzystać. W sensie nie ma innej drogi. Ta metoda musi być wykonana i tyle. I można chodzić i się wkurzać na twórców co za bagno oni stworzyli, można też oprócz tego (tak mówię oprócz bo sam bym tak łatwo nie przestał się na twórców wkurzać, bo zjedli mi właśnie mój wolny czas lub coś) kombinować. Walnięcie głową w ścianę, pomysł. Walnięcie, pomysł. I tak w kółko.
Tylko, że z walenia i zbierania pomysłów nic nie ma. To co trzeba zrobić, to walnąć głową, spisać pomysł który się pojawił. Usiąść i:
git branch -b wall-headbang-01
I zaimplementować pomysł niezależnie jak głupi byłby albo jak dużo zmian wymaga w kodzie. Tutaj kluczem jest słowo: ZAIMPLEMENTOWAĆ. Bo wymyślenie i stwierdzenie, że to się nie sprawdzi jest tak samo bezmyślne jak walenie w głową w ścianę… wait, nie ważne. Tak, taki pomysł trzeba napisać, rozpisać i odpalić. A jak się wszystko położy, to znów:
git branch -b wall-headbang-02
I jedziemy dalej.
W którymś momencie albo dojdziemy do wniosku, że z naszej twarzy i głowy nic nie zostało a problem dalej istnieje, albo w magiczny sposób naprawimy to co nie działało, lub wymyślimy rozwiązanie działające tak jak nic dotąd.
Czasami zaś takie wall-headbangi pozwalają nam na uporządkowanie sobie głowy, na wyrzuceniu idiotycznych pomysłów i zrobienie miejsca dla tych super fajnych jedynych niepowtarzalnych. Albo na przykład rozwiązanie wall-headbang-13 okaże się, prawie dobre, wymaga to jednak małej zmiany albo w wymaganiach, albo w części już “zamrożonej” (jeżeli takie części są, ale słyszałem nie raz: zostaw, już przetestowane, nie mamy czasu na nowe testowanie). Mała rozmowa z klientem, mała poprawka i nagle problemu nie było. Czapki w z głów i w ogóle.
Albo czasami rozwiązaniem jest po prostu jedną z najgłupszych (a zaraz najinteligentniejszych) rzeczy jakie możemy zrobić:
setTimeout(do_that_shit, 100);
Działa, działa w JavaScript, działa w .NET, działa na Office, działa na SharePoint. Działa wszędzie. A jak się śmiejecie, tutaj dokumentacja jednego z produktów:
Wait a little
Some things are not possible to do right at the moment; say, you cannot close the inspector of an Outlook item in the Send event of that item. A widespread approach is to use a timer. Add-in Express provides a way to do this by using the <SendMessage> method and <OnSendMessage> event; when you call <SendMessage>, it posts the Windows message that you specified in the methods’ parameters and the execution continues. When Windows delivers this message to an internal Add-in Express window, the <OnSendMessage> event is raised. Make sure that you filter incoming messages; there will be quite a lot of them. The <OnSendMessage> event always occurs on the main thread.
Chłopaki nawet ułatwili i zrobili własny “setTimeout” bo inaczej się nie dało.
Kwestia tylko tego, jak bardzo chcesz rozwiązać problem. Bo jak nie chcesz, to olej sprawę i powiedz nie dało się. Jednak, w IT jest tak, że przeważnie się da, pytanie jakim kosztem i czy warto.
Ale to już pozostawiam wam do decyzji. Ja za to idę opijać shakiem owocowym to co mi się udało osiągnąć przy wall-headbang-15 :) poobijany, ale dumny i zadowolony.
PS.: nieprawda, po wall-headbang-15 dostałem zapytanie z innego projektu i tam już z miejsca Entity Framework przywitał mnie pacnięciem w głowę młotem Thora. Ale o tym to już, kiedy indziej
To jedno z podejść. Wg książki, którą właśnie czytam – “Głowa do liczb” – zamiast takiego ciągłego fiksowania się na problemie, które jednocześnie coraz bardziej zawęża widzenie, należy od problemu odejść, zająć się czymś innym i wrócić za jakiś czas.
Comments are closed.