Projektowanie wad i radzenie sobie z poniżeniem [zamknięty]

84

Czy zawsze miałeś zasadniczo rację w projektach oprogramowania, które proponowałeś? Kiedy rozdajesz projekt, który był zasadniczo zły, tracisz szacunek innych członków zespołu. Bez względu na to, co zrobisz później, zostaniesz sprawdzony pod kątem wszystkiego, co zaproponujesz po tym incydencie. Jest to szczególnie gorsze, gdy jesteś nowym członkiem zespołu, który nie zna twojej przeszłości, w której miałeś dobre historie sukcesu.

Być może powodem, dla którego podałeś zły projekt, był brak doświadczenia lub wiedzy albo jedno i drugie w tej dziedzinie. Jak sobie z tym poradziliście? Czy to jakaś jednorazowa rzecz w twojej karierze, czy zdarza się to z przerwami? Czy można to opóźnić, czy też w takiej sytuacji trzeba szukać nowej linii pracy? Proszę o szczere opinie ...

Dziękuję Ci.

20358
źródło
17
być może projekt był poprawny, tylko dla innego systemu ;-) nie inwestuj swojego ego w swój kod / projekty, jest zbyt wiele czynników, aby oczekiwać doskonałości; inwestuj zamiast tego w gotowość do nauki, uczciwość (szczególnie w szczerość wobec siebie) i pracę zespołową. Projekt mógł być idealny pierwszego dnia, a wymagania zmieniły się drugiego dnia! Ucz się na tym i kontynuuj
Steven A. Lowe
Dlaczego przywiązanie do twojego projektu? Celem powinno być robienie tego, co najlepsze dla produktu / firmy. Zaproponuj coś Zapytaj ludzi o ich myśli; poproś ich o znalezienie wad. Znalazłeś wady? Opłucz i powtórz. Bez skaz? Idź po to. Potrzebujesz debaty lub dyskusji na temat zalet / wad? Więc zrób to. Broń swojego projektu tam, gdzie trzeba go bronić. Puść to, gdy to po prostu nie działa. Dlaczego miałoby to być krępujące? Burza mózgów. Ludzie powinni zawsze mieć swobodę sugerowania najdzikszych, najgłupszych rzeczy ...
Swati
Myślę, że nie opowiadasz całej historii. Chociaż nie zawsze każdy produkuje dobre projekty, nie każą innym myśleć, że są niekompetentni, chyba że jest naprawdę oczywiste, że projektant nie ma pojęcia. Podejrzewam, że albo tego nie rozumiesz, albo próbowali wskazać pewne ulepszenia, a ty się nie zgodziłeś, najprawdopodobniej odrzucając niektóre bardzo podstawowe zasady. Oba te czynniki sprawiłyby, żebym lepiej nadzorował pracę programisty.
Dunk
1
Nie zgodziłem się Rozwiązanie, które przedstawiłem, nie zostało zakwestionowane przez mój zespół, ponieważ wszyscy są juniorami. Kiedy zaproponowałem to naszemu klientowi, który miał więcej doświadczenia niż ja i lepszej jakości, zacząłem zdawać sobie sprawę z tego, jak on to zastrzelił, że Podjąłem gdzieś zasadniczo złą decyzję. Nie tylko czułem się głupcem, ale także zawiodłem członków mojego zespołu, ponieważ zaufali mi i teraz wątpię, by to zrobili. Nie winię ich. Spojrzałbym na mnie z podejrzanym, gdybym był na ich miejscu.
user20358,
4
Dobry programista nie jest programistą, który zawsze podejmuje właściwą decyzję, ale programistą, który podejmuje złą decyzję, przyznaje ją i szybko odzyskuje.
Rudy,

Odpowiedzi:

177

Kiedyś vp fortuny 500 kosztowało firmę 1 milion dolarów przy złej decyzji biznesowej. Kiedy złożył rezygnację z funkcji prezesa, otrzymał odpowiedź: „Właśnie zainwestowałem milion dolarów w twoją edukację, a teraz próbujesz odejść? Nie zgadzam się”.

