Jaki jest najbardziej produktywny sposób radzenia sobie z awariami związanymi z programowaniem? [Zamknięte]

Wszyscy tam byliśmy:

• Twój projekt nie powiódł się lub został anulowany.
• Twój zespół odrzucił kod, nad którym spędziłeś dni pracując.
• Wzorzec projektowy, który wprowadziłeś do zespołu, wywołał chaos.
• Wszyscy ignorują twoje pomysły.

Moje pytanie brzmi: jaki jest najbardziej produktywny sposób dla programisty na radzenie sobie z błędami związanymi z programowaniem, takimi jak te?

Twój projekt nie powiódł się.

Tworzenie oprogramowania jest bardzo podatne na awarie projektu, a w zależności od stopnia zaawansowania najlepiej sobie z tym poradzić.

Wiele projektów się nie powiodło, a wiele innych się nie powiedzie, więc rób notatki! Dowiedz się, dlaczego Twój projekt nie powiódł się, aby nie popełnić tych samych błędów następnym razem. Uczysz się znacznie więcej o swoich niepowodzeniach niż o sukcesach.

Zespół, który poświęcił dni na kodowanie, został odrzucony.

Zapisz swoją pracę (na później). Istnieją dwie możliwości: (a) To do bani, a fakt, że wiele osób odpowiedziało w ten sam sposób, wskazuje na to (b) To naprawdę genialna praca, ale znacznie wyprzedzająca to, do czego ludzie są przyzwyczajeni lub mogą to zrozumieć. Ludzie na ogół nie lubią tego, czego nie rozumieją. Być może lepiej jest pokazać to we właściwym czasie LUB w innym miejscu z inną „Kulturą”

W Twojej firmie nikt nie słucha twoich pomysłów.

To prawdopodobnie zły pomysł, LUB kultura nie jest dostosowana do twojego myślenia. Przenieś się do miejsca, które wspiera Twoją kulturę lub ponownie krytycznie oceń swój pomysł (obiektywnie bez własnego uprzedzenia) -> czy mój pomysł jest naprawdę tak dobry? <- Zabij swoje ego

Wzorzec projektowy, który wprowadziłeś siłą w swoim zespole, spowodował bałagan.

Szczerze mówiąc, starałeś się jak najlepiej, ale nie okazało się, jak to zaplanowałeś. Lepiej zacząć od nowa lub uczyć się na błędach popełnionych w projekcie jako zespół i iść naprzód.

Nie są porażkami - są doświadczeniami

Uczysz się i rozwijasz na podstawie swoich doświadczeń, zastanawiając się, jak sprawili, że się czujesz i czy chcesz więcej tego uczucia.

Jeśli jest to złe doświadczenie (jak ta lista, którą zaoferowałeś), to towarzyszące złe uczucie jest prawdopodobnie czymś, czego będziesz chciał uniknąć (zakładając, że nie jesteś tak gruby, że nie przejmowałeś się wpływem swoich działań).

Ogólnie rzecz biorąc, nie angażuj się zbytnio w porównywanie siebie z innymi, mają oni tyle samo problemów z przepracowaniem tego wszystkiego, co ty .

• Zachowaj spokój - nie panikuj, nic nie poprawi
• Kontrola szkód - zapisz to, co jeszcze można uratować
• Ucz się na błędach - ponowne wykonanie niewłaściwej czynności prawdopodobnie nie sprawi, że zadziała
• Pomyśl o nowym początku - rozpocznij kolejną próbę bez plecaka rozczarowań i poczucia winy
• Spójrz na większe awarie - w porównaniu z pierwszym lotem Ariane 5 Twoja awaria jest znikoma
• Skonsultuj się z psychoterapeutą, jeśli nie poradzisz sobie sam

Budujesz coś.

Dla mnie (nie sądzę, że jest to odpowiednie dla wszystkich) budowanie czegoś (komiksy, rysunki, małe gry itp.) Jest jak budowanie odrobiny pewności siebie, aby wrócić do walki z porażką. Może to być również dobry sposób na wyrażenie gniewu, goryczy lub uczuć związanych z porażką, ale w „konstruktywny” sposób.

To i tak mi odpowiada.

