Tłumaczenie maszynowe. Przeczytaj angielski oryginał: Your performance review is a memory test →
Zapytaj dowolnego menedżera inżynierii, kto jest ich najlepszym inżynierem. Zobacz, jak szybko pada odpowiedź. Nie ma wahania, żadnych zastrzeżeń, żadnego „niech najpierw coś sprawdzę”. Oni wiedzą. Zawsze wiedzieli.
Teraz poproś ich, aby pokazali tę pracę. Otrzymasz historię. Dobrą historię, zazwyczaj o incydencie, który ktoś obsłużył o 2 w nocy, albo refaktoryzacji, która odblokowała kwartał, albo o osobie, która zawsze odpowiada na kanale. Czego nie dostaniesz, to liczby, porównania ani żadnego opisu czterech inżynierów, których pracy menedżer nie był świadkiem. Pewność nigdy nie opierała się na pomiarach. Opierała się na zapamiętaniu, a zapamiętanie jest funkcją bliskości.
Oto teza, a wszystko po tym jest jej dowodem. Wydajność inżynieryjna jest oceniana z pamięci, pamięć nagradza widoczność, a nie wartość, a to, co naprawdę chcesz, aby ludzie budowali, jest zapisane w roadmapie, który nigdy nie jest powiązany z tym, za co ich oceniasz. Te dwa dokumenty – roadmap i ocena wyników – nie mają ze sobą nic wspólnego w prawie każdej firmie, jaką widziałem, w tym w mojej do niedawna.
Więc połączyliśmy je. Każde scalone żądanie pull request jest odczytywane przez model, przypisywana jest mu waga i mnożona przez to, jak bardzo nasz roadmap dba o komponent, którego dotyczy. Rezultatem jest miesięczna tabela liderów, która wpływa na decyzje o premiach.
Pokażę wam naszą, włączając w to części, w których jest żenująca i w których jest błędna.
Przyjęta mądrość mówi, że tego nie da się zmierzyć, a przyjęta mądrość to wzruszenie ramion
Standardowe stanowisko w kwestii mierzenia indywidualnej wydajności inżynieryjnej jest takie, że nie należy tego robić, ponieważ każdy wskaźnik zastępczy jest pułapką. Liczba linii kodu nagradza rozdęcie. Liczba commitów nagradza dzielenie. Story points to negocjacja, a nie pomiar. Nawet dobre frameworki są celowo na poziomie zespołu: DORA mierzy cztery rzeczy dotyczące potoku dostarczania i nie mówi nic o ludziach, co jest świadomym wyborem projektowym, o którym autorzy mówią wprost.
Wszystko to jest prawdą, ale żadne z tego nie jest odpowiedzią. Odmowa mierzenia nie tworzy firmy, w której nikt nie jest oceniany. Tworzy firmę, w której wszyscy i tak są oceniani, za pomocą mechanizmu bez śladu audytu. Ranking nadal ma miejsce przy okazji ustalania wynagrodzeń. Po prostu odbywa się w pokoju, z pamięci, z wagą uzależnioną od tego, z kim osoba w pokoju spędziła najwięcej czasu.
Nazwijmy to premią głośnego inżyniera: różnica między tym, jak dobrze jesteś oceniany, a tym, jak dobrze pracowałeś, wyjaśniona całkowicie przez twoją odległość od osoby piszącej twoją ocenę. To nie jest wada charakteru menedżerów. To przewidywalny rezultat proszenia człowieka o porównanie wkładu technicznego piętnastu osób na przestrzeni roku, używając tylko tego, co akurat zauważył.
Premia była nieunikniona do około dwóch lat temu, ponieważ surowy materiał do lepszej odpowiedzi stanowiła sterta diffów, których nikt nie miał czasu przeczytać. To ograniczenie zniknęło. Model może przeczytać każdy diff w twoim repozytorium co miesiąc za mniej niż koszt jednej godziny spotkania, na którym obecnie zgadujesz.
Przeczytanie ich to łatwa część. Zdecydowanie, ile to czytanie jest warte, to cały problem, i to nie jest pytanie techniczne.
Cały wzór mieści się w jednej linii
Oto on, w całości, ze ścieżki punktacji w GitRank:
final_score = is_eligible ? severity_base_points × component_multiplier : 0To nie jest uproszczenie na potrzeby bloga. To jest ta linia. Nie ma ukrytej regresji, żadnego wyuczonego ważenia, żadnego terminu reputacji, żadnej korekty stażu. Waga razy ważność, albo zero.
Krytyczna poprawka jest warta dwadzieścia niskopriorytetowych. Ten stosunek to deklaracja polityki, i zapisaliśmy ją, zamiast zostawiać w czyjejś głowie.
Połowa ważności to część, która naprawdę ma znaczenie, i to jest powód, dla którego myślę, że to podejście się uogólnia. Każdy komponent w repozytorium ma mnożnik, a mnożnik jest ustawiany na podstawie tego, czego produkt potrzebuje w tym kwartale:
Chat ma 2.0x, ponieważ chat to to, na co stawiamy w produkcie. Authentication ma 1.0x, ponieważ działa i chcielibyśmy, aby działało dalej po cichu. Funkcje współpracy i podświetlanie dokumentów mają 2.0x z tego samego powodu co chat. Żadna z tych liczb nie jest oceną techniczną. To roadmap, przepisany na pole, które płaci.
To jest ten ruch. Nie model, nie tabela liderów, nie grywalizacja. Ruch polega na tym, że dokument strategiczny i wkład do wynagrodzeń stały się tym samym dokumentem. Jeśli roadmap zmieni się w październiku, mnożniki zmieniają się w październiku, a zachęta zmienia się w październiku, a nie w następnym cyklu rocznej oceny za czternaście miesięcy.
Pozwólcie, że to wyjaśnię, bo to jest część, którą ludzie pomijają. Prawdziwy problem w rozwijającej się organizacji inżynieryjnej nigdy nie polegał na tym, że ludzie są leniwi. Chodzi o to, że czterdzieści inteligentnych osób, każda optymalizująca lokalnie i uczciwie, łącznie wyprodukuje ćwierć pracy, która nie składa się na to, czego firma chciała. Kierownictwo średniego szczebla istnieje głównie po to, aby to naprawić, przenosząc strategię w rozmowach, od biurka do biurka, tracąc wierność na każdym przeskoku. Tabela mnożników wykonuje tę samą pracę routingu w jednym skoku i nie męczy się, nie ma ulubieńców i nie zapomina, co powiedziałeś jej w styczniu.
Krytyczna poprawka na czacie jest warta czterdzieści poprawek kosmetycznych w API
Połącz obie połowy, a rozpiętość jest drastyczna.
P0 na czacie zdobywa 100 punktów bazowych razy 2,0, czyli 200 punktów. P3 w API zdobywa 5 punktów bazowych razy 1,0, czyli 5 punktów. Najcenniejszy pojedynczy pull request, jaki możesz tu scalić, jest wart czterdzieści najmniej wartościowych. Nie czterdzieści procent więcej. Czterdzieści razy.
Ta liczba jest celowo drastyczna i robi to, czego łagodne zachęty nigdy nie potrafią. Nikt nie reorganizuje swojego tygodnia wokół 15% różnicy. Ludzie absolutnie reorganizują swój tydzień wokół 40-krotnej.
Spójrz, co dzieje się z prawdziwym tygodniem przy takich wagach. Oto rozkład wag w ciągu pięciu tygodni, z rozszerzonym tygodniem 13 lipca:
188 pull requestów. P2 stanowi 59% z nich, co jest typowym tygodniem inżynieryjnym wszędzie: głównie średniej wielkości poprawki z dostępnym obejściem.
Teraz to zważ. Te 111 P2 jest warte 2 220 punktów przy 1x. 50 P1 jest warte 2 500. Mniej niż połowa pull requestów niesie więcej niż połowę wartości tygodnia, a pojedyncze P0 jest warte tyle, co dwadzieścia P3, które surowa liczba commitów potraktowałaby jako identyczną pracę.
To jest cały argument za ważeniem, w jednym tygodniu prawdziwych danych. Policz pull requesty, a dojdziesz do wniosku, że tydzień dotyczył P2. Zważ je, a odkryjesz, że tydzień dotyczył pięćdziesięciu konkretnych prac i możesz wymienić, kto je wykonał.
Dwie osoby stanowiły 58% wyników, a nie odgadłbym kolejności
Wracając do tabeli liderów, bo to tutaj przestałem ufać własnej intuicji.
Siedmiu programistów, 10 415 punktów w 30-dniowym oknie. Najlepszy programista ma 3 530 z nich, co stanowi 33,9% wszystkiego, co zespół wyprodukował pod względem wartości. Dwóch najlepszych ma razem 57,7%.
Chcę być ostrożny co to oznacza, a czego nie. Nie oznacza to, że pozostałych pięciu osiąga gorsze wyniki, a jeśli tak to odczytujesz, wyciągnąłeś z tego posta złą lekcję. Taka koncentracja zwykle oznacza, że dwaj najlepsi pracują nad komponentami o najwyższym mnożniku, co jest dokładnie tym, co system ma nagradzać i dokładnie tym, o co ich prosiliśmy. Liczba jest opisem tego, gdzie ląduje wartość, a nie wyrokiem na pięciu ludzi.
Ale spójrz na kolejność, bo zburzyła moje przewidywania. Oto kto jest właścicielem czego:
Mulualem-E jest głównym ekspertem od czatu, naszego komponentu 2.0x, z 71 z 230 pull requestów. Jest także głównym ekspertem od agentów, naszego komponentu 1.5x, z 86 z 148, czyli 58% tego obszaru. Gdybyś mi to opisał i zapytał, kto jest na szczycie tabeli liderów, bez wahania powiedziałbym, że on. Jest drugi.
Pierwsze miejsce zajmuje tugberkayartextcortex, z 31 pull requestami P1 wobec 12 Mulualem-E. Mieszanka wag pokonała własność komponentu. Posiadanie najważniejszego obszaru produktu to nie to samo, co wielokrotne dostarczanie w nim pracy o dużym wpływie, i dopóki tego nie opublikowaliśmy, nie mogłem ci powiedzieć, którą z tych dwóch rzeczy nasze wynagrodzenie faktycznie nagradzało. Nagradzało tę, którą akurat zauważyłem.
To jest premia za głośnego inżyniera, przyłapana na gorącym uczynku, w mojej własnej firmie. Moja intuicja miała właściwe dwie osoby, ale złą kolejność, a zła kolejność to właśnie premia.
Osoba, która napisała najwięcej kodu, jest na ostatnim miejscu
Teraz odkrycie, które sprawiło, że poczułem się nieswojo, i które chcę, żebyś naprawdę przetrawił.
karthikmudunuri jest głównym ekspertem od presentation makera, z 51 z 58 pull requestów tego komponentu. To 88% całego obszaru produktu. Objętość nie jest jego problemem. Jest ostatni w tabeli liderów, z 300 punktami.
Istnieje kombinacja, która daje dokładnie tę liczbę: cztery pull requesty P1 w komponencie 1.5x i nic więcej, co zdobywa punkty. 4 × 50 × 1.5 = 300. Jego odznaka mówi 4 P1, co pasuje. Nie mogę udowodnić, że to prawdziwy rozkład z tego dashboardu, i chcę uczciwie zaznaczyć tę niedokładność, ponieważ tabela liderów obejmuje 30 dni, podczas gdy wykresy komponentów obejmują 6 lipca do 3 sierpnia, więc te dwa okna są bliskie, ale nie identyczne.
Jeśli dekompozycja jest prawidłowa, około 47 scalonych pull requestów dało zero punktów. Są tylko dwa wytłumaczenia. Albo były to rzeczywiście mało istotne poprawki kosmetyczne – wtedy wynik jest poprawny, a sensowna dyskusja dotyczy tego, czy powinniśmy trzymać kogoś przez miesiąc przy 88% koncentracji na komponencie, którego nie oznaczyliśmy jako ważny. Albo była to realna praca, którą bramka kwalifikowalności wyzerowała – wtedy wynik jest błędny, a narzędzie jest mu winne wyjaśnienie.
Punktacja jest oparta na zasadzie „wszystko albo nic” w kwestii kwalifikowalności. Niezaliczenie jednego włączonego kryterium – domyślnie są to: powiązanie z zgłoszeniem, implementacja poprawki, jakość opisu PR, testy (tam, gdzie model uzna je za wymagane) oraz limit 3000 linii – powoduje, że wynik wynosi zero niezależnie od wagi. Naprawdę krytyczna poprawka ze złym opisem dostaje tyle samo, co nic.
Nie wiem, które wytłumaczenie jest poprawne, i oto moja faktyczna skarga: dashboard powinien mi to powiedzieć dla każdego pull requesta, a dziś każe mi to odtwarzać z sumy. To realna luka w naszym produkcie i jest naprawiana. Jest to też dokładnie ten tryb awarii, którego ludzie obawiają się w systemach punktacji, więc nie będę udawał, że odkryłem to podczas przeglądu projektu. Odkryłem to, pisząc ten post.
To, gdzie są błędy, to decyzja produktowa, a nie inżynieryjna
Drugą rzeczą, która wynika z punktowania każdego pull requesta, jest to, że przestajesz dyskutować o jakości na podstawie anegdot.
740 pull requestów w dziesięciu najbardziej aktywnych komponentach. 230 z nich, 31%, to poprawki błędów, a nie nowa praca. Sam Chat to 230 pull requestów, kolejne 31%, czyli dokładnie to, jak powinien wyglądać mnożnik 2.0x, gdy działa.
Potem jest presentation maker: 58 pull requestów, 23 z nich to błędy. To 40% wskaźnik błędów w komponencie z czterema współtwórcami, wobec 25% w Chacie z siedmioma. A Payments to 44 pull requesty z 20 błędami, czyli 45%, w komponencie, który dotyka pieniędzy.
Chat i Agents mają po 57 błędów, ale Chat wyprodukował je w 230 pull requestach, a Agents w 148. Ta sama liczba błędów, o 55% więcej pracy za jednym z nich. To sygnał dotyczący Agents, którego żadne retrospektywy by nie ujawniły, bo nikt w zespole nie scalił wystarczająco dużo z obu, żeby to zauważyć.
Linia błędów i linia funkcji rosną razem w tym oknie, zamiast się wymieniać – to kształt, którego chcesz, a nie ten, którego się spodziewałem. Odczytywanie tego wykresu traktuję jako opisowe, a nie jako twierdzenie, że coś poprawiliśmy. Obejmuje pięć tygodni, a trend mieści się w szumie, jaki daje jeden duży projekt wdrożony w tym czasie.
Oto, gdzie nasze własne narzędzie jest obecnie błędne
Gdybym pokazał wam tylko działające części, słusznie byście zdyskontowali całość. Więc:
Zakładka prompt nie robi tego, co mówi na ścieżce produkcyjnej. Istnieje ekran administracyjny, który pozwala dostosować prompt ewaluacyjny. Steruje on wsadowym uruchomieniem ewaluacji. Ścieżka webhook i cron, która punktuje pull requesty w produkcji, używa promptu zakodowanego na stałe w źródle. Jeśli edytujesz ten szablon, oczekując, że zmieni twoje bieżące wyniki, nie zmieni, a interfejs nic o tym nie informuje.
Kolumna „PRs” na dashboardzie z rankingiem to nie liczba pull requestów. To wynik autorstwa. Widać to na powyższym zrzucie: pierwszy wiersz pokazuje 3530 w kolumnie PRs i 3530 w kolumnie Score. Osobna strona rankingu robi to dobrze – ma osobne kolumny dla pull requestów i autorstwa – więc to błędne oznaczenie na jedynym ekranie, który wszyscy faktycznie otwierają, czyli prawie najgorsze możliwe miejsce na taki błąd.
Nasz README podaje błędne wartości punktów. Pisze, że P2 to 25 punktów, a P3 to 10. Baza danych seeduje 20 i 5, a powyższy zrzut konfiguracji potwierdza 20 i 5. Dokumentacja i oprogramowanie są ze sobą w sprzeczności, a oprogramowanie wygrywa.
Ścieżka recenzji jest prawie martwa. Recenzowanie kodu innych osób zdobywa punkty na osobnej drabince prędkości – szybsze recenzje dostają wyższe noty. W całym tym rankingu dokładnie jedna osoba ma jakiekolwiek punkty za recenzje: 90 z 10 415 ogółem, czyli 0,86% wszystkiego, co zostało ocenione. Cokolwiek myślimy, że motywujemy w kwestii przeglądu kodu, nie robimy tego. Najbardziej prawdopodobnym powodem jest to, że synchronizacja recenzji zaczęła zbierać dane dopiero niedawno, ale nie potwierdziłem tego i dopóki tego nie zrobię, uczciwe odczytanie jest takie, że funkcja nie działa.
Nasze własne FAQ twierdzi, że dokładność klasyfikacji wynosi około 90%, a nie mogę tego poprzeć. W repozytorium nie ma zestawu ewaluacyjnego, skryptu benchmarkowego ani żadnego osądzonego korpusu za tą liczbą. To twierdzenie, którego nie przyjąłbym od dostawcy, a jest na naszej własnej stronie marketingowej. Zostanie usunięte.
Tablica wyników jest podatna na oszustwa, a nasza ma prawie żadnych zabezpieczeń
Przeszukałem nasz kod punktujący w poszukiwaniu środków zapobiegających oszustwom. Oto pełna lista tego, co istnieje.
Pull requesty przekraczające 3000 zmienionych linii są wykluczone, co powstrzymuje najprymitywniejszą formę nabijania punktów. Samooceny dostają zero punktów i są wykluczane ze wszystkich zapytań do rankingu. Recenzje z kont zawierających [bot] w loginie są pomijane. Model jest pytany, czy kod faktycznie robi to, co deklaruje opis – to najbliższe, co mamy do wykrywania nonsensów. Administratorzy mogą nadpisać dowolny wynik, a nadpisanie wymaga pisemnego uzasadnienia o długości co najmniej dziesięciu znaków.
Oto, czego nie ma. Żadnego tygodniowego ani miesięcznego limitu punktów na osobę. Żadnych malejących zwrotów za powtarzającą się pracę w tym samym komponencie. Żadnego wygaszania w czasie, a 30-dniowe okno w rankingu to domyślny zakres dat, który każdy może poszerzyć, a nie limit. Żadnego wykrywania duplikatów lub revertów, więc naprawienie czegoś, co sam zepsułeś w zeszłym tygodniu, punktuje tak samo jak naprawienie czegoś, co zepsuł ktoś inny. Żadnego wykrywania zmowy między recenzentami. Filtr botów dotyczy recenzentów, ale nie autorów pull requestów, więc scalony pull request napisany przez bota punktuje jak ludzki – co w 2026 roku nie jest już hipotetyczne.
Każdy, kto jest zdeterminowany, by nabijać ten system, może to zrobić. Dzielić pracę na mniejsze pull requesty, każdy z linkiem do zgłoszenia i czystym opisem, celując w komponent 2.0x. To jest exploit i chcę go nazwać precyzyjnie, bo wygląda on tak: wygląda jak małe, dobrze udokumentowane, dobrze przetestowane zmiany w najważniejszej części produktu. Najskuteczniejszy sposób na oszukanie naszej tablicy wyników to robienie tego, czego chcemy. To nie przypadek – to cel projektowy i jedyna obrona przed prawem Goodharta, która kiedykolwiek faktycznie zadziałała. Spraw, by proxy było drogie do sfałszowania w jakikolwiek sposób, który nie jest prawdziwą rzeczą.
To nie jest pełna obrona. Ważność jest przypisywana przez model czytający diff, a model można namówić, by nazwał średni błąd wysokim, jeśli opis pull requesta jest wystarczająco dramatyczny. Nie zmierzyliśmy, jak często to się zdarza. Nikt tego nie zrobił. Jeśli oceniasz jakiekolwiek narzędzie w tej kategorii, w tym nasze, to jest pytanie, które należy zadać, a „mniej więcej 90%” nie jest odpowiedzią.
Nie podam wam liczby wzrostu, bo jej nie mam
Oto twierdzenie, które chciałbym przedstawić. Odkąd zaczęliśmy publikować ten ranking co miesiąc, praca widocznie przesunęła się w kierunku komponentów, które oznaczyliśmy jako ważne, ponieważ inżynierowie chcą punktów.
Oto dlaczego nie przedstawiam tego jako liczby. Włączyliśmy to w trakcie, bez czystej linii bazowej, bez repozytorium kontrolnego i bez wcześniej zarejestrowanej definicji tego, co oznaczałoby „przesunięcie”. Mnożniki zmieniały się w tym okresie. Podobnie jak liczba pracowników i roadmapa. Każdy procent, który opublikowałbym, byłby liczbą wybraną po zobaczeniu danych, co nie jest pomiarem – to dekoracja.
Co mogę wam powiedzieć, to jakościowe i oznaczam to jako takie. Argumenty się zmieniły. Ludzie przestali pytać mnie, czy ich praca jest doceniana, a zaczęli pytać, dlaczego komponent ma rating 1.0x. To o wiele lepszy spór do prowadzenia i to jest jedyna rzecz, za którą zapłaciłbym osobno.
Jeśli kiedykolwiek będę miał prawdziwe „przed i po”, najpierw opublikuję metodologię, a dopiero potem liczbę. Jeśli opublikuję to w odwrotnej kolejności, nie wierzcie mi.
Skieruj to na roadmapę, a potem daj ludziom linijkę
Chcę zakończyć ponad produktem, bo produkt jest tutaj najmniej interesujący.
Prawdziwą rolą schematu organizacyjnego nigdy nie była władza. To było routowanie. Niósł odpowiedź na pytanie „co jest ważne w tym kwartale” na zewnątrz od ludzi, którzy to decydowali, i niósł odpowiedź na pytanie „kto co zrobił” z powrotem do wewnątrz – i robił to źle, wolno i z ogromnym zniekształceniem na każdym przeskoku. Wszystko, czego nie lubisz w korporacyjnej polityce, jest artefaktem kompresji z tego routowania. Menedżerowie nie byli jego przyczyną. Byli jedynym dostępnym sprzętem.
Nie są już jedynym dostępnym sprzętem. Model, który czyta każdy diff plus tabelę mnożników, robi routowanie na zewnątrz w jednym skoku, a routowanie do wewnątrz w jednym zapytaniu. Dla ludzi pozostaje część, która zawsze była faktyczną pracą i na którą nigdy nie było czasu: decydowanie, jakie powinny być mnożniki, i siedzenie z ludźmi, których wyniki te decyzje przesunęły.
Polityka nie znika. Nie dajcie sobie wmówić, że tak. Przesuwa się. Przesuwa się z „czy mój menedżer pamięta mój kwartał” na „dlaczego mój komponent ma rating 1.0x, skoro roadmapa mówi, że jest kluczowy” – i ta druga walka jest walką o faktyczną strategię firmy, prowadzoną publicznie, w tabeli, którą każdy może przeczytać. Wolałbym tę walkę co miesiąc niż obecną, która odbywa się raz w roku, prywatnie, przez kogoś rekonstruującego jedenaście miesięcy z pamięci.
Ktoś poprowadzi to źle. Ktoś powiesi tablicę wyników na ścianie bez wyjaśnień kwalifikowalności i bez śladu nadpisań, zwolni dolny decyl i będzie to katastrofa, która zostanie zrzucona na model, a nie na osobę, która wybrała mnożniki. To jest część, za którą się płaci, i nie zapłaci jej ten, kto to skonfigurował.
Więc zmierzcie mnie tym samym narzędziem. Jeśli uruchomicie coś takiego, opublikujcie trzy rzeczy obok rankingu: tabelę mnożników, żeby ludzie mogli spierać się o strategię, a nie o wynik. Podział na poszczególne pull requesty, żeby każdy, kto dostał zero, mógł zobaczyć, która brama go zatrzymała, i odwołać się. Oraz dziennik nadpisań, bo liczba zmieniona przez człowieka jest jedyną liczbą wartą audytu.
Obecnie publikujemy pierwsze. Trzecie robimy źle: nadpisanie zapisuje swoje uzasadnienie w wierszu oceny, a wyczyszczenie nadpisania usuwa uzasadnienie razem z nim, więc mamy notatkę, którą można cofnąć, a nie dziennik. A drugiego nie publikujemy wystarczająco dobrze, co odkryłem dopiero wtedy, gdy programista z 88% komponentu znalazł się na końcu mojego własnego rankingu i nie umiałem mu wyjaśnić dlaczego.
GitRank jest dostępny pod adresem gitrank.dev i jest licencjonowany na CC BY-NC 4.0. Punktacja na ścieżce produkcyjnej działa na Claude Haiku 4.5 z temperaturą 0.3. Wszystkie powyższe dane pochodzą z naszego własnego repozytorium platformy między 6 lipca a 3 sierpnia 2026 roku, wielkość próby to jedna firma i siedmiu programistów, co jest opisem nas samych, a nie benchmarkiem czegokolwiek.