Mam już dość kierowników i innych pracowników, którzy szybko obwiniają kogoś za to, że jest debiutantem lub zakłada, że ​​jest niekompetentny. Jest tylko jeden sposób, aby stać się dobrym projektantem, a mianowicie kilka razy więcej. Nie dbam o to, czy moi pracownicy popełniają błąd, dbam o to, czy popełnią to samo wiele razy. Pytanie brzmi: jak pokorny i jak można się uczyć? Kiedy ktoś przedstawi ci twój błąd, czy najpierw bronisz się, czy go wysłuchasz? Jeśli jesteś jednym z nielicznych facetów, którzy potrafią przełknąć swoją dumę i uczyć się na niej, to warto ją zatrzymać. Każdy, komu stracisz szacunek z powodu popełnienia błędu raz, nie jest kimś, kto zasługuje na twój szacunek.

Osobiście musiałem przepisać dwa pierwsze projekty, które zaprojektowałem co najmniej dwa razy, ale wiesz co? Nauczyłem się tony i chociaż moi pracodawcy byli w tym czasie zaniepokojeni, szybko to zrównoważyła wydajność, którą z czasem zyskałem, chętny do uczenia się na własnych błędach.

Jeśli chodzi o aspekt upokorzenia i jak dojść do siebie, mam dwie rady. Po pierwsze, ludzie zapominają z czasem. Ponadto, gdy ktoś inny ma na nich światło reflektorów, również się zepsują. Wtedy wszystko znów będzie równe. Po drugie, nie bądź dupkiem dla innych, którzy popełniają błędy, uczą się, uczą. W rzeczywistości powinieneś ich zachęcać, chyba że naprawdę potrzebują mocnego kopnięcia w tyłek. Z czasem możesz pomóc zmienić kulturę swojego zespołu, pamiętając, jak się czułeś, gdy popełniłeś szczery błąd. W końcu zainspirujesz ludzi do bycia lepszymi programistami, projektantami i ludźmi.

Jonathan Henson
źródło
3
Naprawdę podoba mi się ten komentarz. W przeszłości popełniłem kilka błędów w miejscu pracy i chociaż nie jestem idealny, postanowiłem się od nich uczyć. Podszedłem do mojego współpracownika (znacznie starszy w tej dziedzinie niż ja) i zapytałem, co mogę zrobić lepiej, a ona dała mi kilka dobrych wskazówek. Lubię myśleć, że teraz mam się lepiej. Choć boli mnie świadomość, że popsułem się i poczułem upokorzenie, to w końcu przemija. Jest to dla mnie zachęcające, ponieważ mówi mi, że postąpiłem słusznie i że tak się stanie. Zwłaszcza, że ​​to właściwie moja pierwsza praca. :)
Ben Richards,
1
Twoje prawo, że ludzie zapominają. Kiedyś pomogłem zlikwidować firmę na pół dnia raz na nieudaną aktualizację DB. To był okropny dzień, ale skończyłem i myślę, że wszyscy też.
Kratz
5
Ładna anegdota i dobra uwaga. Oczywiście myślę: Łatwo powiedzieć prezesowi. Nie zainwestował własnych pieniędzy. Ktoś ze skórą w grze nie będzie miał tak dziwnie oderwanej reakcji na kolosalny błąd. Jednak jeśli będą uczciwi, rozpoznają, że popełniali po drodze mnóstwo mniejszych błędów i wyciągnęli wnioski z każdego z nich. Najważniejsze jest, aby szybko zawieść, być szczerym i wybrać coś nowego na swój kolejny błąd. :) Takie podejście zostanie docenione i nagrodzone w firmach, w które warto zainwestować swój czas kariery.
Greg Hendershott
1
@BiAiB Wiceprezydent - zwykle oznacza „zastępcę dowódcy”.
Jonathan Henson,
2
@Greg H: „bizzarely odłączony?” Nie, tylko racjonalne. Ktoś, kto próbuje zrobić dobrą robotę, kto popełnia błąd, uczy się na podstawie tego błędu. Zastąpienie tej osoby, po tym, jak lepiej się uczy, inną osobą, która nie ma doświadczenia, jest złą decyzją. Ten nowy facet może mieć czystą płytę, ale tylko dlatego, że nigdy nie próbował niczego interesującego.
Zan Lynx,
33

