Czy jest jakiś sposób na szybsze rozwiązywanie problemów? Właśnie otrzymałem ostrzeżenie od mojego szefa [zamknięte]

Właśnie powiedział mi mój szef, że w poniedziałek otrzymam negatywną ocenę wydajności. Chce ze mną porozmawiać o tym, dlaczego jestem taki wolny i dlaczego mój wskaźnik naprawiania błędów jest tak niski.

Uwielbiam programować i rozwiązywać problemy, ale moja praca jest naprawdę bardzo trudna.

Jestem programistą przez około 10 lat. Ale to moja pierwsza wielowątkowa praca z osadzonym linuksem - jestem tu 2 lata i dla wszystkich jest oczywiste, że wciąż mam problemy. I myślę, że stałem się tak zdemoralizowany i czuję się tak marginalizowany, że straciłem dużo ognia, który miałem na początku pracy.

Czy ktoś kiedykolwiek był w podobnej sytuacji i jak możesz zwiększyć częstotliwość naprawiania błędów?

Aktualizacja: miałem recenzję. Zostałem przydzielony do trzymiesięcznego „programu rozwoju pracowników” (w rodzaju wspomnianego przez Dunka). Nie jestem pewien, czy mogę to odwrócić. Ale nawet jeśli muszę przejść dalej, wiele się nauczyłem z tego doświadczenia.

Kolejna aktualizacja

Minęło około 6 tygodni od pierwszej recenzji. Radzę wszystkim, którzy znajdują się w tej samej sytuacji, aby być wystarczająco pokornym, aby przyjąć krytykę i uczyć się na własnych błędach. I nie bój się wyglądać głupio. Zadawaj mnóstwo pytań. Poinformuj ludzi, że próbujesz się uczyć, i pytaj, aż zrozumiesz. Ale bądź przygotowany na to, że się nie uda. Tworzę portfolio kodów ... i daję z siebie wszystko.

Kolejna aktualizacja

Waham się, aby to tutaj załączyć, ponieważ obawiam się, że nie będę w stanie skierować przyszłych pracodawców do mojego profilu przepełnienia stosu ... Ale i tak może to być interesujące dla kogoś, kto czyta to pytanie, ale tak naprawdę straciłem praca kilka tygodni temu. Jestem w trakcie doskonalenia wszystkich umiejętności, których potrzebuję - wiele skorzystałem z podanych tu rad.

Wiele odpowiedzi kwestionowało metody / taktykę / metryki twojego szefa itp. Ale to nie ma sensu. Może jesteś powolny. Każdy pokój deweloperów musi mieć JEDEN, który jest wolniejszy niż reszta, prawda? (To tylko prosta teoria zbiorów.) Załóżmy, że to ty. Odpowiedź brzmi: DLACZEGO jesteś wolny? (Oczywiście jest to pytanie, na które musisz odpowiedzieć, zanim będziesz w stanie rozwiązać zadane pytanie, jak uzyskać szybsze tempo).

Mogą być różne powody, ale oto kilka możliwych wyjaśnień do rozważenia:

1. Jesteście mniej inteligentni niż oni . To możliwe, prawda? (Badania wykazały, że WSZYSCY jesteśmy mniej popularni , mniej interesujący i (a następnie) mniej inteligentni niż nasi przyjaciele.) Więc może jesteś po prostu powolny. Z drugiej strony uważam, że jest to mało prawdopodobne. Szybkie spojrzenie na Twój profil StackOverflow pokazuje, że masz historię inteligentnych pytań na wiele różnych tematów. Więc jesteś oczywiście myślicielem i prawdopodobnie dobrym.

2. Jesteś zbyt cienki. Ten sam profil SO pokazuje, że twoje pytania obejmują bardzo szeroki zakres technologii w ciągu ostatnich 2 lat (grafika, sieć, python, c ++, c, linux, embedded, wątki, gniazda itp.). Osobiście wiem, że kiedy znalazłem się w sytuacji, w której musiałem (lub chciałem) zagłębić się w wiele różnych strumieni, bardzo szybko (lub raczej bardzo powoli ) płynę . Być może naprawdę potrzebujesz tutaj FOCUS . A może zdrowa dawka priorytetów . Czy istnieje możliwość przeniesienia mniej ważnych garnków do tylnego palnika i zwiększenia ciepła głównego naczynia?

