Robię 4-5 razy więcej punktów fabularnych niż przeciętnie, ale produkuję błędy o połowę szybciej. Wykresy mówią, że to 2x więcej błędów, jak sobie z tym poradzić?

43

Dlatego ogólnie przyjmuje się, że programiści najwyższego poziomu mogą wytwarzać kod o rząd wielkości większy / lepszy niż ich bardziej przeciętni rówieśnicy.

Powszechnie przyjmuje się również, że częstotliwość błędów w kodzie jest stosunkowo stała dla programistów.

Zamiast tego mają na nią wpływ procesy używane podczas pisania kodu i po napisaniu kodu . (Jak rozumiem) Ludzie mają tendencję do popełniania błędów w dość stałym tempie - lepsi programiści zauważają ich więcej i szybciej je naprawiają.

  • Zauważ, że oba powyższe twierdzenia pochodzą z Code Complete autorstwa Steve'a McConnella - więc nie jest to kwestia różnych perspektyw.

Ostatnio zacząłem to widzieć w moim kodzie. Potrafię wydobyć około 4-5 razy więcej kodu niż wielu moich rówieśników (mierzonych przez punkty fabularne oszacowane przez zespół), o wyższej jakości (na podstawie wskaźników wydajności i liczby zmian wprowadzonych po odprawie). Ale wciąż popełniam błędy. Pomiędzy lepszymi testami jednostkowymi, lepszym zrozumieniem tego, co robi kod i lepszym okiem na problemy podczas recenzji kodu, nie produkuję 4-5 razy więcej błędów.

Nadal jednak produkuję około dwa razy więcej błędów wykrytych przez QA niż innych programistów w moim zespole. Jak można sobie wyobrazić, powoduje to pewne problemy z nietechnicznymi ludźmi wykonującymi pomiary metryczne (czytaj: mój szef).

Próbowałem wskazać, że produkuję błędy o połowę szybciej niż moi rówieśnicy (i naprawiam dwa razy więcej), ale jest to trudna sprzedaż, gdy są wykresy wskazujące, że produkuję dwa razy więcej błędów.

Jak więc poradzić sobie z faktem, że wzrost wydajności doprowadzi do zwiększenia liczby błędów?

Telastyn
źródło
27
Lub po prostu zwolnij, abyś mógł zrobić to dobrze.
Brandon
29
Z praktycznego punktu widzenia wydaje się, że zarabiasz więcej za unikanie błędów niż za generowanie kodu. Więc spędzaj 1/4 dnia na pisaniu kodu dla swojej firmy, a resztę dnia na pisanie kodu dla własnych pobocznych projektów. Zgodnie z ustalonym przez ciebie kryterium twój szef powinien cię kochać.
Rob
14
Nie do końca rozumiem, dlaczego nasza społeczność wydaje się bardziej świętować „szybkość” niż poprawność. I piszę „szybkość” w cudzysłowie, ponieważ jeśli musisz wrócić, aby to naprawić, to może nie jest to „szybkość”. Ostatecznie otrzymujesz wynagrodzenie za dostarczenie działającego oprogramowania. Jeśli pisząc kod szybciej niż przeciętnie, robisz błędy, pomijając testy lub nie rozumiejąc poprawnie wymagań, poświęć trochę czasu, który „poświęcisz” i wykorzystaj go do poprawy zrozumienia testów / wymagań (na przykład robisz to TDD?). Jak mówi wujek Bob, „jeśli chcesz iść szybko, idź dobrze”.
MichelHenrich
9
Sposób, w jaki to naprawiasz, polega na naprawianiu wskaźników.
Robert Harvey
24
@MichelHenrich: Jeśli produkuje błędy o połowę szybciej od swoich rówieśników, szybkość nie jest problemem; zarządzanie jest problemem. Czytasz te głupie wskaźniki w taki sam sposób, jak jego szefowie.
Robert Harvey

Odpowiedzi:

41

Myślę, że mieszasz swoje obawy. Po twojej stronie nie ma nic , co musisz zmienić.

Wydajność jest wskazówką, jak szybko projekt zostanie ukończony. Kierownicy projektów i wszyscy inni lubią wiedzieć, kiedy projekt zostanie zrealizowany. Wyższa lub szybsza wydajność oznacza, że ​​zobaczymy, że projekt zostanie zrealizowany wcześniej.

Wskaźnik błędów nie jest związany z produktywnością, ale raczej z rozmiarem projektu. Na przykład możesz mieć Nbłędy w Yliniach kodu. W obrębie tej metryki nie ma nic, co mówi (lub obchodzi!), Jak szybko napisane są te wiersze kodu.

