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

129

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.

BeeBand
źródło
170
Poinformuj swojego szefa, że ​​naprawdę miło z jego strony, że zaoszczędził na swojej recenzji zamiast wspominać o tym, gdy zauważył, że to problem.
Blrfl
13
Programowanie konserwacji wymaga określonego rodzaju osoby. Może to nie twoja sprawa. Podobnie nowy rozwój wymaga jeszcze jednego rodzaju osoby. Mówisz o odkrywaniu narzędzi / wskazówek / sztuczek. Ile z tych narzędzi stworzyłeś na własny użytek? Jeśli odpowiedź jest przecząca, to naprawdę uważam, że nie jesteś typem osoby zajmującej się programowaniem konserwacji. Jeśli toczysz się między wieloma projektami z powodu braku wydajności, weź to jako jasny komunikat, że nie masz kwalifikacji na zajmowane stanowisko. Znajdź coś bardziej odpowiedniego dla siebie.
Dunk
40
Jeśli musisz zgadywać , że jesteś tasowany ze względu na swoją wydajność, zarząd robi coś złego. Podobnie, jeśli po raz pierwszy usłyszysz o swoich gorszych wynikach po 2 latach, zarząd robi coś złego.
Michael Shaw,
32
@Bee: Zazwyczaj, gdy ktoś otrzyma kiepską recenzję, czas odejść. Mogą wystawić cię na „program rozwoju pracowników”, ale nie sądzę, żebym kiedykolwiek widział, jak ktoś wyzdrowieje po osiągnięciu tego etapu. Najłatwiej jest znaleźć pracę, kiedy już ją masz. Gdybym był tobą, zaktualizowałbym moje CV i wkrótce zacznę szukać gdzie indziej. Powinieneś także bardzo uważać na rodzaj wykonywanej pracy. 7 lat doświadczenia wciąż pozostawia wiele opcji. Gdy osiągniesz 10, firmy będą oczekiwać specjalistycznej wiedzy w poszczególnych obszarach. Wybierz obszar, który ci się podoba i jesteś dobry. Ups, właśnie widziałeś, że trafiłeś już 10.
Dunk
8
Nie wystarczy, aby być odpowiedzią, ale odnośnie „sposobu na przyspieszenie”: twierdzisz, że jest to domena, w której jesteś nowy. Może to być sposób, w jaki naprawiasz to zbyt wiele prób i błędów, nie bardzo wiedząc, co się dzieje "głęboko"? W takim przypadku dokładne poznanie podstaw pomoże lepiej dostrzec potencjalne problemy.
Matsemann

Odpowiedzi:

80

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ę!

kmote
źródło
2
co za wspaniała odpowiedź. myślę, że wszystkie twoje punkty odnoszą się do mnie (a jeśli chodzi o # 1, być może jestem mniej inteligentny, słyszę, że istnieją różne rodzaje inteligencji - więc może to jest związane z # 4. może jestem odrętwianym wbudowanym devem linux dev ale może jestem lepszy w materiałach internetowych ... a teraz myślę o tym, to może być realistyczne). tak czy inaczej - jesteś bardzo spostrzegawczy.
BeeBand
14
3 i 4 są większe (dla programistów), niż większość szefów może sobie wyobrazić. Jeśli programista ma niskie morale, nie może skoncentrować się na pracy. Dla programisty morale jest pędem, a pęd jest wszystkim.
TimG
7
Doskonała odpowiedź. Debuguj się to świetne zdanie, btw. Chciałbym móc jeszcze raz cię za to głosować.
Kyeotic,
2
Twoje „poszło za nim” nie działa w punkcie 1, ponieważ paradoks przyjaźni modeluje relacje między dwojgiem ludzi jako prostą dwukierunkową przewagę między dwoma wierzchołkami na wykresie, podczas gdy wykres tego, kto jest „mądrzejszy”, niż kto musiałby rozważyć szeroki wachlarz innych czynników, nie wspominając o tym, że nie obowiązują zasady przechodniości. Zgadzam się z punktami 2, 3 i 4. W przypadku PO myślę, że jego szef jest dupkiem, który cierpi z powodu efektu ogłuszenia-kruegera.
funkymushroom
1
programista, debuguj siebie. uwielbiam to :) również dobra odpowiedź. użyteczne dla mnie, nie dlatego, że jestem w takiej sytuacji, ale dlatego, że widzę, jak tego uniknąć. +1
jammypeach
56

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 ...