3. Nie bawisz się Kiedy ogień gaśnie, silnik parowy ma zwalniać. Przyznałeś w swoim poście, że twoje morale odniosło ostatnio poważny cios. Niestety zostałeś pochłonięty przez zasysające wiry samowzmacniających się harmonicznych ujemnych - siły, która może niszczyć mosty . To zbyt dobrze znana spirala: trudne zadanie -> stres -> przekroczony termin -> większy stres -> zły mechanizm radzenia sobie -> więcej stres -> kunktatorstwo -> więcej przekroczonych terminów -> krytyka / plotki (prawdziwe lub wyobrażone) - > jeszcze więcej stresu. Dostajesz obraz. To rzadko prowadzi do czegoś użytecznego. Weź lekcję z moich dni w raftingu: kiedy zostaniesz wciągnięty pod wodę przez krążący prąd z tyłu szybkiej klasy 4, twoja kamizelka ratunkowa NIEpocieszyć cię z powrotem na powierzchnię. Najlepszą strategią (choć nieintuicyjną) jest znalezienie dna rzeki i wyjście z riptide. Tak więc radzę ci: znajdź trochę ziemi , koleś (przyjaciele, kościół, nowe zdrowe nawyki itp.) I skorzystaj z niej, by wyprowadzić się z jacuzzi.

4. Nie jesteś w swojej strefie. Michael Jordan był bardzo kiepskim graczem w baseball. (OK, wciąż był lepszy ode mnie, ale zdecydowanie mniej znaczący.) Może „wielowątkowość wbudowanego linuksa” po prostu nie jest twoim koncertem. Ale Software Development to dziedzina niezwykle szeroka (jak dobrze wiecie; por. Nr 2 powyżej). Czy Twoja firma jest na tyle szeroka, że ​​możesz znaleźć inną niszę? W mojej ostatniej pracy zostałem zatrudniony jako wbudowany programista. (Nie miałem doświadczenia w tej dziedzinie, ale powiedziałem im, że jestem „szybkim uczniem”). Szybko zatonąłem jak kamień. Ale nadal ciężko pracowałem i szukałem problemów, które zrobiłemumieć dla nich rozwiązać. Jak się okazało, stopniowo mogłem migrować do nowych obowiązków, przy których mogłem zabłysnąć i za co ostatecznie otrzymałem znaczne wyróżnienie. Może więc musisz samodzielnie zmienić markę.

Chodzi o to, że jeśli jesteś wolny, masz powód. Ale hej - jesteś inżynierem oprogramowania, stary! Debuguj się!

Twój szef może mieć rację: możesz być „gorszy” (więcej o tym za minutę). Ale to nie wina twojego poziomu kompetencji. Nie sądzę, aby zasięgnięcie sugestii, że siły poza twoją kontrolą powodują stres, ma negatywny wpływ na twoje wyniki.

Rzućmy okiem na kilka powodów, dla których twój szef może teraz o tym mówić:

Kultura i polityka

Mogą istnieć siły poza twoją kontrolą, wymagające od szefa wyrażenia swojej troski. Ważne jest, aby zrozumieć system, w którym pracujesz. Twoim zadaniem jest sprawić, by szef wyglądał dobrze. Jedynym sposobem, aby to zrobić, jest zrozumienie presji, na którą on / ona ma wpływ.

Umiejętność

Możliwe, że umiejętność nie jest na równi, jak mówisz, otwarcie stwierdził. Oto, co bym zrobił w tej sytuacji:

Uzyskaj szczegółowe informacje od swojego szefa na temat tego, jak mierzy wydajność. Czy nie zamykasz tylu błędów, ile osoba X? Czy jest określona liczba błędów, które powinieneś rozwiązać? Jeśli pracujesz sam, musisz upewnić się, że osoby mierzące twoją wydajność mierzą ją uczciwie i nie opierają się na z góry przyjętym pomyśle.

Jeśli twoje wyniki są powolne i oparte na prawdziwej luce, zidentyfikuj tę lukę i opracuj szczegółowy plan wraz z szefem, aby go wypełnić.

Ta recenzja jest również dobrą okazją, aby poruszyć fakt, że nie jesteś zadowolony. Dobrze, że zauważyłeś, że nie kochasz tej pracy. Ale dowiedz się, dlaczego. Jaką część swojej pracy lubisz, a co nie? Być może ta praca nie jest dla ciebie ...