Aby to połączyć, jeśli masz wyższą produktywność, tak, „zobaczysz”, że błędy są pisane szybciej. Ale i tak miałeś mieć taką liczbę błędów, ponieważ jest to związane z rozmiarem projektu.

Co więcej, wyższa produktywność oznacza, że ​​będziesz mieć więcej czasu na zakończenie projektu, aby wyłapać te błędy lub deweloper będzie szybciej znajdował błędy, które stworzyli. 1


Aby zająć się bardziej osobistymi aspektami pytania.

Jeśli twój szef bacznie obserwuje liczbę błędów, które produkujesz, a nie liczbę błędów, które popełnisz, sesja edukacyjna jest w porządku. Liczba utworzonych błędów nie ma znaczenia bez wskaźnika wsparcia.

Aby maksymalnie wykorzystać ten przykład, powiedz swojemu szefowi, że chcę podwoić twoje wynagrodzenie. Dlaczego? Nie stworzyłem absolutnie żadnych błędów w twoim projekcie i dlatego jestem znacznie lepszym programistą niż ty. Co? Będzie miał problem z tym, że nie stworzyłem ani jednego wiersza kodu na korzyść twojego projektu? Ach Teraz rozumiemy, dlaczego stawka jest ważna.

Wygląda na to, że Twój zespół ma dane do oceny błędów na punkt historii. Jeśli nic więcej, to lepsze niż mierzenie przez liczbę utworzonych błędów. Twoi najlepsi programiści powinni tworzyć więcej błędów, ponieważ piszą więcej kodu. Niech twój szef wyrzuci ten wykres lub przynajmniej rzuci za nim kolejną serię pokazującą, ile punktów fabuły (lub jakiejkolwiek wartości biznesowej mierzysz) obok liczby błędów. Ten wykres opowie dokładniejszą historię.


1 Ten szczególny komentarz przyciągnął o wiele więcej uwagi niż zamierzano. Więc bądźmy trochę pedantyczni (zaskoczenie, wiem) i skupmy się na tym pytaniu.

Podstawą tego pytania jest to, że menedżer patrzy na niewłaściwe rzeczy. Patrzą na surowe sumy błędów, kiedy powinni patrzeć na szybkość generowania w porównaniu z liczbą wykonanych zadań. Nie miejmy obsesji na punkcie mierzenia się z „liniami kodu”, punktami fabularnymi, złożonością lub czymkolwiek innym. To nie jest pytanie, a te obawy odwracają uwagę od ważniejszego pytania.

Jak wskazano w linkach PO, można przewidzieć pewną liczbę błędów w projekcie wyłącznie na podstawie wielkości samego projektu. Tak, możesz zmniejszyć tę liczbę błędów poprzez różne techniki programowania i testowania. Znów nie o to chodziło w tym pytaniu. Aby zrozumieć to pytanie, musimy zaakceptować fakt, że w przypadku projektu o określonej wielkości i metodologii rozwoju zobaczymy określoną liczbę błędów, gdy programowanie zostanie „zakończone”.

Wróćmy więc w końcu do tego komentarza, który niektórzy całkowicie źle zrozumieli. Jeśli przydzielisz dwóm programistom zadania o porównywalnej wielkości, programista o wyższym wskaźniku wydajności wykona swoje zadanie przed drugim. Bardziej produktywny programista będzie miał zatem więcej czasu na końcu okna programowania. Ten „dodatkowy czas” (w porównaniu z innym programistą) można wykorzystać na inne zadania, takie jak praca nad defektami, które będą przenikać przez standardowy proces programowania.

Musimy przyjąć OP na słowo, że są bardziej wydajni niż inni programiści. Nic w tych twierdzeniach nie sugeruje, że OP lub inni bardziej produktywni programiści są wulgarni w swojej pracy. Wskazanie, że błędów byłoby mniej, gdyby spędzili więcej czasu na tej funkcji lub zasugerowanie, że debugowanie nie jest częścią tego czasu rozwoju, pomija to, o co poproszono. Niektórzy programiści są szybsi od innych i wykonują prace porównywalne lub lepszej jakości. Ponownie zobacz linki, które OP podaje w swoim pytaniu.