Robię to od dłuższego czasu (ponad 15 lat) i za pierwszym razem nadal nie mam racji. Najlepsze projekty powstają w wyniku iteracyjnego procesu współpracy. Kiedy pracujesz od jakiegoś czasu nad projektem, łatwo wpaść w pułapkę myślenia, że ​​jest to jedyny sposób, aby to zrobić. Świeża perspektywa pomaga zobaczyć rzeczy, za którymi tęsknisz.

Aby to zadziałało, zespół musi sobie ufać. Nie możesz bać się pokazywać ludziom projektu, który może być wadliwy, i musisz być w stanie zaakceptować krytykę tego projektu. Z kolei reszta zespołu musi zrozumieć, że wady projektu nie są odzwierciedleniem projektanta. Jest to oczekiwana część projektu. W ten sposób członkowie zespołu uczą się i doskonalą: na własnych błędach i błędach innych.

Jeśli jesteś w dysfunkcyjnym zespole, który tak nie działa, masz dwie opcje:

  1. spróbuj naprawić zespół
  2. znajdź nowy zespół (wewnętrznie lub u nowego pracodawcy).
KeithB
źródło
20

O ile mi wiadomo, zawsze byłem zasadniczo do obrony . To nie całkiem to samo, co bycie zasadniczo poprawnym . Często okoliczności zmieniają się między momentem podjęcia decyzji „x” a momentem, gdy staje się jasne, że „x” było złą decyzją z perspektywy czasu .

To trochę jak przygotowanie amerykańskich podatków dochodowych. Wiele osób uważa, że ​​powinna być odpowiedź. Nie ma Masz swoją opinię; twój księgowy podatkowy ma jej opinię; IRS ma swoją opinię.

Kiedy popełniam błędy, nie tracę niczyjego szacunku. (O ile mi wiadomo.) Myślę, że dzieje się tak, ponieważ po części zawsze przyznam się do własnych błędów. (W rzeczywistości często znajduję własne błędy). Ponadto, prawie wszystkie znaczące decyzje projektowe powodują, że podpisuje się na nich więcej niż jedna osoba. Wszelkie błędy w tych decyzjach są własnością grupy, a nie w całości jednej osoby.

Jeśli chodzi o przyznawanie się do błędów, myślę, że staje się to łatwiejsze, gdy zdobywasz kompetencje i doświadczenie. Z mojego doświadczenia wynika, że ​​im nowszy projekt i rozwój, tym mniejsze prawdopodobieństwo, że popełnisz błąd.

Zdarza się to w kółko i nie powinno wykoleić twojej kariery. Nikt na znaczącej odpowiedzialności niezmiennie podejmuje właściwe decyzje. W rzeczywistości nikt, kto ponosi znaczną odpowiedzialność, niezmiennie podejmuje uzasadnione decyzje.

Ale przez większość czasu powinieneś być w stanie podejmować uzasadnione decyzje na podstawie niepełnych informacji. Jak powiedziała moja córka: „To po prostu bycie ludźmi”.

Mike Sherrill „Cat Recall”
źródło
Im więcej wiem, tym bardziej wiem, że nie wiem. Mój zakres wiedzy rośnie wolniej niż moja świadomość rzeczy do poznania. Staram się być lepszy każdego dnia. Korzystam z najlepszych znanych mi praktyk. Nauczyłem się, że niektóre z nich nie będą tak dobre, jak mi się wydaje. Niestety zgadzam się, że przyznawanie się do błędów staje się łatwiejsze w miarę zdobywania doświadczenia. Jeśli jednak nie masz doświadczenia, należy spodziewać się błędów.
BillThor,
Świetna odpowiedź! Z pewnością popełniłem błędy w projektach, ale nie sądzę, żebym kiedykolwiek był przez nich upokorzony lub stracił szacunek moich kolegów z drużyny. Moje decyzje zawsze były podejmowane z jakiegoś powodu, a kiedy okazało się, że moje rozumowanie było oparte na błędnej lub niekompletnej wiedzy, zawsze uznałem błąd i pracowałem nad jego poprawieniem.
Carson63000,
8

Czasami wszyscy coś robią źle. Błędy są nieuniknione. Przyznaj się swobodnie, gdy się mylisz, ucz się na swoich błędach i okazuj pokorę, zwłaszcza jeśli początkowo nie byłeś przekonany, że tak naprawdę się myliłeś.