Tone
źródło
2
to świetna odpowiedź. Zastanawiam się, dlaczego nie lubię tej pracy. Głównie są to pliki dziennika, które nam podają, aby towarzyszyć błędom, zacząłem ich nienawidzić bardziej niż ktokolwiek inny - zawsze zaczynam całkowicie i całkowicie po ciemku z każdym błędem, który mi dają. Myślę, że nienawidzę tego „w ciemności”.
BeeBand
4
O ile nie wystąpił podobny problem w tym samym projekcie, większość ludzi zaczyna „w ciemności”, kiedy dostaje nowy błąd. Następnie na podstawie symptomów zastanawiasz się, jak odtworzyć problem, który powinien dać ci pomysły, od czego zacząć zgadywać przyczynę problemu. Kontynuujesz krok po kroku. Nic magicznego, nic do nienawidzenia. Mówisz, że nienawidzisz plików dziennika. Czy stworzyłeś sobie jakieś narzędzia do automatyzacji analizy tych plików dziennika? Ignorując fakt, że pliki dziennika powinny się przydać, gdyby nie były, nie musiałbym długo czekać, aż stworzę narzędzie, które pomoże mi je przeanalizować.
Dunk
1
@Dunk tak Stworzyłem narzędzie do analizy plików dziennika na różne sposoby. Dowiedziałem się później, że ktoś stworzył już jakiś rok temu.
BeeBand
@Bee: Utworzenie narzędzia pokazuje wymaganą inicjatywę. Czy nikt nie przedstawia przeglądu środowiska programistycznego podczas przechodzenia między projektami? Jeśli narzędzia istnieją, to z pewnością wydaje się, że kierownik projektu powinien cię o nich poinformować.
Dunk
Przegląd @Dunk ponownie - nie. Mój pierwszy kierownik zespołu pokazał mi szczególne narzędzie - ale nie wskazał, że jest przydatne do naprawiania błędów określonego rodzaju lub że może to przekładać się na inne projekty. Kiedy zostałem przeniesiony do tego nowego projektu konserwacji, nikt nie rozmawiał ze mną przez środowisko programistów - musiałem tylko zapytać. Dopiero po staraniach o zbudowanie własnego narzędzia poprosiłem kolegę, który wspomniał, jak mogę korzystać z oryginalnego narzędzia. (Uwaga: jest to inne narzędzie niż mój poprzedni komentarz).
BeeBand
38

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.

naftalimich
źródło
2
W mojej karierze zawodowej widziałem zespoły dokładnie takie, jak opisałeś. Kod, który przechowują, jest rozległy i tajemniczy, a informacje o tym, jak działa, są zazdrośnie strzeżone. Nowi członkowie zespołu celowo są pozostawieni samym sobie i ostatecznie przenoszą się, aby ocalić swoją karierę.
Anthony Giorgio
31

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

Mathew Foscarini
źródło
11
To nie jest nielegalne, aby dać negatywne opinie wydajności, ale nie muszą być obiektywne i uzgodnić realne kryteria pracy i wspierać cię.
pjc50
9
Pomyślałem, że może przesadzam, kiedy opublikowałem tę odpowiedź, ale przeczytanie twojego wpisu rezonowało z moimi własnymi doświadczeniami. Naprawianie błędów nie jest czymś, co można zmierzyć w kontekście wydajności. Spędziłem 3 miesiące raz, aby naprawić pojedynczy błąd. Zwykle sprytni faceci dostają poważne błędy.
Reactgular
9
Nie mam prawa głosować, ponieważ nie widzę dowodów na to, że jesteś prawnikiem i twierdzę, że udzielam porady prawnej. Ponadto, jeśli inni pracownicy naprawiają błędy X średnio miesięcznie, ale PO naprawia X / 10, jest to absolutnie obiektywne i rozsądne.
Andy,
7
@Dziękuję, że podzieliłeś się opinią o tym, dlaczego głosowałeś. Zgadzam się, że wskaźniki naprawy błędów są wskaźnikiem, ale co jest obiektywne w informowaniu kogoś w piątek, że ma negatywną opinię w najbliższy poniedziałek. Poza taktownym zmuszaniem ich do pocenia się w weekend. Czy nie jest bezpiecznie zakładać, że pożądanym rezultatem byłoby to, że pracownik nie pojawi się w poniedziałek w celu dokonania przeglądu? Czy nie klasyfikuje się to jako konstruktywne zwolnienie? Mam nadzieję, że mogę zmienić twoją perspektywę, ponieważ konstruktywne zwolnienie jest ciągłym problemem w naszej branży.
Reactgular
7
W żaden sposób sędzia nie uznałby, że jest to konstruktywne zwolnienie. Możesz obezwładniać literę prawa, ale ten rodzaj prawa istnieje w przypadkach, gdy pracownik jest nękany lub molestowany, sytuacja jest aktywnie wroga. W oparciu o to, co mówi OP, zostali poinformowani, że dostają negatywną recenzję, ponieważ s / on nie kumuluje się z rówieśnikami, jeśli chodzi o wskaźnik naprawiania błędów; to trudna sytuacja, ale nie jest ona wroga i na pewno nie jest nielegalna. Być może szef mógł być bardziej taktowny, ale opinie nie muszą być ograniczone do oficjalnych recenzji wyników
pdubs
26

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!

