Dziękuję bardzo za komentarz! :) Marcin mnie zaprosił, miałem okazję podzielić się błędami które popełniam. Bardzo się cieszę, że się przydało! :)

Interesująca jest ta korelacja między takimi historiami a występowaniem słowa „korpo” przy ich okazji ;)

"There is nothing so useless as doing efficiently that which should not be done at all." - Peter Drucker ;)

Co masz na myśli pisząc - niedoceniane? Z mojej perspektywy to przecież clue tej pracy, ale rozwiń temat bo brzmi ciekawie.

Wielu anonimowych magików chwali się w necie pracą na kilka frontów 🤔

@@PrzemekSmyrdek Zdalnie - da się, ale w innych branżach np. budowlanka też pracują na kilka frontów

@@grzesiekx441 …ale nie wiem czy bywają na trzech budowach w tej samej minucie - wiesz co mam na myśli.

@@PrzemekSmyrdek Na mojej budowie gość to zrealizował tak, że po prostu wziął podwykonawców, w programowaniu rzadziej się to praktykuje ( chyba XD )

Ciekawe. Przyznam, że nigdy nie rozumiałem tej opinii: "jeśli trzeba w jakiś szczególny sposób tłumaczyć kod, np przez komentarze/rozmowy, to coś jest w nim nie tak.". W takiej sytuacji zakładamy, że wszyscy, którzy pracują w projekcie mają tę samą wiedzę o całej aplikacji i wszystkich bibliotekach, dostępną w każdym momencie. Myślę, że jak w teamie pracuje kilka osób, o różnej wiedzy i różnym poziomie doświadczenia, komentarze mogą ułatwić pracę i zrozumienie tego co robimy. Np. w aplikacji Reactowej, mam kod napisany w D3.js. Wiem, że w przyszłości mogą na ten kod patrzeć ludzie, którzy nie mają świetnej znajomości D3, ale muszą go utrzymywać. Dodaję komentarze opisujące strukturę kodu, jakie elementy zmodyfikować, żeby uzyskać porządany efekt, czego nie wolno ruszać bo cała wizualizacja się wywali. Dla mnie jest to ułatwienie pracy sobie i innym.

@@fricze Zadaniem osoby która robi code review, nie jest zrozumienie całego projektu, tylko tego konkretnego kodu, warto żeby był napisany w taki sposób, aby właśnie tych dodatkowych tłumaczeń nie wymagał, co można osiągnąć przez odpowiednie nazywanie metod/klas/funkcji, stosowanie wzorców, zwięzłych metod/funkcji, zasad SOLID, KISS. Do tego stosowanie komentarzy to niezbyt dobra praktyka, ponieważ poza kodem trzeba dodatkowo utrzymywać i modyfikować komentarze, czasem ktoś może zapomnieć to zrobić i wtedy komentarz rozjeżdża się z kodem. Widzę tylko jedno uzasadnienie dla stosowania komentarza, kiedy dany kod wydaje się niepoprawny, łamie jakieś podstawowe zasady programowania, czy reguły panujące w danym języku, ale właśnie w tej dziwnej postaci jest konieczny (np przez jakiś dług technologiczny, czy specyficzny styl programowania, albo specyficzne, nieintuicyjne użycie tego kodu, np w środowisku wielowątkowym), wtedy warto dodać taki komentarz z uzasadnieniem skąd tak dziwny kod, żeby inny programista miał tego świadomość i nie marnował czasu na poprawianie tego kodu. Być może sytuacja wygląda inaczej kiedy samodzielnie tworzysz jakiś moduł, ale ja osobiście nie schodziłbym do poziomu tłumaczenia bibliotek, użycie konkretnej biblioteki powinno być ukryte pod jakąś zrozumiałą abstrakcją, której implementację można bezboleśnie zmienić na użycie innej biblioteki. Poza tym, samouczek dla danej technologii, dobre praktyki itd, można zawrzeć w wiki, nie trzeba robić tego w kodzie.