„Upokorzenie” nigdy nie powinno się nigdy zdarzyć. Prawdopodobnie wcale nie poprawi to wydajności osoby.

Tutaj, w mojej firmie, rozwinęliśmy kulturę szacunku dla tych ludzi, którzy wciąż są gotowi trzymać się za szyję przy podejmowaniu trudnych decyzji, ale mogą przyznać się do błędu i dostosować swoje zachowanie w razie potrzeby.

MadKeithV
źródło
Będę popierać „kulturę szacunku”. Jestem niestety na tyle szczęśliwy, że jestem jednym z dwóch programistów w naszej firmie. Dlaczego niefortunny? Ponieważ za każdym razem, gdy ja (a nawet ktokolwiek) popełnia błąd, inny programista śmieje się na twoich twarzach jak idiota. Co gorsza, kiedy popełnia błąd, zawsze udaje mu się obarczyć winą gdzie indziej (inny członek personelu, Windows, wyrównanie planetarne). Tak nie powinno być i dlatego całkowicie nienawidzę prosić go o pomoc z obawy, że przerodzi się w konkurs na sikanie.
hermiod
6

Czy zawsze miałeś zasadniczo rację w projektach oprogramowania, które proponowałeś?

Tak, jestem nadludzki! Oczywiście, że nie.

Kiedy rozdajesz projekt, który był zasadniczo zły, tracisz szacunek innych członków zespołu.

Nie! Jeśli tak się stanie, coś jest nie tak z duchem zespołu.

Każdy popełnia błędy. Niektóre rozwiązania okazują się dobre, niektóre złe, większość pomiędzy. Zarówno sukcesy, jak i porażki powinny być traktowane jako lekcja przez ciebie i resztę zespołu.

Pierwsze błędy mogą wydawać się złe, ale po wykonaniu ich setek, jest to po prostu część pracy.

Joonas Pulakka
źródło
4

Zdarza się każdemu. Najważniejsze jest, aby uczyć się na własnych błędach i starać się, aby to się nie powtórzyło. Przyznaj się również, że to był błąd z twojej strony. Na przykład kiedyś popełniłem błąd przy użyciu gorszej warstwy dostępu do danych (SubSonic3). W momencie, gdy podejmowałem decyzję, chciałem po prostu uciec od ręcznie wykonanych zapytań SQL. Wybrałem więc coś, co wtedy wydawało się jednym z najłatwiejszych do rozpoczęcia. Nie miałem też zbyt dużego doświadczenia z DAL. Cóż, po rozwiązaniu kilku problemów zastanawiałem się, dlaczego niektóre zapytania trwały trochę za długo i stwierdziłem, że SubSonic ściąga całe tabele bez powodu.

Więc powiedziałem mojemu szefowi, wyjaśniłem, że popełniłem błąd, i dałem mu mój plan naprawy. Mój szef oczywiście nie był entuzjastycznie nastawiony do tego, że popełniłem dość duży błąd, wymagający kilku dni czystej migracji. Ale upewnił się również, że nie popełnię tego samego błędu. Zmusił mnie do stworzenia projektu sprawdzającego koncepcję dla następnej warstwy dostępu do danych, do której zaproponowałem migrację, i upewniliśmy się, że będzie działał zgodnie z naszymi wymaganiami i że nie zniszczyła całych tabel. Podsumowując, było to dla mnie dobre doświadczenie edukacyjne i teraz upewnię się, że kluczowa część projektu spełnia wymagania i nie ma wielkich problemów.

Więc w zasadzie to, co robisz, to:

  1. Przyznaj się, że popełniłeś błąd
  2. Zrób plan, aby to naprawić
  3. Upewnij się, że Twój plan faktycznie zadziała
  4. Upewnij się jeszcze raz.
  5. Napraw to!

Jeśli nie jesteś pewien, jak to naprawić, nie bój się, aby zaangażować w to innych członków zespołu.

Ostatnia rzecz, zrelaksuj się! Wszyscy popełniają błędy. Bardzo niewiele osób po raz pierwszy robi to idealnie

Earlz
źródło
3