źródło
43
„Mierzenie postępu programowania za pomocą linii kodu jest jak mierzenie postępu budowy samolotu według masy”. -Bill Gates
Neil
40
Świetne programy mogą w rzeczywistości generować więcej błędów niż przeciętny programista - ponieważ świetne programy zwykle pracują nad trudniejszymi problemami.
hlovdal
4
Błędy / K linii lub błędy / storypoint byłyby uczciwą stawką. Uciekłbym tak szybko, jak to możliwe, gdyby szef chciał użyć błędów / godzinę jako stawki.
Bart van Ingen Schenau
4
„Twoi najlepsi programiści powinni tworzyć więcej błędów, ponieważ piszą więcej kodu”. nie, powinny zapobiegać błędom lub kończyć więcej funkcji. Często oznacza to, że piszą mniej kodu, a nawet usuwają fragmenty kodu. (zapewne wiesz, że po prostu nie napisałem tego w ten sposób) Z pewnością w niektórych branżach, w których pracowałem (np. w przemyśle lotniczym i jądrowym) jedynym kodem, który się liczy, jest kod, który okazał się mieć zero wad. Wszystko inne to hałas.
Pete Kirkham
4
„Jeśli już, wyższa produktywność oznacza, że ​​pod koniec projektu będziesz mieć więcej czasu na wyłapanie tych błędów, w przeciwnym razie deweloper szybciej znajdzie błędy, które stworzyli”. - Myślę, że jest to fałszywe i wymaga bardziej uważnej anaylsis. Mówiąc inaczej: gdyby poświęcił więcej czasu na każdą funkcję, tak, miałby mniej czasu na zmiażdżenie błędów. Ale byłoby też mniej błędów do zgniecenia.
Occulus
21

Poświęć trochę dodatkowego czasu na czyszczenie, polerowanie i testowanie kodu. Nadal będą błędy, ale będzie ich mniej. To wymaga czasu. Twój wskaźnik wyjściowy kodu spadnie, ale Twój wynik bezbłędny wzrośnie, co przełoży się na lepszą wydajność. Ponieważ błędy są drogie.

Czy potrafisz trzymać kod w oddziale lub środowisku testowym, dopóki go nie przekopiesz i nie złapiesz więcej błędów? Błędy w gałęzi generalnie powodują mniej fal niż błędy w kodzie produkcyjnym.

Ale nie do końca przekopuję twoje twierdzenia, prowadząc do twojego pytania. Być może twój szef też nie jest.

Nie sądzę, że każdy koder powoduje taki sam poziom błędów. Twój drugi link jest w zasadzie całkowicie nie na temat, ponieważ porównuje różne języki, a nie różne poziomy umiejętności programisty. Kompletny kod wspomina o niektórych pomiarach z dużą próbką, które dotyczą procesu, a nie umiejętności programistów. A kiedy mówią, że kodery najwyższego poziomu produkują więcej / lepszy kod, oznacza to, że ma mniej błędów. Zależy od aplikacji. Tak, myślę, że to kwestia innej perspektywy.

Ostatecznie jednak, jeśli szef chce czystszego kodu, daj mu czystszy kod.

Philip
źródło
4
+1. Nie wiem, dlaczego druga odpowiedź ma tak wiele pozytywnych opinii. Wygląda na to, że już dobrze uzasadniłeś swojego szefa, a on nie słucha. Więc spędzaj więcej czasu na testowaniu, a mniej na „wypuszczaniu” wierszy kodu. Jeśli to nie w porządku, zmień pracę.
durron597
21

Wyjdę na kończynę i będę adwokatem diabła. Nie oznacza to, że nie sympatyzuję z twoją trudną sytuacją, ale cóż, moja sympatia ci nie pomoże. Pozwólcie, że dodam do perspektywy Philipa :

Twój szef dba o jakość produktu, częściowo dlatego , że jego nazwa i reputacja będą z nim związane. Częścią jakości jest postrzegana ilość błędów . Jeśli sprzedajesz niesamowite wiertło, które wierci cztery razy szybciej niż jakiekolwiek konkurencyjne wiertła, ale także psuje się dwa razy częściej, będziesz miał złą reputację. Nawet jeśli można argumentować, że wiertło działa lepiej, ludzie przyzwyczajają się do prędkości, ale zapamiętają awarie.

Z perspektywy czasu większości błędów można oczywiście zapobiec. Gdybyś tylko był trochę bardziej ostrożny, twój szef poczuje, możesz uniknąć tych problemów i wszelkich niezbędnych porządków. Z jego punktu widzenia jest to trywialna, sensowna rzecz, o którą należy zapytać, a wszelkie argumenty, które o to robisz, nie będą działać i sprawią, że będziesz wyglądać źle.