Niektóre środowiska pracy są niewykonalne. Widziałem środowiska, w których nikt nie był w stanie przeżyć (z wyjątkiem tych, którzy byli na początku), ponieważ tyle rzeczy było nieudokumentowanych, a pytania były tak gwałtownie zniechęcone.

Naprawdę musisz być ze sobą szczery, jeśli chodzi o oczekiwania i zasoby, które pomogą Ci je spełnić. Problemem może nie być Ty.

Wspominasz, że są ludzie wykonujący podobną pracę do twojej, którzy, jak przypuszczam, nie mają trudności, ale mają ponad 5 lat doświadczenia w stosunku do twoich. Jak się czujesz w porównaniu z rówieśnikami? Czy są gwiazdami rocka, którzy całkowicie cię przewyższają (pod tym względem), czy są tacy jak ty? Być może dopiero poznali system, kiedy był prostszy ... Wspomniałeś o 8-letnim doświadczeniu w programowaniu przed tą pracą. Jak się tam dostałeś? Jeśli zrobiłeś świetnie, to powinno ci coś powiedzieć.

To, co mnie uderzyło, polega na tym, że opisałeś siebie jako ciemność w odniesieniu do wszystkich błędów, które pojawiały się na twojej drodze. Możliwe, że baza kodu jest tak rozległa i niezbadana, że ​​oczekiwania mogą być nieuzasadnione.

Gdybyś to zrobił tak daleko, jak to możliwe, oznacza to, że zrobiłeś coś dobrze i masz coś dla siebie.

Podsumowując, myślę, że musisz czuć się dobrze ze sobą i tym, co robisz. A jeśli to oznacza kontynuację, niech tak będzie.

Lepiej iść dalej, niż praca zrujnuje ci życie.

Po pierwsze, uwaga: ta odpowiedź może dotyczyć tylko niektórych regionów, w których zwolnienie pracownika bez odprawy jest nielegalne. To mówi...

Może to być przypadek konstruktywnego zwolnienia i który jest nielegalny.

Taktyka polega na zdemoralizowaniu i obniżeniu samooceny pracownika, dopóki nie porzuci pracy. Jest to sposób na zaoszczędzenie pieniędzy przez firmę bez konieczności odprawy lub rozwiązania problemu konfrontacji z pracownikiem i zwolnienia go.

Chce ze mną porozmawiać o tym, dlaczego jestem taki wolny i dlaczego mój wskaźnik naprawiania błędów jest tak niski.

Ta wina jest bardzo niejednoznaczna. Żadna ze stron nie może twierdzić, że druga strona jest w błędzie. Naprawienie jednego błędu zajęło miesiąc. Więc co! To stawia cię w pozycji obronnej, ponieważ musisz przedstawić fakty na poparcie swojego twierdzenia, że ​​wymagany był miesiąc. Biorąc pod uwagę twoje obecne umiejętności, doświadczenie i wiedzę jako czynniki. Jako pracodawca zadaniem pracodawcy jest zarządzanie czasem i wysiłkiem jego pracowników. Pracodawca musi być osobą zaangażowaną w ryzyko związane z naprawieniem błędów. Nie pracownik. Zawsze miał możliwość przypisania błędu komuś innemu.

Jeśli jesteś kontrahentem i w umowie określono, że będzie on odpowiedzialny za naprawianie błędów, to zupełnie inna historia.

Czy to źle, że pracodawca narzeka, że ​​trwa zbyt długo? Absolutnie nie, ale nie może cię pociągnąć za to do odpowiedzialności i nie może cię za to zwolnić. Może ci powiedzieć: „Nie mamy już żadnych błędów, które wymagają twoich umiejętności, a ty zostajesz zwolniony”, ale muszą ci powiedzieć, gdy pojawi się nowy problem, który możesz naprawić. W przeciwnym razie muszą zakończyć się zerwaniem. To, czego nie może zrobić, to dać ci pracę, z którą nie możesz sobie poradzić, a potem narzekać. Myślę, że to nielegalne.

Uwielbiam programować i rozwiązywać problemy, ale moja praca jest naprawdę bardzo trudna.

Istnieje duża różnica między podjęciem pracy, która jest dla ciebie trudna, a pracodawcą, który daje ci pracę, która jest zbyt trudna. Jeśli uważasz, że powierzone Ci zadania zostały wykonane, aby zniechęcić cię do kariery w firmie, może to być nielegalne.