Zan Lynx
źródło
3
To fantastyczna odpowiedź. Jestem pod wielkim wrażeniem.
Daniel Hollinrake
26

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.

zwol
źródło
4
„Debugowanie jest dwa razy trudniejsze niż pisanie kodu”. - Brian Kernigan (ojciec C, UNIX)
TimG
4
@TimG: I jak każdy inny programista, Kernigan nie doceniał trudności.
mu jest za krótki
Wow, chciałbym zaznaczyć, że to jest naprawdę trudne pytanie i jestem naprawdę zaskoczony, widząc tutaj tak dobrą i wnikliwą odpowiedź. Dzięki.
maksymko
12

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.

JB King
źródło
2
ended up getting micromanaged until I was terminated- Cóż, właśnie spojrzałem na twój profil SO i wyraźnie się od niego wycofałeś, więc uważam, że twoja reakcja jest pocieszająca. Opowiem o twoim pierwszym punkcie w poniedziałek - otrzymuję błędy z bardzo różnych obszarów.
BeeBand
10

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.

chrisaycock
źródło
2
tak, to nie jest mój kod - to rozległy, rozległy system osadzony, po raz pierwszy zaprojektowany 10 lat temu. Myślę, że masz rację co do wzorów - muszę wrócić do podstaw.
BeeBand
1
@BeeBand dobrze byłoby wiedzieć, jak się masz. Mam nadzieję, że wszystko się ułoży.
Daniel Hollinrake
10

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?

pjc50
źródło
Byłoby interesujące wiedzieć, czy BeeBand już to zrobił. Po przeczytaniu komentarzy i odpowiedzi wydaje się, że jest to dość nieprzyjazne środowisko.
Daniel Hollinrake
1
Cóż, mogę z tym współczuć. Wiem, jak to jest być w firmie, w której zespół programistów pada śnieg z pracą. Na szczęście, chociaż w moim przypadku współpracuję z kilkoma świetnymi kolegami i uważamy na siebie. Czy jest ktoś, z kim możesz się sparować? Czas spędzony na szkoleniu i zwiększaniu produktywności zwróci się dla wszystkich. Od dźwięków, na których Ci zależy i które są sumienne, aby Twoja firma skorzystała na utrzymaniu Ciebie.
Daniel Hollinrake
8

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.

użytkownik2106285
źródło
7

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 ...

Kaz
źródło
1
Największy problem ze współbieżnością polega na tym, że o wiele łatwiej jest pisać kod bez błędów niż naprawiać błędy w błędnym kodzie. Zwłaszcza jeśli kod jest prawie poprawny. A błędy zwykle nie są w jednym miejscu, ale są rozpowszechniane w wielu.
gnasher729
5

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.

Jason Swett
źródło
Obecnie czytam to na twoją rekomendację.
BeeBand
3

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ć.

m3th0dman
źródło
Przypuszczalnie jest to mierzone jako problemy zamknięte / jednostka czasu . Rozsądne może być powiedzenie „cóż, niektóre błędy zajmują więcej czasu niż inne”, ale jeśli OP nie działa w szczególnie trudnej części kodu, a wszyscy inni robią łatwe rzeczy, to prawdopodobnie nie utrzyma wody.
Caleb
3

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.

dennisk1718
źródło
2

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).

Erik Reppen
źródło
2

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.

dcaswell
źródło