Nie może zmierzyć twojej najwyższej wydajności. Twierdzisz, że produktywność jest wyższa na podstawie weryfikowalnych danych, więc co sądzą o tym twoi koledzy? Czy zgadzają się, być może niechętnie, że jesteś bardziej produktywnym programistą, czy jesteś według ciebie sam? Zrobisz silniejszy punkt, jeśli będziesz popierać swoje twierdzenia innymi ludźmi.

To z perspektywy. Jak sobie radzisz z „naprawianiem” tej frustrującej sytuacji?

Zwolnij trochę. Wyraźnie wspomnij o tym, kto dystrybuuje zadania, które spróbujesz obniżyć wskaźnik błędów (*), aby nie zaskoczyły cię mniejsze spożycie. Jeśli już, spowolnienie zmniejszy liczbę błędów przypisanych do ciebie z powodu braku podaży.

(*) Istnieje różnica między, z jednej strony, uznaniem, że w twoim nazwisku występują błędy i że spróbujesz zmniejszyć tę kwotę, a z drugiej strony, przyznaniem, że masz za dużo błędów w swoim imieniu i powinieneś podjąć działanie.

Nie próbuj przekonywać swojego szefa, ponieważ to nie zadziała. Znów nie oznacza to, że musisz przyznać się do sedna; możesz przedstawić kontrapunkt i podtrzymać swoją opinię, nie odrzucając jego obaw. Ponieważ jeśli argumentujesz, o co ci chodzi i nie możesz w zadowalający sposób udowodnić swojej wyższej wydajności (a nawet jeśli możesz), ryzykujesz obrażeniem swoich kolegów lub pozornym lekceważeniem ich. Nie chcesz być tym facetem .

JvR
źródło
4
Moja ulubiona odpowiedź, a także najbliższa do punktu, który chciałbym dodać: jaka jest wartość ukończonej liczby punktów fabularnych i jaki jest koszt błędu dla firmy? OP może stwierdzić z tymi ważonymi priorytetami bossami, że w rzeczywistości bardziej produktywne jest tworzenie tylko dwa razy więcej kodu niż innych programistów, ale z dużo mniej wadami.
Neil Slater
2
Twoje zdanie na temat ćwiczenia zależy od wielu rzeczy. W szczególności jego cykl pracy. Jeśli wiertło działa 24 godziny na dobę, siedem razy w tygodniu i działa dwa razy szybciej, powinieneś BARDZO NAJMNIEJ zastanowić się nad wydajnością wiertła. Ponieważ jeśli kosztuje to mniej niż dwa razy więcej niż zwykłe wiertło i można go użyć, jest to lepsza wartość. Wiesz, ekonomia. Mówisz mu, by zastanowił się nad wartością jego pracy w porównaniu z jej kosztem. Jego stosunek kosztów do świadczeń jest dwa razy lepszy niż u jego rówieśników.
nomen
1
@nomen Och, ale zgadzam się: ludzie absolutnie powinni to wziąć pod uwagę. Ale czy oni?
JvR
20

Zakładając, że wyprodukujesz taką samą „ilość” kodu jak twoi koledzy w 20% ich czasu, możesz wydać 4 razy więcej na naprawdę debugowanie kodu i uczynienie go idealnym, co jeszcze bardziej zmniejszy twój wskaźnik błędów. Wtedy możesz nazwać się dobrym programistą.

Największe pytanie brzmi: dlaczego kodujesz 5 razy więcej niż inne, zamiast dążyć do jakości. Czy to jest coś, co dyktuje ci twoje ego, czy może twój szef cię zmusza?

Musisz także wziąć pod uwagę koszty naprawy błędu. Gdy znajdziesz go wcześnie, wciąż możesz znajdować się „wewnątrz” kodu, aby go szybko naprawić. Jeśli pojawi się dopiero po kolejnym miesiącu programowania, może być trudno znaleźć, a nawet zmusić cię do zmiany dużych części już zaprogramowanego kodu.

Wygląda na to, że masz umiejętności tworzenia kodu i możesz sprawić, że będzie to niesamowite, jeśli skupisz się na jakości zamiast na szybkości. Spróbuj przez chwilę, zgaduję, że ci się spodoba.

Następnym problemem jest zdobycie potwierdzenia (mówienie o pieniądzach) dla lepszej wydajności. Porozmawiaj z szefem i zapytaj go, jak postępować, w końcu to jego firma i pieniądze, a jeśli chce, abyś produkował mniej błędów, powinien również zdecydować, w jaki sposób to się stanie.