Cóż, pytałeś :) Jeden po drugim:

* Your project failed.

To nie jest nic nowego. Wszyscy ponieśliśmy porażkę prywatnie i wszyscy ponieśliśmy porażkę w oczach naszych rówieśników. Każdy, kto ukończył szkołę podstawową i średnią, doświadczył tego.

Jeśli nie mogę popełnić błędów i oczekuję stabilnego zatrudnienia, powinieneś rozważyć wysłanie notatki do HR informującej ich, że ludzie zostaną wykluczeni z przyszłych rozważań.

Kilka awarii z rzędu oznacza, że ​​albo masz nieuzasadnione wymagania i specyfikacje, albo nie uczysz się na własnych błędach. Każdy ze scenariuszy wymaga natychmiastowego działania.

Można sobie wyobrazić, że wiele osób zapisuje się na coś tylko po to, aby zdobyć zatrudnienie, a następnie wypracować sposób spełnienia wymagań.

* What you have spent days coding was rejected by your team.

Zdarza się. Jak zauważyli inni, zapisz to. Zrób to jeszcze raz. Dlatego nazywamy to pracą. Myślę, że w tym przypadku prawdopodobnie nie zaangażowałeś zespołu w to, co robiłeś.

Może się również zdarzyć, że wymagania zmieniły się wczoraj lub godzinę temu. Powinien to być jednak wyjątek, a nie norma. Recenzja jest równie brutalna, jak pomocna. Jeśli Twój kod jest ciągle odrzucany jako „nieodpowiedni” (lub coś w tym rodzaju), powinieneś spędzać więcej czasu wybierając mózgi i angażując innych. Uważam, że to pytanie jest błędem w większości ustawień zespołu, chyba że „zespół” jest czymś innym niż samoopisaniem się.

* Nobody listens to your ideas in your company.

Ponownie wymaga to kontekstu. Jak długo tu jesteś? Jak bardzo inni hakerzy ufają twojej umiejętności? Czy zastanawiałeś się nad tym, że pomysły, które przyniosą więcej pracy wielu osobom, mogą zapraszać KAŻDY powód do ich odrzucenia? Kiedyś miałem coś odrzuconego, ponieważ nie było ono gotowe na IPV6, ale używało prostego gniazda domeny na urządzeniu pętli zwrotnej (wyłącznie). Osoba, która go zatopiła, po prostu nie mogła znieść więcej pracy.

Jak dobrze się wyrażasz? Czy możesz zaprzyjaźnić się i wpływać na ludzi?

* The design pattern you introduced with force in your team created a mess.

Dlatego właśnie należy unikać siły. Umiejętność mówienia nie jest warunkiem koniecznym do słuchania. Brak innych komentarzy.

Och chłopcze, to dużo, jeśli naprawdę miałeś na myśli, że wszystko ci się przytrafiło!

OSTRZEŻENIE : W wielu punktach poniżej możesz czuć się tak, jakbym cię krytykował i że chciałbym uczynić cię odpowiedzialnym za nieszczęścia i nie brać pod uwagę czynników zewnętrznych. Ja nie. Po prostu nie podajesz zbyt wielu szczegółów, a ja po prostu dostarczam listy kontrolne działań, które należy podjąć, aby upewnić się, że wszystko pójdzie nie tak. Wiem, że sam popełniłem wiele błędów (wszyscy to robią) i stajemy się lepsi tylko wtedy, gdy się z nich uczymy. Aby się od nich uczyć, musimy przede wszystkim zacząć postrzegać je jako błędy i przyjąć odpowiedzialność za to, co poszło źle z naszej strony. Do diabła, przyjmij odpowiedzialność za to, co poszło nie tak w cudzych częściach, możesz się z tego również nauczyć.

Twój projekt nie powiódł się

Teraz niewiele można zrobić, aby to złagodzić.

Możesz jednak wiele zrobić, aby tego uniknąć w przyszłości. Proponuję spróbować poprawić swoje umiejętności zarządzania projektem i czasem.

Jedna z książek o najlepszym stosunku ((ważna rada) / strony), które przeczytałem na ten temat, choć może nie najlepsza, to radykalne zarządzanie projektami Roba Thomsetta .

