5 rzeczy, które są słabe w świecie programowania

Przyznaję, że każdy, kto pisze kod, ma coś nie tak z głową. Wszystko, co przewiduje 90% porażki i 10% sukcesu, wydaje się być unikane za wszelką cenę. Niestety, wysokie płace i masochizm rozpowszechniły się w rozwoju oprogramowania, więc oto jesteśmy we współczesnym świecie. Miejmy nadzieję, że ChatGPT złagodzi nasze cierpienie i zapewni nam bezrobocie.

Niestety, to jest 5 rzeczy, na które wściekam się na co dzień w programowaniu.

Kompleks wyższości

Programiści mają pewien kompleks wyższości wobec siebie nawzajem i innych ról technologicznych. Widząc na studiach, jak ci wariaci atakują informatyków za pomocą publicznego e-maila, zdajesz sobie sprawę, jak smutni muszą być niektórzy z nich. Nikt nie powinien uważać się za lepszego od kogoś innego. Wydaje się to oczywiste, ale programiści mają to dziwne przekonanie, że pisanie kodu czyni ich w jakiś sposób lepszymi.

Bardzo mnie to denerwuje, ponieważ tworzy to społeczności, które spowalniają rozwój. Wydaje mi się, że ta moda już umiera, ale byłem świadkiem kilku sytuacji, o których warto wspomnieć.

Powiem wprost, prace hydrauliczne można wykonać samemu, ale za ich prawidłowe wykonanie płaci się profesjonalistom. Nie ma znaczenia, czy masz doświadczenie w elektryce lub wykładzinach i że uważasz, że masz do tego predyspozycje. Specjaliści od technologii powinni nabrać nieco pokory i zastosować ten sposób myślenia. Życie stanie się prostsze.

Obsesja na punkcie języków lub technologii

Zarówno pojedyncze jednostki, jak i firmy robią to ze względu na to, jak bardzo skuteczne może to być w niektórych przypadkach. Jednak niezależnie od tego, czy wybierasz narzędzie wewnętrzne, czy 5 projektów Pythona z rzędu, złoty młotek nie jest dobrym pomysłem.

Zawsze wybieraj odpowiednie narzędzie do danego zadania. Wydaje mi się, że wielu (nawet doświadczonych) inżynierów czuje się dobrze w swoim jednym ekosystemie, gdy często nie ma to sensu. Szereg projektów ma z tego powodu więcej problemów niż rozwiązań, a problem pojawił się w momencie, gdy podjęto decyzję o podjęciu niewłaściwej decyzji.

Przykładowo, używanie Pythona do każdego projektu ze względu na jego prostotę nie jest dobrym podejściem. Czasami kilkuwierszowy skrypt bash lub make target może z łatwością zastąpić cały skrypt Pythona. Może być tak, że szybkość jest kluczowa w usłudze internetowej, a Go lub Java mogą być bardziej odpowiednie do skalowania.

Przyznaję, że czasami znajomość popłaca ze względu na terminy i zrozumienie zespołu, ale nie powinno to zdominować rozmowy na temat projektu. Powinniśmy najpierw pokłócić się o design, a jeśli specyfikacja już istnieje, dopełnić ją odpowiednimi elementami.

Brak nacisku na code review

Byłem rozpieszczany w moim pierwszym zespole, gdzie wzajemne code review było dość powszechną praktyką. Ludzie zaznaczali sobie w kalendarzu konkretny czas na code review i zadawanie pytań. Współpraca była tam częstym zjawiskiem, ale nie było tak w przypadku reszty firmy ani w żadnym innym miejscu, w którym pracowałem.

Code review służy nie tylko wskazywaniu możliwych błędów w kodzie. Chodzi tutaj o wskazanie wad projektowych, zapachów i stworzenie lepszych praktyk lub rozpoczęcie dyskusji na ich temat.

Podkreślam znaczenie code review, ponieważ choć staram się jak mogę, nie podejmuję najlepszych decyzji w 100% przypadków. W trakcie tego procesu wielu nowych inżynierów zwracało mi uwagę na błędy lub niedopatrzenia, które popełniłem. Finalnie przydałaby nam się druga para oczu.

Co więcej, długoterminowych błędów można uniknąć dzięki krótkoterminowym ulepszeniom. Jeśli kiedykolwiek wdepnąłeś w śmierdzącą kupę gówna, to rozumiesz, jak ważne jest wczesne wykrywanie błędów.

„Naucz się kodować”

Nie każdy chce pisać ten cholerny kod. Byłem asystentem prowadzącym zajęcia i uczestniczyłem we wprowadzeniu do programowania (dwa razy, ponieważ nie udało mi się za pierwszym razem) wystarczająco dużo razy, aby wiedzieć, że niektórzy ludzie tego nie lubią. Nie oznacza to, że jesteś głupi lub tego nie potrafisz.

Każdy może nauczyć się kodowania i związanych z tym koncepcji. Nie wierzę, że wiedza nie może zostać zdobyta i zastosowana przez jakąkolwiek osobę, ale wielu ludzi mogłoby się tym mniej przejmować.

Morał z tej historii jest taki, że nie powinieneś mówić ludziom, którzy zostali zwolnieni, aby „nauczyli się kodować”. Co więcej, nie bądź politycznym gnojkiem i nie wykorzystuj kodowania do celów politycznych. Mark Zuckerberg i tak już robi swoje.

Zapominanie o tym, co brzydkie

Wszyscy patrzą na rzeczy z sentymentem, nie pamiętając o okropnym bagnie, które temu towarzyszyło. Osobiście podobał mi się sezon zapaśniczy, ale nienawidziłem przygotowań i redukcji wagi w tym sporcie. Rozumiem jednak, że ta część jest do bani, gdy rozmawiam z innymi o tym sporcie.

Kiedy pojawia się nowy projekt, wydaje się, że szacunki nigdy nie uwzględniają bólu i cierpienia związanego z innymi projektami. Wszystko jest „proste”, gdy w rzeczywistości nic takie nie jest. Czuję, że wiele organizacji cierpi z powodu programistów pamiętających 10%, które poszły dobrze w projekcie. Hipotetycznie wszystko jest łatwe na papierze, ale wysiłek z tym związany jest zbyt często pomijany.

Czas być nieco bardziej pesymistycznym, choćby menedżerowi trzeba było o tym przypominać milion razy.

Dzięki za przeczytanie!

Oryginał tekstu w języku angielskim przeczytasz tutaj.