awsm
źródło
11
OP dostarcza 500% punktów historii pozostałych członków zespołu z 60% mniej wad na punkt historii, a ty chcesz zmienić sposób, w jaki on działa?
Justin
6
Największe pytanie brzmi: dlaczego kodujesz 5 razy więcej niż inni, zamiast dążyć do jakości [...] skupiasz się na jakości zamiast na szybkości ” - Zrobiłeś mi dzień, człowieku. Ktokolwiek poparł to: Proszę odrabiać podstawowe zadania matematyczne. Mówiąc wprost: natychmiast zatrudniłbym OP i odmówiłbym zatrudnienia ciebie.
JensG
1
Matematyka może się mylić, ale myślę, że to prawda. Wolę zatrudnić kogoś, kto dąży do wyższej jakości do pracy w mojej obecnej firmie. Potrzeby są jednak różne, szczególnie w zależności od branży i wielkości firmy.
Michael Durrant
1
Wolę zatrudnić kogoś, kto robi to, o co prosi jego szef, zamiast narzekać na to w Internecie. Czasami szef wie najlepiej.
Dawood mówi o przywróceniu Moniki
8

Deweloperzy mogą być bystrzy, a nawet genialni, z umiejętnością rozumienia i kodowania solo, nie będąc DOBRYMI programistami. Dobry programista tworzy wysokiej jakości pracę i ulepsza cały projekt.

Nie mówię, że to ty, ale jeden z najbardziej frustrujących programistów, z którymi kiedykolwiek pracowałem, napisał więcej kodu niż ktokolwiek w zespole, a mieliśmy dobrych ludzi w zespole. Śledziliśmy zatwierdzenia za pomocą oprogramowania rankingowego, więc dla niektórych osób była to prawie konkurencja. Wyrzucał pokosy kodu, pozostawiając za sobą dokumentację ZERO, nieprzeniknione lasy, i tak naprawdę utrudnił mi zrozumienie części własnego kodu (mogę to zrobić sam, dziękuję bardzo!). W końcu prawie wykoleił projekt, ponieważ stał się show jednoosobowym. Ludzie nie mogli za nim podążać. Nie byliśmy zsynchronizowani jako zespół. Kilka lat później przepisaliśmy niektóre z jego funkcji, aby odzyskać łatwość konserwacji.

Chciałem od niego zwolnić i spędzić więcej czasu: 1) Poprawić jakość bazy kodów 2) Komunikować się z zespołem 3) Pracować nad rzeczami, które pomogły innym, a także pomóc mu ukończyć funkcje / historie 4) Naprawianie robaki

Nie zgadzam się z pomiarem produktywności za pomocą wierszy kodu, ale jest to kluczowa miara. Czy twój licznik kodu zawiera komentarze? Jeśli tak, istnieje prosty sposób na utrzymanie wyjścia liniowego przy jednoczesnym zmniejszeniu „wskaźnika błędów”; po prostu zwiększ jakość i ilość pisanych komentarzy. Komentarze rzadko zawierają błędy (choć mogą) i ogólnie nie mamy wystarczającej jakości komentarzy. Ja nie akceptowanie kodu-inflację, ale akt komentowania jest jak mini przeglądu kodu, zmusza uważasz, Refactor i poprawić.

codenheim
źródło
1
Dobra uwaga. Nie zgadzam się na dodawanie komentarzy (ponieważ bardziej przejrzysty, czytelniejszy kod jest lepszy) i mierzymy według punktu kompletnego, a nie wierszy kodu. Wydaje mi się, że wykonuję z tym dobrą robotę (recenzje kodu pomagają ludziom wyjaśnić sprawę), ale daje +1, ponieważ na pewno nie wszyscy to robią.
Telastyn
1
Nie chcę dodawać komentarzy do puchu / płyty kotłowej. Właśnie założyłem, że jesteś jak większość z nas i nie komentujesz wystarczająco dużo. Tak, trzymaj się z dala od bezwartościowych komentarzy, szczególnie fantazyjnej sztuki ascii, chyba że jest to dobry humor :)
codenheim
4
Z mojego doświadczenia wynika, że ​​komentarze często zawierają błędy.
Dawood mówi, że przywraca Monikę
Nie funkcjonalny, mierzalny rodzaj ...
codenheim
6
@DavidWallace, według mojego doświadczenia kod często zawiera błędy. To nie znaczy, że przestajesz to pisać.
Charles E. Grant
4