Naprawdę nie określasz, co nie powiódł się twój projekt, ale zakładam kombinację rzeczy, które spowodowały nierównowagę w zwykłym trójkącie koszt / czas / qualiy . Najważniejszym czynnikiem w moich oczach jest kierowanie projektem i rozwojem, przy jednoczesnym stałym kontakcie zarówno z waszymi aktorami technicznymi (deweloperami i testerami), jak i zainteresowanymi stronami. Zbyt wiele projektów kończy się niepowodzeniem, ponieważ nie słuchają sponsorów ani interesariuszy i nie zmuszają ich do zaangażowania się w proces.

Jeśli nie są zaangażowani, nie możesz wiedzieć, czego chcą. Jeśli nie możesz wiedzieć, czego chcą, nie możesz tego dostarczyć. Jeśli go nie dostarczysz, będą niezadowoleni. To jest porażka. Ponadto, jeśli nie angażujesz swoich interesariuszy, są oni odłączeni od rzeczywistości inżynierii oprogramowania, co oznacza, że ​​nie rozumieją twoich problemów. Jeśli często się z tobą kontaktują, lepiej rozumieją, z czym masz do czynienia. Będą mogli lepiej zrozumieć, gdy powiesz im, że „mała” funkcja [śmiech] potrwa miesiące. Mogą lepiej ufać Twojemu planowaniu, ponieważ pomogli go zbudować. Projekt nie może odnieść sukcesu z „specyfikacjami na początku, opracowaniem, testowaniem, dostarczeniem na końcu”. Po prostu nigdy tego nie robi. Możesz dostarczyć to, o co proszono w specyfikacjach,

Co najważniejsze, zrób retrospektywę i upewnij się, że jest to gra pozbawiona ego, a nie wina. Wystarczy zidentyfikować problemy.

Zespół, który spędziłeś dni na kodowaniu, został odrzucony

Byłem w takiej sytuacji. Ponownie niewiele można zrobić, aby to złagodzić, z wyjątkiem:

• Zachowaj go w SCM na później.
• Może spróbuj stopniowo wypychać małe fragmenty do głównej bazy kodu zamiast ogromnego refaktoryzacji.

Są jednak rzeczy, które możesz zrobić, aby zapobiec takiej sytuacji:

• Dlaczego to się stało? Jaki jest powód odrzucenia?
• Przez większość czasu, kiedy widzę, że tak się dzieje (i tak też było w moim przypadku), oznacza to, że deweloper poszedł solo lub w trybie kodowania krów i produkował rzeczy, o które nigdy nie proszono. Kod, który nie pochodzi z wymagań biznesowych, może być wymyślny i „lepszy”, ale często jest stratą czasu i pieniędzy. Co więcej, będzie go kosztować jeszcze więcej, jeśli go zintegrujesz, ponieważ będzie musiał ponownie przetestować. Myśl jak ludzie, którzy rozdają ci pieniądze: musisz także być wydajny na tym poziomie.
• Czy jakość produkowanego oprogramowania była satysfakcjonująca? Czy był zgodny ze standardami i konwencjami dotyczącymi działalności w Twojej firmie?
• Czy okresowo (i często!) Informowałeś o tym bezpośrednich menedżerów? Czy od czasu do czasu wymieniasz się z innymi programistami zespołu? Jeśli nie, nic o tym nie wiedzą, ich ocena i przegląd będzie ogromnie kosztowny. W końcu NIE uwzględnia tego samego czasu. To tak, jakby zawsze próbować odkładać sprzątanie wynajętego mieszkania, a następnie próbować je wyczyścić dopiero po wyprowadzce: To kiepska praca, męcząca, trudniejsza niż byłaby to, gdyby była wykonywana regularnie i często nie da się jej zrobić dobrze.
• Czy produkowałeś testy produkcyjne? Testy jednostek? Testy integracyjne?
• Czy Twój kod był regularnie sprawdzany w SCM? Czy to było w innej branży? Czy potrzebował innej gałęzi, czy można to zrobić w bagażniku? Odkładanie popełnionego kodu jest zwykle złym znakiem. Oczywiście czasami masz ochotę to zrobić, ale po prostu strzelasz sobie w stopę.