To jest naukowy konkurs na sikanie i nie jest to dobra sytuacja. Nikt nie ma zawsze racji i nie ma się czego wstydzić, jeśli ktoś wymyśli lepszy sposób na zrobienie tego lub jeśli znajdzie problem z tak jak to zrobiłeś.

Musisz emocjonalnie oderwać się od swojego rozwiązania i spędzić czas na szukaniu najlepszego rozwiązania, wtedy możesz być zadowolony, gdy problem zostanie rozwiązany, nawet jeśli zostanie rozwiązany przez kogoś innego.

Satanicpuppy
źródło
3

W swoim pytaniu wiele nie mówisz. Nie mogę powiedzieć, jakie jest twoje ustawienie do „wydawania projektu”. Czy jest to wstępna dyskusja z rówieśnikiem na temat twojego planowanego podejścia, czy też dostarczenie czegoś, co, jak masz nadzieję, jest ostatecznym kodem?

Jeśli to pierwsze, to nie ma powodu, aby czuć się źle i nie ma powodu, aby twoi rówieśnicy cię podejrzewali w przyszłości.

Jeśli czekasz na ostateczną dostawę, aby omówić swój projekt z kimś innym, nie winię ich za to, że są podejrzliwi w stosunku do twojej drugiej pracy.

Każdy musi omówić swój projekt z kimś innym. W zależności od złożoności lub krytyczności może być konieczne kilkakrotne omówienie tego problemu z wieloma osobami. Każdy może popełnić błąd, niezrozumieć wymaganie lub pominąć specjalny przypadek.

Błędy zidentyfikowane wcześnie są łatwiejsze i tańsze do naprawienia. Powinny być wybaczalne, chyba że ciągle powtarzasz te same błędy. Recenzje wzajemne ułatwiają wczesne wykrywanie błędów.

Jeśli próbujesz być samotnym programistą w środowisku zespołowym, popełniasz (prawie niewybaczalny) grzech, myśląc, że jesteś wystarczająco doskonały, aby nie potrzebować pomocy nikogo innego. Fakt, że jest to środowisko zespołowe, dowodzi, że problem jest na tyle duży, że nikt nie zrozumie wszystkiego. Ludzie muszą ze sobą rozmawiać, w przeciwnym razie błędy odwrócą swoje brzydkie głowy o wiele za blisko do uwolnienia (lub po uwolnieniu).

jimreed
źródło
Moje rozwiązanie nie zostało zakwestionowane przez mój zespół, ponieważ wszyscy są juniorami. Zostałem doprowadzony do zespołu, aby rozwiązać problem, w którym zespół się nie udał. Ponadto pojawił się już problem złego projektu, zapachów kodu itp. Zostałem wciągnięty jako panaceum, aby to naprawić i uszczęśliwić klienta. Kiedy zaproponowałem ten nowy projekt naszemu klientowi, który miał więcej doświadczenia niż ja i lepszej jakości, zacząłem zdawać sobie sprawę z tego, że właśnie zestrzelił go, że podjąłem gdzieś zasadniczo złą decyzję. To było stopniowo lepsze niż to, co zrobił zespół, ale wciąż dużo na czerwono ...
user20358
Jako starszy pracownik powinienem był wiedzieć o tych rzeczach. Jestem pewien, że mój zespół też tak myśli.
user20358,
@ user20358 Powiedziałbym, że powinien być jeszcze czas, aby ocalić swoją reputację w zespole. Znaczących problemów nie można naprawić natychmiast. Czy zostałeś wciągnięty w magiczną kulę za jednym strzałem, czy też zostałeś wciągnięty, aby stale dodawać doświadczenia zespołowi? Mam nadzieję, że to drugie. Zakładając, że musisz zintegrować się z zespołem, aby mogli nauczyć cię tego, czego się nauczyli po drodze, i możesz wykorzystać swoje doświadczenie, aby poprowadzić ich w lepszym kierunku. Potwierdź ich sukcesy i poprowadź je, aby zobaczyli i odkryli sposoby ulepszenia produktu.
jimreed,
3