Próba oświecenia zarządzania nie jest początkowa. Jest stary klisz: „Czy uwierzysz mi czy swoim kłamliwym oczom?” To, co dotyczy twoich szefów, to liczba błędów. Żadna racjonalizacja nie powie im, że jest to do przyjęcia. To ponad dwa razy bardziej ryzykowne. Ponadto nie tylko ty masz wpływ na liczbę błędów. Kontrola jakości ma dwa razy więcej pracy, niż próbowanie zidentyfikowania twoich błędów, więc zarząd będzie chciał, abyś robił ich mniej.

Najlepszym rozwiązaniem jest zmniejszenie liczby błędów, które produkujesz , kropka. Zarządzanie będzie nie tylko szczęśliwsze, ale i Ty. Nie ty Bo jestem całkiem pewny, jak lubisz chluby ty prześcignąć swoich współpracowników o współczynnik cztery, chcesz kochać znaczy zrobić to czyni tę samą liczbę, lub nawet mniej błędów niż robią.

Jak już wspomniałeś, „… na liczbę błędów popełnionych w kodzie… mają wpływ procesy stosowane podczas pisania kodu i po jego napisaniu”. Jeśli chcesz zmienić częstotliwość, z jaką produkujesz błędy, będziesz musiał zmienić procesy używane do pisania kodu.

Programiści używają metod produkcji do tworzenia kodu, podobnie jak linia montażowa używa metod do produkcji masowo produkowanych obiektów. Okej, praktyki branży oprogramowania są bardziej jak drobne bibeloty z gałęzi znalezionych w lesie. Ale ponieważ produkujemy maszyny, powinniśmy stosować ten sam rygor i dyscyplinę, co w przypadku szybkich maszyn masowej produkcji.

Obejmuje to te same techniki, które są stosowane w masowej produkcji w celu zmniejszenia wskaźnika defektów: analiza przyczyn źródłowych w celu ustalenia, dlaczego błędy są robione, i zmiana procesu, aby nie były. A przynajmniej złapiesz, zanim zrobi to kontrola jakości.

  1. Zrób listę swoich błędów. Prawdopodobnie masz już jeden dzięki chłopakom z QA. Prawdopodobnie też podzielone na kategorie. Rodzaj błędu, ważność, punkt, w którym błąd został wstrzyknięty do kodu itp.

  2. Wybierz największą kategorię błędów. Ponieważ Twój wolumen jest tak wysoki, najpierw powinieneś wybrać tę kategorię. Inne kategorie obejmują te najłatwiejsze do znalezienia i te najłatwiejsze do wykonania.

  3. Wiedząc, gdzie te błędy są wprowadzane do kodu, przyjrzyj się wprowadzaniu zmian na tym etapie (i wcześniejszych), które zapobiegną występowaniu tych błędów, oraz sposobom na łatwiejsze ich złapanie na tym etapie.

  4. Pamiętaj, aby zapoznać się z przypadkami niezwiązanymi z programowaniem, ponieważ mogą one mieć wpływ na jakość Twojej pracy. Muzyka w tle, przerwy, posiłki, zbyt długa praca bez przerwy, głód itp.

To, co znajdziesz, może spowolnić. Z drugiej strony może pomóc Ci produkować jeszcze szybciej, ponieważ będziesz musiał mniej przerabiać rzeczy, które już masz za sobą. W rzeczywistości czterokrotnie więcej kodu nie jest bliskie bycia o rząd wielkości lepszym od współpracowników, więc zmiana procesu jest zdecydowanie najlepszym rozwiązaniem.

Huperniketes
źródło
3

Zmień swój cel, od produkowania największej liczby kodów do pomocy firmie w dalszym rozwoju.

Ponieważ wygląda na to, że masz wielu współpracowników i dodatkowy czas, największy wpływ na szybsze dostarczanie funkcji i poprawianie błędów ma pomoc kolegom.

Pomóż swoim kolegom przez

  • korzystanie z recenzji kodu w celu poprawy jakości kodu i edukacji.
  • tworzenie automatyzacji procesów, aby ich praca była szybsza, a ich życie łatwiejsze.
  • pisząc z nimi lepsze testy
  • atakowanie kodu technicznego w celu ulepszenia bazy kodu
  • bycie facetem, który jest zawsze dostępny, aby pomagać innym.
  • pisanie / ulepszanie narzędzi, które pomagają zwiększyć produktywność programistów
  • uzasadnienie zarządzania lepszymi narzędziami / sprzętem / warunkami pracy dla współpracowników, jeśli masz więcej siły.
  • przygotowywanie i prowadzenie sesji edukacyjnych na temat pisania lepszego kodu.
  • praktykowanie pokory
Michael Durrant
źródło
1