Jestem programistą przez około 10 lat. Ale to moja pierwsza wielowątkowa praca z osadzonym linuksem - jestem tu 2 lata i dla wszystkich jest oczywiste, że wciąż mam problemy.

Dlatego myślę, że znalazłeś się w środku konstruktywnego zwolnienia. Nie są z tobą zadowoleni, więc nakładają na ciebie bzdury, dopóki nie odejdziesz.

I myślę, że stałem się tak zdemoralizowany i czuję się tak marginalizowany, że straciłem dużo ognia, który miałem na początku pracy.

Pracodawca jest odpowiedzialny za zapewnienie bezpiecznego i pozytywnego środowiska pracy. Bez dodatkowych informacji (najprawdopodobniej osobistych) trudno jest osobom z zewnątrz powiedzieć, co naprawdę się tutaj dzieje. Poproś prawnika ds. Zatrudnienia o bezpłatną konsultację. Będą mogli powiedzieć, czy grasz.

Bibliografia

Nie jestem prawnikiem, ale czy Google napisał kilka dokumentów omawiających konstruktywne zwolnienie, które warto przeczytać przed wpisaniem recenzji w poniedziałek. Najważniejsze jest, aby uważać na obniżenie wynagrodzenia, poniżenie i nagłe zmiany w swojej karierze w firmie.

Istotne fakty uważaj na:

• Brak odpowiedniego wsparcia pracownika w trudnych warunkach pracy
• Nadmierna dyscyplina pracownika Narzucenie zmiany miejsca pracy pracowników w krótkim czasie
• Nałożenie obniżki wynagrodzenia lub wynagrodzenia

Prawne pytania i odpowiedzi: konstruktywne zwolnienie

Powody roszczenia o konstruktywne zwolnienie

Wikipedia

elementy konstruktywnego zwolnienia

Być może jesteś porównywany do jednego z oryginalnych programistów projektu. Wiem, że jako oryginalny twórca jednego z projektów, nad którymi pracuję, mam ogromną przewagę przy naprawianiu błędów. Nie sądzę, że dzieje się tak z powodu braku dokumentacji, po prostu mogę intuicyjnie przeskakiwać do potencjalnych problemów, ponieważ mój mózg zna cały kod.

Jeśli jesteś do tego porównywany, to po prostu nie zamierzasz mierzyć. Zawsze zajmie Ci więcej czasu, aby przyspieszyć realizację projektu i nie będziesz wiedział, gdzie znajdują się wszystkie potencjalne punkty interakcji.

Przeczytałem twój komentarz o niewiedzeniu o narzędziach i sztuczkach, których inni programiści używają do rozwiązywania problemów. Być może do następnej poprawki musisz spróbować sparować programowanie. Może to być niezwykle przydatne. Na zmianę steruj klawiaturą. Zrobić dużo rozmawiać.

Możesz użyć notatnika lub tablicy do wykreślenia ścieżek funkcji, wątków i czasu życia blokady, a także zaznaczenia, gdzie obserwujesz różne zachowania i gdzie możesz wstawić nowe sondy.

Rozwiązanie tego rodzaju problemów z wątkami niskiego poziomu może być naprawdę trudne i mam dla ciebie wiele sympatii. Musiałem przeanalizować kilka gigabajtów plików dziennika, aby wykryć problem z dwoma liniami. I wiesz co? Patrzyłem na to przez kilka dni, zanim poprosiłem o pomoc młodszego inżyniera, który rok wcześniej był stażystą, a on zaproponował nowe podejście i zauważył problem w ciągu godziny. Tak więc, gdy poświęcisz trochę czasu na błąd, zwróć na niego uwagę. To może bardzo pomóc!

Jedną z najczęstszych dysfunkcji zarządzania w tej branży jest niezrozumienie, że debugowanie jest z natury trudne . Mam prawie 20 lat doświadczenia i ciągle muszę spędzić cały tydzień na znajdowaniu błędu w jednej linii, który powoduje awarię programu jeden raz na pięćdziesiąt. A potem, jeśli mój menedżer nie rozumie tych rzeczy, przeszkadza mi, że poświęciłem tydzień na zmianę jednej linii kodu.

Co możesz z tym zrobić?

• Rób notatki podczas debugowania. Po prostu zawsze otwórz okno edytora i zapisz swój strumień świadomości. To nie musi mieć sensu dla nikogo oprócz ciebie. Może się okazać, że pomaga to w szybszym debugowaniu, ale oznacza również, że masz coś konkretnego do wskazania, aby pokazać, że nie grałeś w Nethacka przez cały tydzień.

