Jak radzić sobie z porażeniem analizy?

Bardzo często utknąłem przy wyborze najlepszej decyzji projektowej. Nawet w przypadku drobnych szczegółów, takich jak definicje funkcji, przepływ sterowania i nazwy zmiennych, spędzam niezwykle długie okresy, analizując korzyści i kompromisy z moich wyborów.

Czuję, że tracę dużo wydajności, spędzając godziny na takich nieistotnych szczegółach. Mimo że w głębi duszy wiem, że mogę zmienić te rzeczy, jeśli mój obecny projekt się nie powiedzie, mam problem z podjęciem zdecydowanego wyboru.

Co powinienem zrobić, aby zwalczyć ten problem?

Dwie proste zasady:

1. Zrób najprostszą rzecz, która może działać.
2. Refaktoryzuj w sposób ciągły.

Gdy zaczniesz robić każdą z tych rzeczy, zyskasz pewność, że możesz teraz podejmować proste decyzje bez uszczerbku dla twojej zdolności reagowania na zmiany później.

Pamiętaj, że korekta w przyszłości oznacza łatwość zmiany kodu, a nie próbowanie przewidywania wszystkich możliwych sposobów zmiany kodu.

Zwykle, gdy czuję się w ten sposób, oznacza to, że muszę spróbować:

1. Wstań, chodź i upewnij się, że cała biologia działa poprawnie.
2. Podejdź do tablicy i rysuj, aż poczuję się pewnie.
3. Znajdź „kumpla reklamującego projekt”, z którym możesz porozmawiać o problemie.

Jeśli problem dotyczy składni i małych elementów, wówczas:

1. Przekonaj się, że nawet jeśli jest brzydka, jest gdzieś ładnie zamknięta i reprezentuje czysto lokalny rodzaj cruft.
2. Dodaj znaczniki DO ZROBIENIA lub po prostu komentarze wyjaśniające, dlaczego kod Cię popełnił.
3. Przejdź do następnego zadania.

Bardzo łatwo jest myśleć o bezczynności. Nawet jeśli uda jakoś wymyślić najlepsze rozwiązanie w tej chwili , że może łatwo zmienić przed zakończeniem projektu, a co potem?

Lepiej wybrać przyzwoite rozwiązanie i biegać z nim, niż usiąść i zastanowić się, jakie byłoby najlepsze rozwiązanie. Najlepsze rozwiązanie jest nieuchwytne, a co gorsza - subiektywne. Jeśli wymagania zmienią się nawet nieznacznie, Twoje rozwiązanie może okazać się gorsze niż rozwiązanie, które odrzuciłeś, ponieważ nie było wtedy najlepsze.

Uczę się również unikać paraliżu analizy, więc cześć dla nas =) To często się zdarza, ponieważ chcemy zrobić „najlepszy projekt”. W rzeczywistości „najlepszy” jest w oku patrzącego . Moją formułą, aby uniknąć paraliżu analizy, jest zastosowanie wystarczająco dobrej zasady projektowania . Jak ja to robię? Wprowadzam zmienne takie jak ograniczenia czasowe, harmonogram i zadaję sobie pytanie, jaki jest najprostszy projekt, który może wykonać zadanie (nie oznacza to najłatwiejszego) bez pogorszenia jakości, ale jednocześnie upewniam się, że jest to testowalne i otwarta na przedłużeniu zamknięte modyfikacji (OCP)również projekt. Co mam na myśli przez testable i OCP? Cóż, zamiast szukać tego, co uważałem za najlepsze, zastanowiłem się nad projektem, który może mi powiedzieć, kiedy coś idzie nie tak, i spróbować zrobić tyle kodu, który pozwoli mi zreformować i poprawić później. Ponadto, staramy się oddzielić kod, który będzie się zmieniać wraz z kodem, który pozostaje taki sam. Refaktoryzacja staje się łatwiejsza, ponieważ kod, który nie powinien się zmieniać, jest bezpieczniejszy od twojej przyszłej ciebie lub kogoś innego.

Co powiesz na to, by pozwolić sobie na przeczucie wyboru jednej z opcji? Powinno to iść dość szybko i dobrze łączyć się z timeboxingiem , który również zaproponował ammoQ . Możesz spróbować limitu 1 minuty, jeśli opcje są już ustalone, lub 2 minut, jeśli musisz je najpierw zdefiniować. Lub cokolwiek wydaje się właściwe (zdefiniowane wcześniej). Kiedy nauczysz się słuchać instynktu jelitowego, intuicyjny wybór stanie się szybszy i lepszy z praktyką .