W Twojej firmie nikt nie słucha twoich pomysłów

Są tutaj dwie opcje, a my przyjrzymy się obu:

• Twoje pomysły były złe.
• Twoje pomysły były dobre.

Zacznijmy zakładać, że były złe (znowu, zastanawianie się nad tym i zaakceptowanie twojego pomysłu było po prostu złe, wiem). Co robisz, żeby to zmienić?

• Dlaczego wpadłeś na ten pomysł? Jakie jest uzasadnienie ? Czy naprawdę istnieje potrzeba tego, co Twój pomysł próbuje przedstawić na stole?
• Jak wpadłeś na ten pomysł? Zrobiłeś to sam? Udostępniłeś? Burza mózgów? Plan? Prototyp? (rób to w odpowiedniej kolejności. Jeśli się nie powiedzie, odrzuć pomysł, nie kontynuuj. A przynajmniej nie w swoim harmonogramie pracy.)

Pomysły są tylko pomysłami. Jeśli po prostu zaproponujesz je jako pomysły i zostaną one odrzucone, nie rozumiem, dlaczego źle się z tym czujesz. Jeśli jednak zareagujesz na nie, nie powiadamiając nikogo, a NASTĘPNIE prześlesz swoje pomysły, a one zostaną odrzucone, oczywiście odczuwam frustrację w tym czasie. I twoi menedżerowie to robią!

Zakładając, że twoje pomysły były dobre:

• Czy twoja prezentacja była dobra?
• Czy Twój sposób na dostarczenie prezentacji był dobry? (Jestem programistą, wiem o czym mówię: jesteśmy zrzędliwymi, aroganckimi , pedantycznymi PITA, które zawsze mają rację i z którymi ciężko jest pracować, ponieważ często mamy nieproporcjonalne ego ).
• Czy masz plan na jego wdrożenie? Czy myślałeś o koszcie i czasie? Czy zastanawiałeś się, jakie korzyści odniosą użytkownicy / klienci? Czy myślałeś, jak to wpływa na sprzedaż? Czy zastanawiałeś się, jak praca nad tym pomysłem może wpłynąć na inne projekty i priorytety? Powiesz mi: „dlaczego mam to wszystko robić, to zadanie mojego menedżera oraz zespołów marketingu lub sprzedaży ?!” Z wyjątkiem teraz, próbujesz wykonać część wszystkich swoich zadań.

Wzorzec projektowy, który wprowadziłeś siłą w swoim zespole, spowodował bałagan

• Dlaczego wprowadziłeś wzór?
• Jeśli stworzył bałagan, prawdopodobnie albo:
  • nie był odpowiedni wzór,
  • nie został zaimplementowany poprawnie,
  • nie został poprawnie zintegrowany.
• Jak to wprowadziłeś? Jak dokładnie definiujesz stan „bałagan”?
  • mniej czytelny kod?
  • mniej do utrzymania?
  • kompilacje są zepsute?
  • Istnieją różne rodzaje „bałaganu”. Wiedząc, co bałagan jest może pomóc wiedzieć, jaka była awaria tam, a jeśli było to winą za wzorzec projektowy.

Jestem też nieco zaskoczony tym podejściem. Musiałeś w rzeczywistości naciskać na wprowadzenie wzorca projektowego? To wydaje się dość dziwne. Wzór już tam jest, albo musisz zmienić część rozwiązania zgodnie ze wzorem. Nie naciskać go jak byś przyjęcie ram lub technologii (jak ludzie pchnął naprawdę trudno mieć XML wszędzie, a teraz jak ludzie zaczynają popychanie, aby móc napisać HTML5 na ich okładce produktu w dużych jasnych liter).

Dlaczego musiałeś pchać? Dlaczego był opór? Może to było uzasadnione.

Czy byłbyś w stanie podać przykłady, że ten konkretny wzorzec pomógłby w znaczący sposób poprawić bazę kodu (na przykład poprzez dopasowanie go do przykładu Refaktoryzacja do Wzorów ).