• Porównaj notatki ze wszystkimi współpracownikami. Jak długo zajmuje im naprawienie błędów? Czy ich błędy pozostają nierozwiązane? Jak często zmieniają jedną małą rzecz i znajdują się pochowani pod stosem kaskadowych konsekwencji? Odpowiedzi na te pytania pozwolą ci zrozumieć, czy naprawdę walczysz z resztą działu.

• Zaprzyjaźnij się z osobami odpowiedzialnymi za kontrolę jakości i obsługą klienta. To oni mają najlepszy pomysł na to, jak ważne są błędy. Często ma to niewielką lub żadną korelację z tym, jak trudne są błędy, więc możesz trochę zagrać w system i spróbować przypisać wszystkie ważne błędy o niskim stopniu trudności. (To nie jest tak naprawdę oszustwo. Dobrze zorganizowany zespół zawsze najpierw szuka tych błędów.)

• Jeśli twój szef nie udzielał ci wystarczających informacji zwrotnych na temat twoich wyników przez dwa lata z rzędu, jest to problem, który należy najpierw omówić w tym przeglądzie wydajności, a następnie, gdy dostaniesz obejście tego, aby podnieść się z szefem swojego szefa. Bądź grzeczny, a zwłaszcza nie pozwól im zobaczyć, jak jesteś zły, ale napisz konkretną krytykę na piśmie.

Chociaż możesz lubić programować i rozwiązywać problemy, może pojawić się pytanie, jak dobrze stosujesz to, czego się uczysz w innych obszarach. Czy któryś z ostatnich kilkunastu błędów, które naprawiłeś, jest na tyle podobny, że to, co pomogło ci naprawić, było przydatne na innym? Jest to część spojrzenia wstecz na to, co zrobiłeś i ile czasu zajęło, aby to zrobić. Tylko pomysł do rozważenia.

Po drugie, przyjrzałbym się, jak sobie radzisz. Czy regularnie przeszkadzasz i próbując naprawić błąd A, słyszysz, że błędy B i C mają wyższy priorytet? Zastanów się dokładnie, jakie zmiany w sposobie wykonywania pracy mogą ci w tym pomóc, ponieważ jest to prawdopodobnie część tego, co szef będzie chciał wiedzieć.

Miałem kilka miejsc pracy, które mówią mi, że nie podobają im się, ile czasu zajęło mi wykonanie części mojej pracy. Oczywiście były to te miejsca, w których gdybym zrobił jedną rzecz, 5 nowych rzeczy spadłoby mi na kolana, a zatem łatwo było zostać przytłoczonym. Chociaż mogę już tam nie pracować, nie miałem dobrego rozwiązania, aby sprowadzić moją uwagę do kilku rzeczy, więc nie czuję się, jakbym próbował opanować 1000 rzeczy naraz. Jeśli znam kilka kluczowych rzeczy do zrobienia i sposób oceny mojej pracy, to jestem o wiele lepszy, niż jeśli mam listę „spraw do załatwienia” o długości mili i nikogo to nie obchodzi, jeśli dostanę części tego zrobione. Dlatego może się zdarzyć, że jest to element kulturowy w organizacji, ale ostrożnie prosiłbym o zmiany w tym miejscu.

Po dwóch latach pracy powinno być oczywiste dla wszystkich (Ciebie, Twojego szefa, kolegów), co do twojego stanowiska. Tj. Nigdy nie powinieneś dowiadywać się, że źle sobie radziłeś tylko raz w roku; idealne środowisko pracy zapewni ciągłe informacje zwrotne.

W każdym razie, jeśli chodzi o debugowanie kodu wielowątkowego: nie wspomniałeś, czy to jest twój kod, czy kod kogoś innego. Istnieje kilka nowych debuggerów i analizatorów statycznych, które mogą obsługiwać współbieżność. Ale tak naprawdę, znajomość wzorów będzie najlepszym wyborem, ponieważ będziesz wiedział, czego szukać.