Jeśli martwią Cię możliwości wybrania nie idealnie, oto kilka pomysłów na rozwiązanie tego problemu:

• Gdyby istniała opcja z wyraźną przewagą nad innymi, nie zadałabyś sobie wyboru. Dzięki takiemu rozumowaniu, ilekroć nie jesteś zdecydowany, co do wyboru w niezbyt skomplikowanej sprawie, oznacza to, że wszystkie opcje są całkiem równe; więc nie ma wiele do stracenia , wybierając jedno z nich.
• To powiedziawszy, intuicja wcale nie jest przypadkowa, ale całkiem niezła, wykształcona domysł dla optymalnego rozwiązania. Często lepsze niż to, co można wymyślić poprzez niekończące się szperanie.
• Uwzględniając perfekcjonizm, można oceniać szybkość decyzji wyższą niż optymalność wyboru, gdy półświadomie ocenia się wydajność. Co jest całkowicie sensowne w przypadku nieistotnych wyborów, ale nie jest łatwe do zapamiętania.

Powodzenia! :)

Myślę, że to odchodzi z małym doświadczeniem. Większość mojego paraliżu dzieje się, ponieważ próbuję sobie wyobrazić, jak baza kodu będzie wyglądać znacznie dalej, niż jest to konieczne, więc aby ją przezwyciężyć, po prostu robię najprostszą możliwą rzecz, która zadziała, a następnie przejdę dalej. Gdy projekt ma określony kształt, powtarzające się jednostki kodu zaczynają się wyróżniać i łatwo jest wyodrębnić powtarzające się wzorce i uprościć kod.

Aby przezwyciężyć niechęć do decydowania, zastosuj timeboxing : ustaw budzik na kilka minut; dręczyć swój umysł do tego czasu, ale kiedy włączy się alarm, wybierz najlepszą z dotychczas dostępnych opcji.

Utwórz prototyp. Pamiętaj, że prototyp został wyrzucony, więc nie ma znaczenia, jakich funkcji, nazwy zmiennej, a nawet wielkiej architektury używasz. Po prostu budujesz go, aby udowodnić, że działa.

Gdy go utworzysz i wyrzucisz, chętnie się założę, że podejmowanie takich decyzji będzie łatwiejsze.

Też cierpię z tego powodu. Powiedziałbym, że nie masz wystarczającej motywacji do ukończenia.

Na przykład, kiedy pisałem kod renderujący, miałem dużą zachętę do ukończenia, ponieważ wiedziałem, że gdybym sobie z tym poradził, zobaczyłbym system w akcji i pomyślałbym, jak wspaniale było pisać tekst na quadzie, lub przekształcenie vert. Ale teraz, kiedy zmieniam faktoring (próba 4, jeśli chcesz wiedzieć), cierpię, ponieważ to dużo pracy, a nawet jeśli skończę, zobaczę ten sam stary quad. I naprawdę nie chcę ponownie refaktoryzować i mam dość ciągłego oglądania tego samego starego quada i nie jest to dla mnie żadna nagroda.

Musisz rozbić go na komponenty i nagrodzić się za ich ukończenie, nawet jeśli jest to tylko niektóre we / wy konsoli, które pokazują, że działa.

Czytałem twoje pytanie i zastanawiałem się nad innymi plakatami: nie nadajesz się do tej pracy; wyznaczyć sobie termin; zrób coś jeszcze przez chwilę. Po krótkiej refleksji nie jestem pewien, czy którakolwiek z odpowiedzi jest tak pomocna

Problem z takimi problemami psychicznymi polega na tym, że nie są one łatwe do rozwiązania, są częścią ciebie i oczywiście zależy ci (zbyt wiele) na swojej pracy, nie masz pewności, by się ze sobą zgodzić, są też zbyt Niedoświadczony, że przez cały czas miałeś rację, lub zbyt mocno stresujesz się nad tym, aby idealnie go wybrać. Dlaczego miałbyś się martwić takimi błahostkami ?!