Zupełnie nie na temat, ale o tym pomyślałem po raz pierwszy, czytając tytuł pytania, ponieważ myślałem, że odnosi się to do awarii oprogramowania ... Miałem oprogramowanie, które zaimplementowało klasę BlackHole, aby zarządzać wyjątkowymi wyjątkami w jednym z składniki. Może się to wydawać (i naprawdę jest) dziwnym i brudnym hackowaniem, ale samo nazewnictwo było tak wspaniałe, że wszyscy doceniliśmy to za całkiem fajny sposób radzenia sobie z awarią! :)

Krok 1: Można się złościć!

Po pierwsze, zrozumiałe jest, że denerwujesz się lub gniewasz w obliczu niepowodzenia. Udzielając rad komuś w takiej sytuacji, najprawdopodobniej nie będzie chciał usłyszeć „Po prostu zrób to i przejdź dalej” lub „Po prostu pomyśl o tym jako o możliwości uczenia się”.

W rzeczywistości uważam, że zdenerwowanie i wyładowanie frustracji może być zdrowe i produktywne, pod warunkiem, że robisz to prywatnie lub z przyjacielem. Ludzie mają na to różne sposoby, ale myślę, że jednym z najbardziej produktywnych sposobów jest napisanie wściekłego fałszywego listu (ważne! Nie wysyłaj tego listu nikomu ). Wyjaśnij swoje uczucia, na przykład, dlaczego uważasz, że cokolwiek się stało, było nieuzasadnione.

Krok 2: Poświęć trochę czasu, aby się uspokoić.

Upewnij się, że wyraziłeś wszystko, co czujesz, a po uwolnieniu gniewu poświęć trochę czasu, aby się uspokoić. Może potrzebujesz tylko kilku minut, a może kilku godzin.

Krok 3: Sprawdź, co się stało w kroku 1

W tym momencie masz nadzieję, że będziesz w stanie bardziej obiektywnie myśleć o sytuacji. Jeśli napisałeś list, przeczytaj go sam. Jeśli zwierzyłeś się komuś, spróbuj zapamiętać to, co powiedziałeś. Jeśli wyobrażałeś sobie krzyczenie na kogoś, to po prostu przejrzyj to w myślach.

Często piszę list, kiedy jestem zły, a potem po uspokojeniu pracuję nad udoskonaleniem tego listu, aby jaśniej przekazać to, co pierwotnie próbowałem powiedzieć, dopóki nie upewnię się, że ktoś, kto go przeczyta, zrozumie, kim jestem uczucie w tym czasie.

Chodzi o to, aby obiektywnie spróbować ustalić, jakie były twoje punkty. Czy miały sens? Być może potrzebują wyjaśnienia lub dalszych szczegółów. Czy są bezzasadni? Gdybyś miał obiektywnie postawić się w czyimś obuwiu, czy rozumiałbyś poczynione przez siebie punkty? Czy zgodziłbyś się z tymi punktami? Możesz skorzystać z tej okazji, aby ocenić siebie. Co zrobiłeś dobrze? Co mogłeś zrobić lepiej?

Krok 4: Wybierz kierunek działania

Czy można coś zrobić, aby zaradzić sytuacji lub przynajmniej ją poprawić? Zastanów się, czy realistycznie można coś zrobić, aby naprawić lub poprawić sytuację. Często nie ma, ale czasem jest.

Jeśli jesteś winny za coś, może to być tak proste, jak formalne przeprosiny dla kogoś, jasne wyjaśnienie, co poszło nie tak, co zrobiłeś, dlaczego to zrobiłeś i co zrobisz, aby to naprawić lub zapobiec przyszłość.

Następnie zastanów się, co możesz zrobić, aby poprawić przyszłość. Co możesz zrobić, aby zapobiec powtórzeniu się tego samego problemu? Zdecyduj, co chcesz osiągnąć, i wykorzystaj to, czego się nauczyłeś z kroku 3, aby stworzyć własny plan.

Jeśli wszystko inne zawiedzie, spróbuj uruchomić ponownie:

        try
        {
            // ...
        }
        catch (OhNoes111Exception)
        {
            // reboot fixes everything!
            System.Diagnostics.Process.Start("ShutDown", "/r");
        }