Jeśli zrozumiesz, jak działają krytyczne odcinki, warunki wyścigu i impas, będziesz w lepszej pozycji, aby dostrzec rzeczy nieoczekiwane. Jeśli widzisz „komunikację” między dwoma wątkami bez zmiennych warunkowych lub jeśli zasoby są muteksowane bez określonej kolejności lub jeśli zmienna lokalna jest zadeklarowana staticbez wyraźnego powodu, oznacza to, że masz potencjalny błąd! Naucz się więc najlepszych praktyk w swojej dziedzinie, a będziesz w stanie lepiej oceniać, kiedy coś jest nietypowe.

Nie walcz sam, chyba że musisz. Rekrutuj kolegów. Poproś ich o pomoc w polowaniu na błędy. Zapytaj ich o ich proces myślowy i narzędzia. Być może wspomnij o tym w swojej recenzji w ramach planu ulepszeń. Jeśli wszyscy wokół ciebie radzą sobie lepiej w tym systemie , może wiedzą coś konkretnego?

Właśnie powiedział mi mój szef, że w poniedziałek otrzymam negatywną ocenę wydajności. Chce ze mną porozmawiać o tym, dlaczego jestem taki wolny i dlaczego mój wskaźnik naprawiania błędów jest tak niski.

Pamiętaj, że w żadnej niefunkcjonalnej firmie nic się nie dzieje na tym zamówieniu. Jeśli szef jest zaniepokojony twoimi wynikami, powinien wyznaczyć cele krótkoterminowe i porozmawiać o twoich wynikach, aby dowiedzieć się, gdzie leży problem.

Zamiast tego decyduje się na negatywną recenzję, a następnie dowiedzieć się, dlaczego. Wygląda na to, że nie chce angażować się w problem, a on chce tylko wyników w tabeli.

Nie staraj się szybciej rozwiązywać błędów. Postaraj się ocenić własne umiejętności, sprawdź, jak pracują twoi koledzy, skąd wiedzą, co wiedzą, i pamiętaj, że nie jest to idealna firma.

Jeśli chodzi o praktyczne wskazówki, używam fragmentów kodu i własnych mediawiki do robienia notatek. Zawsze myślę o tym, jakie książki przeczytać dalej i w jakim kierunku pójść, aby kontynuować naukę. Uczenie się jest drogą do lepszej pracy i szczęśliwszego życia.

Po pierwsze, zwiększenie pewności siebie:

Dlaczego cierpieć? Możesz łatwo znaleźć pracę, w której będą myśleć, że jesteś „bogiem” tylko dlatego, że możesz zrobić wszystko, co w Linuksie osadzone, bez względu na częstotliwość naprawiania błędów.

W każdym razie nie można ustalić limitu czasu na polowanie na błąd. Polowanie na owady to bez wątpienia umiejętność, a ich skuteczność jest bardzo cenna.

Być może brakuje ci podstawowej sztuczki, o której wiedzą inni, co spowalnia cię.

Na przykład, jeśli ty i ja pracujemy nad oprogramowaniem pośrednim dla Linuksa i używam Valgrind do znajdowania problemów z uszkodzeniem pamięci i wyścigów danych, podczas gdy ty polegasz tylko na gdb i printf, prawdopodobnie skopię ci tyłek, nawet jeśli jesteś mądrzejszy ode mnie.

Jak oceniasz współbieżność ? Jeśli rozwijasz się przez dziesięć lat, ale większość tego doświadczenia nie dotyczyła kodu wielowątkowego, może to stanowić problem.

Powinieneś dokładnie przestudiować wielowątkowość: więcej niż tylko umiejętność korzystania z interfejsów API, ale tak naprawdę „zdobądź” je na głębokim poziomie. Jeśli wykonujesz programowanie wielowątkowe, powinieneś być programistą, który może patrzeć na bazę kodów z odległości mili i dostrzegać scenariusze warunków wyścigu, impasu, priorytetowych inwersji, głodu ...

Niedawno przeczytałem książkę Efektywna praca ze starszym kodem i dało mi to znaczną pewność siebie przy rozwiązywaniu problemów w dowolnej bazie kodu.

Jeśli kod, z którym pracujesz, jest mniej niż doskonały, myślę, że ta książka byłaby pomocna. Przekonałem się, że często by naprawić błąd, muszę najpierw przefiltrować otaczający kod, aby go nawet zrozumieć , a potem, gdy zrozumiem kod, i mam nadzieję, że kod będzie testowalny, będzie śledził i naprawienie problemu jest mniejszym trudem. (Czasami przepisuję kod tylko po to, aby go zrozumieć, ale potem cofam moje zmiany, aby zmniejszyć ryzyko wprowadzenia nowych błędów. Następnie wstawiam poprawkę. Ta technika jest oparta na sztuczce z książki.)