Teraz mam podobne problemy, ale nie tyle z kodem ... zwykle jest to, co na obiad .. pizza lub curry .. hmm ... pizza, ale curry jest fajne, ale czy czuję się jak curry, pizza jest tańsza , ale wtedy dostajesz więcej curry, ale ... i tak dalej. :)

Pomyślałem więc - dlaczego nie mam podobnych problemów z kodowaniem i myślę, że po prostu dlatego, że mam zestaw wzorców, z których regularnie korzystam. Jeśli potrzebuję definicji funkcji, to jest łatwe ... będzie w tym samym stylu, co każda inna definicja funkcji, jaką kiedykolwiek kodowałem. Jeśli potrzebuję przepływu kontrolnego, najpierw decyduję, czy potrzebuję pętli for, czy chwilowej, a następnie tworzę ten sam stary kod, którego użyłem ostatnim razem, gdy potrzebowałem jednej z tych rzeczy. To samo dotyczy wszystkiego, czy chcę kolejkę? Jasne - chodźmy wyciąć i wkleić mój „standardowy” kod kolejki (pobrany z ostatniego projektu, nad którym pracowałem, lub dowolnego, który pamiętam, używając jednej z tych rzeczy). Efekt końcowy ... Martwię się tylko o nowe rzeczy i szczerze mówiąc, to przyjemność.

Tak więc, radzę zacząć budować bibliotekę fragmentów kodu - zwykłem przesyłać je e-mailem do siebie i umieszczać w folderze, ale wszystko, z czym pracujesz, jest najlepsze - a wtedy zaczniesz wiedzieć, co robić za każdym razem. Zawsze przejdziesz do starego kodu, który napisałeś, i usuniesz problem z pracy, gotowy na następny problem. Przekonasz się, że zostałeś znacznie szybszym programistą (poważnie, to jedyny sposób na zwiększenie produktywności programisty) i mam nadzieję, że znajdziesz czas na zabawne elementy, a nie na ponure codzienne rzeczy, które już rozwiązałeś wiele razy koniec.

Oczywiście ostatnia część wszystkiego jest również ważna - im więcej pracy masz, tym mniej luksusu musisz poświęcić na myślenie.

Oto strategia łącząca sugestie Reina Henrichsa ( rozpoczęcie proste, refaktoryzacja ) i amunicji ( timeboxing ):

1. Daj sobie dość ścisły limit czasu na pierwsze rozwiązanie, które po prostu działa. Np. 30 sekund na nazwę zmiennej. Możesz najpierw wymyślić coś takiego x, a następnie dopracować string, a potem, nameaż czas się skończy.
2. Następnie przejdź do innych zadań przez określony czas, np. 10 minut.
3. Dopiero wtedy pozwól sobie na kolejne pole czasowe dla dalszej poprawy swojej decyzji, npuserHandle

Możliwe korzyści z tego podejścia:

• wiedza o powrocie do tego później może na razie złagodzić problem
• kontynuując inne zadania, możesz po prostu znaleźć dobre, satysfakcjonujące rozwiązanie bez czasochłonnego szperania
• po puszczeniu kroku 1 i przejściu do kroku 2 , może być łatwo utrzymać krok 3 naprawdę szybko, ponieważ chcesz kontynuować krok 2, a zatem z radością wybierz jedno przyzwoite rozwiązanie i zaakceptuj je

Kiedy przeprowadziłem badania i nie mam jednoznacznego najlepszego wyboru, daję sobie limit czasu (zwykle 5 minut) na wybranie jednego, a następnie po prostu idę naprzód. Nawet jeśli napotkasz przeszkody, w tym momencie nie ma gwarancji, że nie trafiłbyś na taką samą przeszkodę, podejmując inną decyzję. Nie mogę wymyślić momentu, w którym żałuję swojej decyzji.

Zwykle powodem, dla którego nie możesz podjąć decyzji, jest to, że różnica jest nieznaczna lub nie masz wystarczającej ilości informacji.

W przypadku, gdy: a) Ustaw termin na przedstawienie rozsądnych opcji do rozważenia. Nie decyduj jeszcze, który z nich. Na koniec wybierz jedną (losowo, jeśli nie ma wyraźnej preferencji) ze wskazanych opcji i inny limit czasu. Jeśli pod koniec czasu nie zostanie podjęta jasna decyzja, jest to już ta wybrana. Rozpocznij kodowanie i dokonaj refaktoryzacji, jeśli wyraźnie popełniłeś błąd. Jeśli szef zapyta dlaczego, powiedz „Rzuciłem monetą, masz lepszy sposób?”