​@@AndrzejWilkable 1) "Poza tym, samouczek dla danej technologii, dobre praktyki itd, można zawrzeć w wiki, nie trzeba robić tego w kodzie." - jasne, każda forma dokumentacji, która ułatwi ludziom współpracę jest dobra. Nie muszą to być komentarze. Tu się po części zgadzam. 2) "warto żeby był napisany w taki sposób, aby właśnie tych dodatkowych tłumaczeń nie wymagał, co można osiągnąć przez odpowiednie nazywanie metod/klas/funkcji, stosowanie wzorców, zwięzłych metod/funkcji, zasad SOLID, KISS" - z tym się, w dużej mierze, nie zgadzam. To łatwo prowadzi do bardzo długich nazw klas, funkcji i zmiennych. SOLID i KISS to są narzędzia, które ułatwiają utrzymanie kodu. To prawda. Tylko, że można się do nich stosować i dalej pisać kod, który działa dobrze, ale jest niezrozumiały dla innych. Zupełnie nie działają w zastępstwie dokumentacji/komentarzy. Jeśli masz przykład takiego kodu, który się rozumie "sam z siebie", bez komentarzy/dokumentacji - chętnie go poznam. Dodatkowo KISS jest zasadą abstrakcyjną i różni programiści będą ją różnie interpretować. 3) "użycie konkretnej biblioteki powinno być ukryte pod jakąś zrozumiałą abstrakcją, której implementację można bezboleśnie zmienić na użycie innej biblioteki" - 100% się nie zgadzam. In real life nie da się pisać abstrakcji pod każdą bibliotekę, której używasz. 1) Nie ma czasu. 2) Nawet jeśli by się dało, to abstrakcja będzie zawierała tylko część funkcji, których potrzebujesz i w przyszłości ktoś będzie musiał ją rozbudować. Wtedy nie dość, że musi poznać bibliotekę schowaną pod abstrakcją, to musi jeszcze poznać abstrakcję. W realnym życiu to są zbyt wysokie wymagania. Bezpośrednie użycie biblioteki, plus opisanie kodu, zajmie, z reguły, mniej czasu niż pisanie abstrakcji i będzie bardziej elastyczne. 4) "Zadaniem osoby która robi code review, nie jest zrozumienie całego projektu, tylko tego konkretnego kodu" - bardzo abstrakcyjne stwierdzenie. Bez znajomości projektu można zrobić review dot. code style, ale nie można zrobić porządnego review logiki i np. stwierdzić, że dana funkcja istnieje już w projekcie, więc została niepotrzebnie napisana od nowa. 5) Ode mnie. Rzeczywiście, można pisać dokumentację kodu poza kodem, np. utrzymywać Confluence. Minus jest taki, że to jest daleko od kodu i wymaga szukania. Komentarz jest na miejscu, w trakcie kiedy programujesz. Ciekawa dyskusja! :) Pozdrawiam

Daj kontakt do tego managera 😅

Jak zawsze ‚to zależy’ :) albo jest to kiepski manager, który nie wie jak dobrze zarządzać, albo przekazujesz mu nie te informacje które trzeba. Ja np. nie dziele się z managerem konkretnymi problemami i szczegółami technicznymi tego jak pracuję nad taskami, ale z kolegami z teamu już tak. Managerowi zawsze można powiedzieć: w trakcie pracy wyszły nowe szczegóły, lub zależności z inną częścią programu i teraz w teamie dyskutujemy jak najlepiej je obsłużyć. Będzie to brzmiało lepiej niż: wiesz co, znowu mam problem, zejdzie mi 4 dni dłużej :)

Ja uważam odwrotnie, warto się dużo odzywać, znam przykłady osób które poprzez obszerną komunikacje (niekoniecznie bardzo techniczną) sprawiali wrażenie bardziej zaangażowanych i kompetentnych w oczach osób nietechnicznych i równocześnie w tym samym zespole osoby które skąpiły słów i mimo bardzo wysokich kwalifikacji były popędzane przez menagerke bo czemu tak wolno idzie praca? Sam zresztą też byłem taką osobą dawniej przez co moim zdaniem uciekła mi rola team leadera na rzecz kolegi z podobnym stażem, ale gorszymi umiejętnościami technicznymi.