Zawsze dokonywałem rozróżnienia między, z jednej strony, dobrymi a złymi decyzjami; i na innych poprawnych i niepoprawnych decyzjach. Dobra decyzja to taka, która w tych samych okolicznościach, przy tych samych informacjach, podejmowałabyś w ten sam sposób; zła decyzja to taka, którą podjąłbyś inaczej. Prawidłowa decyzja to taka, która z perspektywy czasu i dodatkowych informacji okazuje się słuszna; i odwrotnie z nieprawidłowymi decyzjami.

Często mówi się, że osoba, która nie podejmuje niewłaściwych decyzji, nigdy niczego nie podejmuje. Nieprawidłowe decyzje są sposobem, w jaki się uczy. Złe decyzje są często zaostrzone, ponieważ decydent inwestuje się w decyzję i próbuje retrospektywnie uzasadnić decyzję lub udowodnić, że mimo wszystko była to dobra decyzja (ukrywanie jest zawsze bardziej szkodliwe niż pierwotna decyzja).

Większość podjętych przeze mnie decyzji projektowych okazała się słuszna, ale większość się nauczyłem i posunąłem się naprzód z decyzjami, które były niepoprawne. Mam nadzieję, że bardzo niewiele moich decyzji było złymi decyzjami, ale część problemu z własnymi złymi decyzjami polega na rozpoznaniu, że decyzja była zła, i zaakceptowaniu wynikających z nich często niesmacznych lekcji.

Chris Walton
źródło
3

Dopóki nie są „rozgrywającym w poniedziałek rano ”. Nie mam pożytku z tego, że ktoś, kto bierze udział w rozmowach projektowych, nie mówi nic, tylko twierdząc, że wie, że to nie zadziała po tym fakcie. Musisz być w stanie przyjąć krytykę, nawet jeśli nie jest umieszczona w konstruktywnym kontekście.

Prawdopodobnie jedną z najlepszych cech witryny SO jest możliwość podjęcia ryzyka i zaproponowania niepewnego rozwiązania. Tak się uczysz. Przechodzenie przez życie z kupą gówna w głowie, które jest złe, ale nigdy nie powiedziano ci o zdradzie, jest prawdziwą ignorancją.

Mogą wiedzieć coś, czego ty nie wiesz, ale nie będą wiedzieć wszystkiego. Pokonaj go, zabierz się do roboty i zrób coś. Niech marnują czas, myśląc, że są tak cholernie mądrzy.

JeffO
źródło
2

Czy zawsze zapewniałem dobry projekt? Nie! Staram się to robić, staram się być lepszy, ale z każdym kolejnym projektem wydaje mi się, że zawsze mogę spojrzeć wstecz na to, co zrobiłem wcześniej, i wzdrygać się, że w jakiś sposób przegapiłem znak.

Jeśli chodzi o kogoś, kto zaproponował projekt mniej gwiezdny, nie przeciwstawiłbym się tej osobie, gdyby ta osoba wykazała, że ​​chętnie uczy się na błędach i jest otwarta na krytykę. Jeśli widzę dowody na to, że osoba podobnie dąży do poprawy i ma taką możliwość, to zła propozycja projektu jest tylko okazją do nauki.

Anthony Pegram
źródło
1

Zdarza się to każdemu od czasu do czasu, więc najlepiej jest dowiedzieć się, dlaczego projekt był zły i wyciągnąć z tego wnioski. Jeśli jest to brak wiedzy, wówczas niepowodzenie projektu da nadzieję, że da ci trochę nowej wiedzy, którą możesz wykorzystać następnym razem. Nie zniechęcaj się, wszyscy przechodzą przez to w pewnym momencie. To najlepszy sposób na zdobycie doświadczenia i złapanie nowego zespołu / środowiska.

FrustratedWithFormsDesigner
źródło
1

To się często zdarza. Nasza branża zmienia się tak szybko, że szanse, aby nigdy się nie pomylić, są w rzeczywistości zerowe.

Czy jednak zepchnąłeś zły projekt na ich gardła nad ich obiekcje? Może dlatego przesadzają.

Jeśli błąd był poważny, oczywiście odzyskanie szacunku zajmie trochę czasu. Gdyby któryś z twoich współpracowników poprowadził cię w złym kierunku i stworzył problemy dla całego zespołu, czy nie potrzebowałbyś go, aby udowodnił, że w najbliższym czasie okaże się więcej?

Wszystko, co możesz zrobić, to przyznać się do błędu, przyznać, kto miał rację, i starać się lepiej słuchać i lepiej badać opcje w przyszłości.