Jak więc poradzić sobie z faktem, że wzrost wydajności doprowadzi do zwiększenia liczby błędów?

Twój szef jest jedyną osobą, która może odpowiedzieć na to pytanie w twoim przypadku. Porozmawiaj z nim, wskaż lepszy stosunek i pozwól mu zdecydować. Jeśli jego decyzja nie ma sensu, nadszedł czas, aby poszukać firmy o swoim sposobie myślenia.

Jako profesjonalista powinieneś być w stanie pracować z dowolnymi warunkami klienta, po prostu upewnij się, że rozumieją konsekwencje. Ładna tabela błędów / historii może pomóc twojemu szefowi zrozumieć, ile spadnie twoja produktywność, jeśli poświęcisz trochę czasu na wyprodukowanie mniej błędów.

Musisz także wziąć pod uwagę następujące punkty:

  • złożoność historii, na przykład proste owijarki getter / setter kontra obliczenia statystyczne lub programowanie w czasie rzeczywistym, a nawet statystyki w czasie rzeczywistym ...
  • dotkliwość błędów, czy to małe literówki na polach tekstowych lub błędne wyniki obliczeń, program ulega awarii
  • koszt naprawy błędów, zarówno jeśli robisz to teraz, później, jak i jeśli ktoś inny musi zrozumieć Twój kod, ponieważ odszedłeś
Marten Storm
źródło
0

Sytuacja polega na tym, że pracujesz cztery razy szybciej niż przeciętny programista, ale popełniasz dwa razy więcej błędów w danym czasie. W stosunku do ilości pracy, którą wykonujesz, w rzeczywistości popełniasz PÓŁ błędów tyle, ile „przeciętnych”.

Możesz spróbować wskazać swoje niskie błędy w stosunku do pracy, a nawet błędy w gotowym produkcie (które możesz wykonać w jednej czwartej normalnego czasu). Większość szefów to zaakceptuje.

Jest kilku bossów, którzy tego nie zrobią, ponieważ pracują z umysłem „tolerowania” błędów na raz. Następnie możesz spowolnić tempo pracy, wykonując dwa razy więcej pracy niż przeciętnie w danym czasie i popełniając te same (lub mniej) błędy, ponieważ masz więcej czasu na sprawdzenie swojej pracy.

Tom Au
źródło
0

Jeśli twój szef chce, abyś poprawił jakość swojej pracy, to popraw jakość swojej pracy.

Powinieneś dążyć do zera błędów, a nie produkować tylko dwa razy więcej niż kolejny najlepszy programista.

Dawood mówi, że przywraca Monikę
źródło
6
Zero błędów jest w dużej mierze nieosiągalnym celem, który często nie jest opłacalny.
Telastyn
7
To nie jest wymówka, aby nie zmniejszać wskaźnika błędów. Jeśli twój szef chce, abyś tworzył lepszy kod, to nadszedł czas, aby stworzyć lepszy kod, a nie wymyślać tego.
Dawood mówi, że przywróć Monikę
4
Powiedziałem tylko, że powinieneś dążyć do wyeliminowania błędów, a nie, że musisz to osiągnąć. Pomyśl o łucznictwie. Nie jestem dobry w łucznictwie - nigdy nie trafiłem „10” w środku celu. Czy powinienem celować w pierścień „7”, ponieważ „10” byłoby zbyt trudne?
Dawood mówi, że przywraca Monikę
6
Tak, ale twój szef mówi, że twoja praca NIE jest „wystarczająco dobra”. Innymi słowy, powinieneś zrobić lepiej. Nie podałeś żadnego dobrego powodu, dla którego nie możesz zrobić lepiej. Cała ta dyskusja brzmi dla mnie jak ktoś, kto próbuje usprawiedliwić się produkcją kodu, który zawiera błędy. „Jestem w zespole bardzo powolnych programistów i dlatego muszę popełniać dwa razy więcej błędów niż wszyscy inni”. Proszę!
Dawood mówi, że przywrócenie Moniki
3
W każdym cyklu wydawniczym produkujesz dwa razy więcej błędów niż twoi rówieśnicy. Błędy są drogie do znalezienia i drogie do naprawienia. Twój szef musi więc przeznaczyć środki na rozwiązanie swoich błędów; i to dwa razy więcej w przypadku błędów niż w przypadku błędów następnego faceta. Dlatego twój szef chce, abyś produkował mniej błędów, niezależnie od tego, co robią reszta twojego zespołu. Może wie, że masz więcej doświadczenia niż reszta zespołu, i dlatego powinien być w stanie produkować mniej błędów. W każdym razie nie rozumiem, dlaczego narzekasz na szefa, który chce, abyś produkował mniej błędów.
Dawood mówi, że przywrócenie Moniki
0