Myślę, że moja sugestia odnosi się tylko do części twojego problemu, i to nieco pośrednio, ale książka jest warta przeczytania bez względu na wszystko, ponieważ praca ze starszym kodem jest nieunikniona dla każdego programisty.

Zapytaj swojego przełożonego, jaka jest twoja prędkość naprawiania błędów i jaka jest średnia szybkość naprawy błędów przez zespół. Co ważniejsze, zapytaj go, jak mierzona jest szybkość naprawiania błędów ...

To rodzaj metryki, tak naprawdę nie jest metryką; gdyby tak było, byłoby to jeszcze bardziej zawodne niż LOC (chociaż mierzenie różnych rzeczy). I bez odpowiedniego pomiaru nie ma powodu, aby cię o coś oskarżać.

Uznaj, że pracujesz u NIE dla pracodawców i / lub klientów. Nie wahaj się wspomnieć o tym w wywiadach, aby od samego początku ustanowić rekord.

Jesteś profesjonalistą, który dużo zainwestował w swoją małą firmę, a mianowicie siebie.

Jesteś gotów do pracy, gdy istnieje Związek Interesów wypychający cię z szafy każdego dnia.

Jeśli tego napędu nie ma przez dłuższy czas, to idź dalej.

Marnujesz swój czas i energię na nieprzyzwoitego pracodawcę, który nie utrzymuje twoich zainteresowań / aktualizuje umiejętności / zadania są trudne i / lub interesujące dla ciebie. To jest praca kierownictwa. Poza tym są czystym napowietrznym .....

Kontynuuj swoją pasję, bo to jest klucz.

Byłem w podobnych sytuacjach, ponieważ bałem się prosić o pomoc. Sądząc po tym, co powiedziałeś w tym komentarzu ...

„Ale frustrujące jest to, że istnieją pewne narzędzia / porady / sztuczki, których dowiedziałem się dopiero po półtora roku. Zostałem przeniesiony z zespołu do zespołu (wydaje mi się, że byłem mniej skuteczny) i odkrywam te „ukryte” narzędzia co jakiś czas ”.

... mogłeś mieć ten sam problem co ja. Debugowanie jest tak samo rzemieślnicze jak pisanie kodu, który nie wymaga tyle debugowania. Obserwowanie, jak inni deweloperzy pracują przez problem debugowania, może być bardzo pouczające. Poproś ich o pomoc, gdy masz problemy z rozwiązaniem problemu. Zwłaszcza jeśli kryjesz ziemię, której wcześniej nie miałeś. I zrób to idealnie, zanim nadejdzie czas na panikę, ponieważ nic nie można zrobić.

To powiedziawszy, zgadzam się z komentarzami, że kierownictwo robi coś złego. Jeśli ktoś ma z czymś problem, powinien uzyskać pomoc, zanim zacznie się negatywna recenzja zabawy. Do diabła, jeśli ktoś w zespole walczy i nigdy nie otrzyma pomocy, powiedziałbym, że każdy członek tego zespołu robi coś złego (chociaż może to być bezpośredni rezultat nadmiernego uważnego obserwowania błędów).

Brakuje w OP jakiejkolwiek wzmianki o powtarzalnym procesie lub metodzie, które są stosowane w celu usunięcia błędów.

Najpierw udokumentuj przebieg procesu. Należy udokumentować, co ma osiągnąć każdy etap procesu.

Możesz przedstawić proces jako taki:

1. Upewnij się, że dokładnie rozumiesz zgłaszany problem.
2. Spróbuj odtworzyć problem.
3. Zacznij rozkładać problem na mniejsze części
4. Pomyśl o możliwych przyczynach problemu.
5. Sprawdź te hipotezy

Przydałoby się wiedzieć, czy błędy istniały od dawna, czy są wprowadzane wraz z ostatnimi zmianami. Jeśli błędy zostały wprowadzone w ostatnich zmianach, pomocne mogą być przeglądy kodu i / lub po prostu czytanie kodu tworzonego przez ludzi.

Myślę, że jeśli potrafisz jasno zdefiniować problem, na przykład: „Mam problem z hipotezami do przetestowania przy próbie rozwiązania błędów”, możesz uzyskać bardziej ukierunkowane porady.