W przypadku b) - potrzebujesz więcej informacji, a siedzenie na dużym tłuszczu A .... przez cały dzień ich nie dostarczy. Wyjdź z trybu projektowania i przejdź do trybu zbierania informacji. Prototypy, zadawaj pytania, czytaj czasopisma techniczne. Cokolwiek robisz, nie śpij zbyt długo.

Często najlepszym rozwiązaniem jest wyjaśnienie swojej decyzji koledze. Ponieważ jednak nie chcesz tego robić zbyt często, następną najlepszą rzeczą jest myślenie na papierze - albo za pomocą papieru / długopisu, albo pustego okna notatnika.

Zacznij od napisania absolutnie wszystkiego - tylko po to, aby wejść w rytm pisania. W oknie notatnika możesz po prostu wpisać „myślę na papierze”, a następnie kontynuować strumień świadomości. Po kilku sekundach będziesz w rytmie pisania, więc naciśnij kilka razy enter i zacznij wyjaśniać swój dylemat.

Określ problem, a następnie podaj możliwe rozwiązania, co jest dobre w każdym z nich itp.

Chociaż nie zawsze działa, proces wydobywania myśli z głowy (RAM) i na media zewnętrzne (dokument notatnika) daje większą swobodę nawiązywania nowych połączeń i patrzenia na decyzję z różnych perspektyw.

Cierpię na ten sam problem. W przypadku drobnych problemów próbuję sobie z tym poradzić, jeśli chodzi o pierwszy projekt, który według mnie nie jest głupi. Nie ma sensu szukać optymalnego projektu; trudno jest, jeśli nie niemożliwe, uzasadnić wszystkie niuanse każdego projektu, o którym możesz pomyśleć bez napisania tego. W miarę pisania kodu zauważysz, że możesz wprowadzić niewielkie ulepszenia. Zrobione dobrze, uważam, że dość łatwo jest w ten sposób uzyskać dość dobre rozwiązanie.

W przypadku większych problemów wydaje mi się, że warto najpierw przemyśleć opcje, ale z czasem to zrobić. Duże problemy mają duże przestrzenie rozwiązań, nie możesz ocenić każdej możliwości, nie powinieneś też próbować.

TLDR; Wybierz rozsądne rozwiązanie, ulepszaj je na bieżąco.

Dotyczy to również:

Nauczyciel ceramiki ogłosił w dniu otwarcia, że ​​dzieli klasę na dwie grupy. Powiedział, że wszyscy po lewej stronie studia będą oceniani wyłącznie na podstawie ilości wykonanej pracy, wszyscy po prawej tylko na podstawie jakości. Jego procedura była prosta: w ostatnim dniu zajęć przynosił wagi łazienkowe i ważył pracę grupy „ilościowej”: pięćdziesiąt funtów garnków oznaczonych „A”, czterdzieści funtów „B” i tak dalej. Ci, którzy zostali oceniani na „jakość”, musieli jednak wyprodukować tylko jedną doniczkę - choć idealną - aby uzyskać „A”.

Cóż, nadszedł czas oceniania i pojawił się ciekawy fakt: wszystkie prace najwyższej jakości zostały wyprodukowane przez grupę ocenianą pod względem ilości. Wygląda na to, że podczas gdy grupa „ilościowa” zajęła się produkcją stosów pracy - i uczyła się na własnych błędach - grupa „jakościowa” siedziała w teorii o doskonałości, a na koniec miała niewiele więcej do pokazania za swoje wysiłki niż wielkie teorie i kupa martwej gliny.

z http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Nigdy tego nie zrozumiałem. Kiedy byłem instruktorem, powiedziałbym coś takiego:

"OK, create an integer variable and assign the return value of strlen() to it."

Może nie jest to zbyt skomplikowane, a 95% ludzi napisało coś takiego:

int x;   // or y, or len, or whatever
x = strlen( s );

Ale od czasu do czasu pojawiał się ktoś sparaliżowany w świetle reflektorów jak królik. Spytałbym współczująco, na czym polega problem, a oni powiedzieliby: „Nie wiem, jak to nazwać!”.

To są ludzie, którzy powinni szukać innej kariery. Jak może powinieneś.