Co według ciebie nie popełniło błędu w projekcie? (Nieprzypadkowy przykład - zaprojektuj proces importu, aby korzystać z istniejącej usługi internetowej, która działa wiersz po rzędzie (ponowne użycie kodu i tylko zmiana reguł biznesowych w jednym miejscu), nie zdając sobie sprawy, że niektóre importy będą miały miliony rekordów i zajmie to dni koniec.) Ucz się z niego i rozważ te rzeczy w przyszłości.

HLGEM
źródło
Nie, nie pcham złego projektu. Zostałem doprowadzony do zespołu, aby rozwiązać problemy, w których zespół ciągle się nie udaje. Ponadto pojawił się już problem złego projektu, zapachów kodu itp. Zostałem wciągnięty jako panaceum, aby to naprawić i uszczęśliwić klienta. Powiedzmy po prostu, że kiedy zaproponowałem ten nowy projekt naszemu klientowi, który miał więcej doświadczenia niż ja i lepszej jakości, zacząłem zdawać sobie sprawę, gdy właśnie go zastrzelił, że podjąłem gdzieś zasadniczo złą decyzję. To było stopniowo lepsze niż to, co zrobił zespół, ale wciąż dużo na czerwono ...
user20358
Przyznałem, że się myliłem, ale to nic nie pomogło, ponieważ zarówno mojemu menedżerowi, jak i klientowi, powinienem był wiedzieć lepiej, biorąc pod uwagę moje doświadczenie.
user20358,
1
Następnie musisz po prostu pracować, aby udowodnić im się w najbliższym czasie. Ludzie popełniają błędy, ważne jest, w jaki sposób dochodzą do siebie po zamoczeniu. Brzmi to tak, jakbyś nie miał informacji potrzebnych do wykonania projektu, być może powinieneś rozważyć przeprowadzenie dokładniejszych badań przed kolejną propozycją projektu. Kiedy coś jest już w złym stanie, trudno jest zaprojektować rozwiązanie wszystkich problemów, skupiasz się na niektórych, ale bardziej krytyczne mogą nie być tak oczywiste.
HLGEM,
0

Tam będzie zawsze być błędy. Błędem jest bycie programistą. Ucz się od innych w Internecie, a zwłaszcza od współpracowników. Jedynym wstydem byłoby poddanie się lub zakopanie głowy w piasku, jeśli chodzi o takie problemy od teraz.

Połóż to za sobą, opuść głowę i daj z siebie wszystko. Jeśli jesteś dobrym programistą, przejrzysz swoje błędy.

Jarrod Pokrzywy
źródło
0

Jeśli nie masz pewności, że Twój pomysł ma solidne podstawy, powinieneś omówić go z kilkoma zaufanymi współpracownikami, zanim zaproponujesz go całej firmie lub działowi. W rzeczywistości, nawet jeśli jesteś tego pewien, powinieneś omówić to z ludźmi, z którymi współpracujesz i którzy najprawdopodobniej cię znają najlepiej. Pomogą ci wcześnie wykryć problemy.

Caleb
źródło
0

Zdarza się nam czasami. Użyj pierwszego projektu jako prototypu. Dowiedz się dokładnie, co zadziałało, a co nie i dlaczego. Następnie możesz napisać o wiele lepszy produkt końcowy.

Nie próbuj się usprawiedliwiać ani bronić. Przyznaj się do błędu i idź dalej.

Tom Squires
źródło
0

Problem podstawowy nie wydaje się wyjaśniony: jest to problem społeczny . Możesz zobaczyć takie zachowanie w prawie każdym zawodzie: jeśli popełnisz błąd, a oni lubią „kategoryzować” cię w pewnych rzeczach, to na zawsze. To zachowanie społeczne. Nawet sprytni i mądrzy ludzie będą podążać za wszystkimi.

Dam wam przykład, który nie ma nic wspólnego z programowaniem: w mojej poprzedniej pracy zapomniałem umyć naczynia raz lub dwa. Od tego czasu wszyscy pracownicy myśleli, że jestem typem człowieka, który nigdy nie myje moich naczyń. A teraz, gdy tylko zlew znajdzie się w zlewie, to ja (kto inny mógłby to być).

