6 Minuty
Linus Torvalds, twórca systemu operacyjnego Linux, otwarcie skrytykował praktykę oceniania programistów na podstawie liczby napisanych linii kodu – metrykę, którą rzekomo promuje Elon Musk. W obszernym wywiadzie na kanale YouTube Linus Tech Tips, Torvalds określił tę metodę nie tylko jako błędną, ale wręcz „niekompetentną”. Jego stanowisko wywołało żywą dyskusję w środowisku deweloperów na temat tego, jak rzeczywiście należy mierzyć umiejętności oraz efektywność twórców oprogramowania.
Dlaczego liczenie linii kodu jest niebezpiecznym uproszczeniem
Podczas wywiadu prowadzący wspomniał o starej metryce programistycznej – liczbie wszystkich linii kodu. Pojawiły się sygnały, że po przejęciu Twittera (obecnie X) przez Elona Muska, inżynierowie mieli drukować swoje pliki źródłowe, a osoby z mniejszą liczbą linijek rzekomo były zagrożone zwolnieniem. Torvalds nie owijał w bawełnę, nazywając ocenianie informatyków według liczby linii „czystą niekompetencją” i podkreślił: „Każdy, kto tak myśli, jest zbyt nierozsądny, by pracować w branży technologicznej.”
Fala komentarzy, jaką wywołała ta ostra ocena, nie powinna dziwić. Sedno problemu jest proste: ilość nie oznacza jakości. Ocenianie produktywności po liczbie napisanych linii kodu wspiera wodolejstwo, zwiększa podatność systemów na błędy i promuje niepotrzebną złożoność. Przemyślane oprogramowanie wykonuje więcej przy mniejszej ilości kodu – ta oszczędność kodowania świadczy o profesjonalizmie, a nie lenistwie.
Reakcje programistów: powszechna dezaprobata
Na Reddit oraz innych forach społeczności programistów głosy zdecydowanie poparły opinię Torvaldsa. Komentarze wahały się od rozbawienia do złości: „Nawet początkujący student informatyki wie, że liczenie linii kodu to najgorsza metryka.” Społeczność argumentuje, że takie reguły zachęcają do tworzenia rozbudowanych, nieefektywnych rozwiązań i zwiększają ilość błędów – dokładnie odwrotny efekt względem potrzeb firm dążących do rozwoju produktów czy stabilizacji platformy.
Przykłady ilustrujące problem
- Kompaktowy algorytm o długości 100 linii może być znacznie skuteczniejszy niż łatka na 1000 linii, która powiela logikę i wprowadza niejasności.
- Refaktoryzacja kodu często zmniejsza liczbę linii przy zwiększeniu przejrzystości i łatwości utrzymania – czy polityka oparta na liczbie linii by to karała?
- Automatyczne formatowanie czy szczegółowe logi mogą sztucznie zwiększyć rozmiar pliku bez realnej poprawy jakości oprogramowania.
Warto wyobrazić sobie, że pisarze są nagradzani za długość esejów, a nie za klarowność wywodu – analogiczna logika odnosi się do nagradzania programistów za objętość, a nie kunszt rozwiązania.
Na co naprawdę powinny zwracać uwagę firmy technologiczne
Jakie wskaźniki powinni więc mierzyć menedżerowie IT, jeśli nie liczba linii kodu? Zdecydowanie większą wartość mają takie miary jakości, jak efekty pracy z code review, wskaźnik błędów, czas realizacji zmian, pokrycie testami oraz zdolność dostarczania niezawodnych funkcjonalności. Nie można też pomijać czynników „miękkich” – współpracy zespołowej, myślenia architektonicznego oraz umiejętności upraszczania złożonych problemów – to właśnie one odróżniają świetnych inżynierów od przeciętnych.
Krytyka Torvaldsa przypomina liderom branży technologicznej, by wybierali wskaźniki, które faktycznie promują utrzymywalność i świadome projektowanie architektury oprogramowania. Inaczej istnieje realne ryzyko, że będą nagradzać zachowania prowadzące do narastania długu technologicznego i spadku stabilności produktu – co może być bardzo kosztowne dla każdej firmy zależnej od innowacyjnych technologii.
Szerszy kontekst: produktywność programistów i współczesne wyzwania
W dzisiejszej branży IT, gdzie dynamiczne zmiany technologiczne oraz szybkie tempo rozwoju projektów stanowią normę, dobór właściwych metod oceny pracowników zyskuje kluczowe znaczenie. Oprogramowanie open-source, jak Linux czy projekty chmurowe, wskazuje na siłę kolektywu oraz odpowiedzialność za jakość kodu, a nie jego ilość. Eksperci coraz częściej zwracają uwagę, by menedżerowie stawiali na mierzalne aspekty jakości kodu, promowali rozwój wiedzy zespołu oraz długofalową stabilność rozwiązań.
Narzędzia nowoczesne, jak automatyzacja analiz statycznych, testy jednostkowe, continuous integration, czy szczegółowe code review, pozwalają skutecznie ocenić rzeczywistą wartość pracy programistów i minimalizować ryzyko wprowadzania błędów.
Torvalds a ewolucja podejścia do efektywności deweloperów
Linus Torvalds od lat uchodzi za autorytet w dziedzinie rozwoju oprogramowania. Jego stanowisko w zakresie metryk programistycznych nie jest odosobnione – wielu szanowanych ekspertów i liderów zgodnie uważa, że kultura pracy oparta na ilości, a nie jakości, prowadzi do zagrożeń i ogranicza prawdziwą innowacyjność. Projekty realizowane w środowiskach otwartych i wysoko konkurencyjnych (jak Kernel Linux czy duże aplikacje chmurowe) pokazują, jak wielka odpowiedzialność ciąży na architektach systemów i liderach technicznych.
Klucz do sukcesu w branży IT to równowaga pomiędzy solidnym, czytelnym kodem a szybkim rozwiązywaniem rzeczywistych problemów użytkowników – a nie ściganie się na objętość.
Przyszłość oceniania programistów: rekomendacje i wyzwania
W obliczu rozwoju sztucznej inteligencji, pracy zdalnej i złożonych ekosystemów IT pojawiły się nowe sposoby śledzenia efektywności. Narzędzia do zarządzania projektami pozwalają mierzyć lead time, wydajność wdrożeń czy stabilność produkcji. Odpowiedzialni liderzy powinni skoncentrować się na wskaźnikach związanych z jakością, komunikacją w zespole oraz adaptacją do zmieniających się wymagań.
Zamiast szukać prostych, liniowych miar w stylu „lines of code” warto wdrażać produktywne praktyki: pair programming, dokumentowanie decyzji architektonicznych, uczenie się na błędach oraz budowanie otwartego, innowacyjnego środowiska pracy.
Podsumowanie: liczenie linii kodu to ślepa uliczka
Wybór nieodpowiednich wskaźników oceny programistów, takich jak liczba linii kodu, prowadzi do wzrostu technicznego długu, obniżenia efektywności i frustracji – zarówno wśród pracowników, jak i zarządów firm technologicznych. Zaangażowani liderzy IT i specjaliści HR powinni wspierać kulturę organizacyjną skupioną na jakości, zaufaniu, przejrzystości oraz ciągłym rozwoju umiejętności zespołowych. To podejście nie tylko zwiększa innowacyjność, lecz także skutecznie minimalizuje ryzyka projektowe oraz kosztowne błędy systemowe.
Źródło: smarti
Zostaw komentarz