Powinieneś powiedzieć swojemu szefowi, że mierniki, których używa, są dość wadliwe. Jeśli spojrzysz na obroty strażników w NBA, przekonasz się, że mają oni zwykle większą liczbę niż napastnicy. Ale to dlatego, że lepiej trzymają piłkę. Jeśli nierozstrzygający strażnik zagrywa 1/5 tyle co strażnik początkowy i obraca piłkę ponad 3 razy średnio .vs. Strażnik początkowy, który obraca piłkę ponad 7 razy na mecz - na pierwszy rzut oka może się wydawać, że gorszy jest Straż początkowa. Ale jeśli podzielisz liczbę obrotów przez liczbę rozegranych minut, to wyraźnie, że początkowy strażnik ma znacznie lepsze liczby na podstawie rozegranych minut.

Podobnie, masz znacznie lepsze liczby, jeśli liczba błędów jest podzielona przez liczbę ukończonych punktów opowieści. Tak właśnie chciałbym zaproponować twojemu kierownikowi. Zmień metrykę na liczbę błędów podzieloną przez ukończone punkty historii lub przynajmniej dodaj nową metrykę, jeśli potrzebna jest całkowita liczba błędów na programistę. Ale ponieważ niektóre punkty opowieści są znacznie trudniejsze i bardziej złożone niż inne punkty opowieści, może i będzie istniała dość duża wariancja, co również musi zostać wzięte pod uwagę przez kierownika.

To, co nie uważam, że powinieneś zrobić, to zwolnić.

Bob Bryan
źródło
0

Zmierz wartość dodaną

Argumentuj, że tak naprawdę liczy się wartość, którą dodajesz. Następnie idź i wprowadź przybliżony (ręczny) pomiar tego:

  • Oszacuj wartość produkowanej funkcjonalności
  • Odejmij swoją pensję
  • Odejmij szacunkowy koszt swoich błędów (przynajmniej koszt ich naprawy)
  • Odejmij szacunkowy koszt wszystkich innych zadłużeń technicznych, które produkujesz

Pozostała część stanowi twoją wartość dodaną. Podobnie dla wszystkich innych.

Szacunki te są trudne, ale nawet przybliżone mogą mieć sens. Sam proces omawiania tych szacunków jest przydatny dla zespołu i projektu.

Lutz Prechelt
źródło
-1

Najlepsi programiści mają tendencję do pisania bardzo regularnego kodu, który jest łatwy do debugowania i zrozumienia, wykorzystują dostępne narzędzia (analiza statyczna, błędy kompilatora, kod debugowania) do maksimum. Również najlepsi programiści już nauczyli się wartości testowania jednostkowego poprzez swoje własne trudne doświadczenie.

Więc chociaż początkowa liczba problemów na linię jest taka sama, problemy są usuwane szybciej.

zzz777
źródło
pytanie wskazuje, że to nie pomaga: „Próbowałem wskazać, że produkuję błędy o połowę szybciej niż moi rówieśnicy (i naprawiam dwa razy więcej), ale trudno sprzedać, gdy są wykresy z informacją, że produkuję dwa razy więcej błędów ... ”
komiks
To jest względne i raczej subiektywne, prawda? Nie wiem, co oznacza „zwykły” kod. Twierdziłbym, że najlepsi programiści próbują wykorzystać wszystkie dostępne biblioteki i konstrukcje językowe, aby uzyskać jak największe korzyści pod względem wydajności i ekspresji, co powinno uczynić kod bardzo łatwym do zrozumienia dla innych dobrze funkcjonujących programistów ... być wyjątkowo trudnym do zrozumienia dla młodszych i średnio zaawansowanych programistów, szczególnie tych, którzy nie są zaznajomieni z bardziej zaawansowanymi koncepcjami architektonicznymi, przepływem sterowania, strukturami danych ...
Aaronaught
IMHO, wielkość określa wieloletnia historia, a 90% żyjących inżynierów oprogramowania nigdy nie miało okazji poznać wielkich. Próbowałem podsumować swoje wrażenia z dwóch świetnych programistów, z którymi pracuję. „Zwykły” kod oznacza: (a) te same czynności są wykonywane w ten sam sposób w całym produkowanym kodzie, (b) łatwo jest zinterpretować modyfikację, i (c) jest zdecydowanie przeciwny do „łatwego do zrozumienia przez inne wysokie działający programiści ... ”.
zzz777