Wszędzie jest tak samo: jest to zachowanie społeczne , bez względu na rodzaj problemu.

Mówisz mi, że chcesz uczciwej opinii? Jedynym rozwiązaniem jest rezygnacja z innej pracy. Jeśli wszyscy ludzie w zespole uważają, że nie jesteś dobry w swojej pracy, wkrótce się to nie zmieni, przepraszam, że to powiedziałeś. Poszukaj innej pracy, ponieważ nigdy nie zmienisz tego rodzaju (głupiego, muszę wyznać) zachowania społecznego .

Olivier Pons
źródło
0

Kluczem jest to, w jaki sposób określasz swoją sprawę i jakie zmiany wprowadzasz. Jeśli twierdzisz, że jesteś guru programowania, który nie robi nic złego i jest bardziej niesamowity niż Jon Skeet, jest całkiem prawdopodobne, że w pewnym momencie zostaniesz za to odrzucony. Kluczem jest to, w jaki sposób prezentujesz swoje rozwiązania, abyś mógł pokazać, że jest to rozsądne rozwiązanie problemu, a nie idealne rozwiązanie, którego nawet nie należy sprawdzać.

Moim najlepszym przykładem byłoby odkrycie skutków ubocznych posiadania klasy staticw aplikacji internetowej, w której kiedyś pracowałem. Nie wiedziałem, jak źle byłoby, gdyby ta jedna instancja trwała i była udostępniana wszystkim użytkownikom aplikacji, ale wyciągnąłem z niej wnioski i odzyskałem czas. Czasami może się zdarzyć, że coś zostanie znalezione i trzeba będzie dokonać poważnych korekt. Byłem także w tym obozie, w którym musiałem przeskanować kilka skryptów VBScript, aby zredukować konkatenacje ciągów, które powodowały problemy z pamięcią, w których kiedyś pracowałem. Pamiętam nawet pisanie kodu podatnego na zastrzyki SQL w 1998 r., Kiedy pisałem znaleziony fragment kodu klienta, który musiał dynamicznie generować SQL, ponieważ miałem około 20 opcjonalnych pól w tej części aplikacji.


Perfekcjonizm może być tutaj trochę obosiecznym mieczem, dlatego też widzę ten trzeci komentarz, a także sposób, w jaki czasami jestem. Złe jest widzenie, że są wszystkie te błędy i nic nigdy nie jest w porządku. Dobrą rzeczą jest to, że zdobywając to, co najlepsze, możesz spełnić, jeśli nie przekroczyć oczekiwań innych. Ciągłe doskonalenie może być sposobem na postrzeganie perfekcjonizmu na PC i jeśli jest utrzymywane z umiarem, uważam to za dobrą rzecz. Czy pomimo popełnionych błędów Twój kod wchodzi do produkcji? Czy wykona to zadanie? Są to kwestie do przemyślenia, a także to, czy ktoś zawsze coś naprawia, czy też dobrze, że chcesz być tak dobry, że wolisz nie robić nic innego, dopóki nie będzie to idealne? Praktyka może być przydatna, aby znaleźć wzorce do lepszego wykonywania pracy. Jednak,

JB King
źródło
I'm no jon skeet :)
user20358,
Popełniłem również podobny błąd. Podjęcie decyzji o zachowaniu klasy statycznej jako kontrolera w aplikacji MVC. Pochodząc z proceduralnych podstaw, moje myślenie OOP ewoluuje każdego dnia. Nadal uważam, że muszę się wiele nauczyć, podejmując decyzję, kiedy abstrahować, a kiedy nie. kiedy odziedziczyć, kiedy iść na kompozycję. Najgorsze jest to, że po zestrzeleniu spędzam czas na nauce i po pewnym czasie mam wrażenie, że w końcu go dostałem. Aż znów mnie zestrzelono. Potem wracam do nauki.
user20358,
Nie przeszkadza mi nauka. To tylko reputacja, którą tracisz, jeśli popełniasz błędy, nawet jeśli za każdym razem są inne. Dla wszystkich wokół nadal wygląda na to, że popełniłeś wiele błędów. Nie nowy za każdym razem, od którego nauczyłeś się i byłeś lepszy.
user20358,