Mam nadzieję, że poniższy artykuł przypadnie Ci do gustu. Nie przywiązuj zbyt dużej wagi do daty powstania tego wpisu. Nawet jeśli napisałem go na początku istnienia bloga, to staram się przynajmniej raz w roku przeglądać stare treści i je aktualizować. Jeżeli mimo wszystko zauważysz jakąś nieścisłość w tekście, to daj mi proszę znać w komentarzu poniżej.
Pamiętaj także, że wartość tego bloga podbijają pozostawione tu komentarze. Jeżeli temat poruszany we wpisie Cię interesuje, to polecam doczytać także komentarze do niego. Znajdziesz w nich chociażby punkt widzenia innych osób, czy dodatkowe informacje, o których ja zapomniałem lub nie wiedziałem.
Zdążyłem wspomnieć już raz, czy dwa, że powodem mojej zmniejszonej aktywności na blogu w ostatnim czasie był przedłużający się remont mieszkania. Nie ma jednak tego złego, co by na dobre nie wyszło. Konieczność nadzorowania i synchronizowania kilku fachowców na raz utwierdziła mnie w przekonaniu, że w „budowlance” można znaleźć wiele analogii do programowania. Tak zrodził się pomysł pamiętników budowlanych. Przeczytacie w nich moje przemyślenia, które powstały właśnie w trakcie wspomnianego remontu. Nadszedł czas na pierwszy wpis.
Kto tu Panu tak spierdolił?
Przychodzi do Ciebie pierwszy fachowiec. Powiedzmy, że tynkarz, chociaż w budowlance i tak wszyscy się znają na wszystkim 😉 Skuwa stare płytki, wyrównuje, naciąga, masełkuje, gruntuje itp., itd. Finalnie jesteś bardzo zadowolon[a|y] z efektu.
Następnego dnia przychodzi drugi fachowiec, płytkarz. Pierwsze zdanie jakie wypowiada, to: „Panie, kto tu Panu tak spierdolił? Ja bym to zrobił tak: …”. Po serii kolejnych zdań tego typu zabiera się za swoją robotę, ale cały czas marudzi ile to można było zrobić lepiej, żeby on miał mniej roboty. Na koniec Ty znów jesteś zadowolon[a|y] z postępów i efektów pracy płytkarza.
Kolejnego dnia wraca pierwszy fachowiec, żeby działać dalej. Patrzy na pracę płytkarza i mówi: „Panie, kto tu Panu tak spierdolił?”, albo coś w tym stylu 🙂 I zaczyna dawać wykład jak on to by zrobił inaczej i dlaczego byłoby lepiej.
Doświadczył[a|e]ś kiedyś takiej sytuacji? Nie? To polecam mały remoncik 😉
A czy ta sytuacja nie przypomina Ci Twojego, programistycznego podwórka? Mnie już nie raz zdarzyło się być świadkiem sytuacji, w której nowa „zajebista” osoba dołącza do projektu, zajrzała w kod i powiedziała: „Kto tu Wam tak spier*****?” 🙂 I uwierz mi, nie jest to najbardziej eleganckie dołączenie do zespołu projektowego 😉
Liczy się kontekst
Prawdą jest, że kod utrzymywany przez kilka lat może mieć sporo niedociągnięć, czy niespójności. Niemniej jednak skąd osoba dołączająca do takiego projektu ma wiedzieć co spowodowało, że ten kod wygląda jak wygląda? I jakie ma prawo w ten sposób, na dzień dobry oceniać pracę innych? Przecież taki „świeżak” nie może mieć pojęcia w jakim kontekście powstał Twój kod.
Być może nad projektem, przez pewien czas pracował junior, ucząc się dopiero technologii i część z jego rozwiązań zachowała się do chwili obecnej. Może część kodu projektu, to kod otrzymany w spadku od dalekowschodniej cywilizacji i nie było jeszcze sposobności go wyprostować. Może w bebechach projektu drzemie jakiś starożytny framework, który nie jest już dłużej rozwijany, ale od którego zależy 90% projektu. Taka zależność może skutecznie powstrzymywać przed wprowadzeniem innowacji i blokować wykorzystanie bardziej nowoczesnych rozwiązań. Może część kodu, która akurat nie spodobała się naszemu świeżakowi, to „tymczasowa łatka” wprowadzona przez Twojego kolegę niezwiązanego z projektem, który „gasił pożar” w momencie kiedy Ty był[a|e]ś akurat na urlopie i nie chciał zawracać Ci głowy. A może jest to jeden z miliona innych powodów, o których newbie nie ma pojęcia. Jak w takiej sytuacji może przekonywać Cię do własnych racji?
Wykaż odrobinę empatii
Pamiętaj również, że w dowolnym momencie swojej kariery, to Ty możesz stanąć w roli świeżaka w istniejącym projekcie. Jeżeli pierwszą myślą, która przyjdzie Ci do głowy po pobieżnym obejrzeniu kodu będzie: „Kto tu Wam to tak …?”, to ugryź się w język i postaraj wykazać odrobinę empatii. Postaw się w sytuacji pozostałych członków zespołu i pomyśl co mogło spowodować, że kod, który widzisz wygląda tak, a nie inaczej. A najlepiej daj sobie trochę czasu, żeby poznać historię kodu i sytuację zespołu. Wtedy w jednej chwili wszystko może okazać się jasne. Na ocenianie przyjdzie jeszcze odpowiedni moment.
Skąd ten tytuł?
Gdybyś nie wiedział(a) do czego odnosi się tytuł dzisiejszego wpisu, to zachęcam do obejrzenia filmu Dzień świra. Poniżej możesz zobaczyć fragment, z którego pochodzi tytułowy cytat:
Bądź na bieżąco!
Podobają Ci się treści publikowane na moim blogu? Nie chcesz niczego pominąć? Zachęcam Cię do subskrybowania kanału RSS, polubienia fanpage na Facebooku, zapisania się na listę mailingową:
lub śledzenia mnie na Twitterze. Generalnie polecam wykonanie wszystkich tych czynności, bo często zdarza się tak, że daną treść wrzucam tylko w jedno miejsce. Zawsze możesz zrobić to na próbę, a jeśli Ci się nie spodoba – zrezygnować
Dołącz do grup na Facebooku
Chcesz więcej? W takim razie zapraszam Cię do dołączenia do powiązanych grup na Facebooku, gdzie znajdziesz dodatkowe informacje na poruszane tutaj tematy, możesz podzielić się własnymi doświadczeniami i przemyśleniami, a przede wszystkim poznasz ludzi interesujących się tą samą tematyką co Ty.
W grupie Programista Na Swoim znajdziesz wiele doświadczonych osób chętnych do porozmawiania na tematy krążące wokół samozatrudnienia i prowadzenia programistycznej działalności gospodarczej. Vademecum Juniora przeznaczone jest zaś do wymiany wiedzy i doświadczeń na temat życia, kariery i problemów (niekoniecznie młodego) programisty.
Wesprzyj mnie
Jeżeli znalezione tutaj treści sprawiły, że masz ochotę wesprzeć moją działalność online, to zobacz na ile różnych sposobów możesz to zrobić. Niezależnie od tego co wybierzesz, będę Ci za to ogromnie wdzięczny.
Na wsparciu możesz także samemu zyskać. Wystarczy, że rzucisz okiem na listę różnych narzędzi, które używam i polecam. Decydując się na skorzystanie z któregokolwiek linku referencyjnego otrzymasz bonus również dla siebie.
Picture Credits
prywatne archiwum
Przeczytaj także
Piotr Prądzyński
Zawodowy programista od 2009 roku. Samozatrudniony od listopada 2015. Wcześniejszy czas spędził na etacie. Od kilku lat zainteresowany tematyką budżetu domowego, finansów osobistych i optymalizacji finansowej. Prywatnie mąż, tata Tymonka, a także fan Manchesteru United, Uniwersum Wiedźmina, Star Wars oraz LEGO.
Sam ostatnio mam doświadczenie z bardzo lichą jakością czegoś co muszę przywrócić do życia. Dystans dystansem, ale na mnie ciąży teraz odpowiedzialność, żeby 20 letni twór działał i do tego, działał dobrze. Moim zdaniem nie ma nic złego w krytyce, wystarczy żeby była konstruktywna. Ja w takich sytuacjach przygotowuje krótki raport tego co jest faktycznie rażące i musi ulec zmianie. Zaliczam do tego oczywiste błędy w implementacji, które mogą powodować w przyszłości błędy ale nie można ich szybko poprawić. Zaliczam również te które, które można w miarę sprawnie zastąpić, sugerując, że np. z całego kodu wyleci kilkaset-kilka tysięcy linii na rzecz biblioteki, która na pewno robi to lepiej (nie użyli jej x lat temu bo jej zwyczajnie jeszcze nie było).
Konstruktywna krytyka zawsze mile widziana 🙂 Ważne żeby nie wjeżdżać od razu z butami i krytykować wszystko na prawo i lewo. Widzę, że masz bardzo zdrowe i sensowne podejście do tematu.
W samo sedno! Jeszcze kilka miesięcy temu wyzywałem kod (i autora…) projektu który musiałem utrzymywać, a nie dalej jak kilka dni temu sam musiałem z braku czasu stosować niezbyt eleganckie rozwiązania, w tym właśnie projekcie 😉 Pozdrawiam!
Hej. Spoko wpis, generalnie sam też mam na koncie oba wybryki. #1 Ten pierwszy gdy to ja byłem tym młodym i robiłem swoje haki. W zasadzie to nawet gdy już coś umiałem są historie krążące o DataContext który spuchł do nie miłosiernych rozmiarów. #2 Ale mam też za uszami za głośne krzyczenie że syf i że zło i tak tak nie można. Szczerze mówiąc, zdarza mi się jeszcze zamarudzić. Ale to znika z wiekiem, gdy nazbiera Ci się odpowiednio za uszami i zbierzesz odpowiednio doświadczenia i zrozumienia dla takiego kodu to przestajesz marudzić, a zaczynasz rozumieć. Powodzenia z banieczką.
O tak, doświadczenie przychodzi z wiekiem 🙂 I w przypadku programistów wystarczy te kilka lat, żeby porządnie skonfrontować rzeczywistość z wyobrażeniami jakie ma się przy starcie kariery.
Najpierw się złościsz, później dosięga Cię rozpacz, a na koniec patrzysz git blame iiiii okazuje się że autorem jesteś Ty 😛
A tak na serio samo stwierdzenie, że jest spitolone nie wnosi nic, zawsze znajdzie się coś co można zrobić lepiej 🙂
Tak jak wspomniałeś, każdy fachowiec mówi co zrobiłby inaczej i to jest bardzo istotne, bo o w czasie remontu jak jeszcze nie wyschło przerabiać raczej nie będziesz. Wiedza może przyda Ci się na kolejny, chociaż traumatyczne przeżycia raczej wypieramy z pamięci 😛
W kodzie zawsze możesz zaplanować jakiś refaktoring, albo chociaż w ramach zespołu usiąść i dać możliwość nowej osobie powiedzenia co jej się nie podoba i wspólnie zaplanować plan restrukturyzacyjny albo jeśli tak ma być wytłumaczyć dlaczego tak musi zostać. Pogadać zawsze warto bo czasem może się okazać, że jesteś tą gotującą się żabą – https://en.wikipedia.org/wiki/Boiling_frog i potrzeba kogoś z zewnątrz żeby sobie to uświadomić 🙂
Nie inaczej 🙂 Konstruktywna krytyka, przekazana na spokojnie jest zawsze mile widziana i faktycznie może dać „powiew świeżości” w zespole. Z kolei krytyka byle skrytykować powoduje tylko i wyłącznie automatyczne zaostrzenie pazurów u osoby krytykowanej 😉
Chcesz więcej? W takim razie zachęcam Cię do dołączenia do powiązanych grup na Facebooku (Programista Na Swoim, Vademecum Juniora), gdzie znajdziesz dodatkowe informacje na poruszane tutaj tematy, możesz podzielić się własnymi doświadczeniami i przemyśleniami, a przede wszystkim poznasz ludzi interesujących się tym samym co Ty.
Jeśli jesteś tu po raz pierwszy lub jeszcze tego nie zrobił[a|e]ś to zostaw proszę komentarz pod moim powitalnym wpisem. Będzie mi niezmiernie miło się z Tobą przywitać
#StandWithUkraine
Moje narzędzia
Jeżeli chciał(a)byś dowiedzieć się z jakich narzędzi korzystam na co dzień, to zapraszam Cię do odwiedzenia strony Narzędzia.
Znajdziesz tam zarówno informacje na temat tego dlaczego czegoś używam, jak i linki referencyjne, dzięki którym zakładając konto w danym serwisie otrzymasz bonus startowy.
3 listopada 2018 at 11:12
Sam ostatnio mam doświadczenie z bardzo lichą jakością czegoś co muszę przywrócić do życia. Dystans dystansem, ale na mnie ciąży teraz odpowiedzialność, żeby 20 letni twór działał i do tego, działał dobrze. Moim zdaniem nie ma nic złego w krytyce, wystarczy żeby była konstruktywna. Ja w takich sytuacjach przygotowuje krótki raport tego co jest faktycznie rażące i musi ulec zmianie. Zaliczam do tego oczywiste błędy w implementacji, które mogą powodować w przyszłości błędy ale nie można ich szybko poprawić. Zaliczam również te które, które można w miarę sprawnie zastąpić, sugerując, że np. z całego kodu wyleci kilkaset-kilka tysięcy linii na rzecz biblioteki, która na pewno robi to lepiej (nie użyli jej x lat temu bo jej zwyczajnie jeszcze nie było).
6 listopada 2018 at 07:42
Konstruktywna krytyka zawsze mile widziana 🙂 Ważne żeby nie wjeżdżać od razu z butami i krytykować wszystko na prawo i lewo. Widzę, że masz bardzo zdrowe i sensowne podejście do tematu.
20 czerwca 2017 at 20:23
W samo sedno! Jeszcze kilka miesięcy temu wyzywałem kod (i autora…) projektu który musiałem utrzymywać, a nie dalej jak kilka dni temu sam musiałem z braku czasu stosować niezbyt eleganckie rozwiązania, w tym właśnie projekcie 😉
Pozdrawiam!
21 czerwca 2017 at 04:31
Każdy z nas ma swoje za uszami 😉
12 czerwca 2017 at 19:44
Hej.
Spoko wpis, generalnie sam też mam na koncie oba wybryki.
#1 Ten pierwszy gdy to ja byłem tym młodym i robiłem swoje haki. W zasadzie to nawet gdy już coś umiałem są historie krążące o DataContext który spuchł do nie miłosiernych rozmiarów.
#2 Ale mam też za uszami za głośne krzyczenie że syf i że zło i tak tak nie można. Szczerze mówiąc, zdarza mi się jeszcze zamarudzić.
Ale to znika z wiekiem, gdy nazbiera Ci się odpowiednio za uszami i zbierzesz odpowiednio doświadczenia i zrozumienia dla takiego kodu to przestajesz marudzić, a zaczynasz rozumieć.
Powodzenia z banieczką.
14 czerwca 2017 at 05:08
Dzięki!
O tak, doświadczenie przychodzi z wiekiem 🙂 I w przypadku programistów wystarczy te kilka lat, żeby porządnie skonfrontować rzeczywistość z wyobrażeniami jakie ma się przy starcie kariery.
Co do wybryków… a kto ich nie miał? 😉
12 czerwca 2017 at 18:45
Najpierw się złościsz, później dosięga Cię rozpacz, a na koniec patrzysz git blame iiiii okazuje się że autorem jesteś Ty 😛
A tak na serio samo stwierdzenie, że jest spitolone nie wnosi nic, zawsze znajdzie się coś co można zrobić lepiej 🙂
Tak jak wspomniałeś, każdy fachowiec mówi co zrobiłby inaczej i to jest bardzo istotne, bo o w czasie remontu jak jeszcze nie wyschło przerabiać raczej nie będziesz. Wiedza może przyda Ci się na kolejny, chociaż traumatyczne przeżycia raczej wypieramy z pamięci 😛
W kodzie zawsze możesz zaplanować jakiś refaktoring, albo chociaż w ramach zespołu usiąść i dać możliwość nowej osobie powiedzenia co jej się nie podoba i wspólnie zaplanować plan restrukturyzacyjny albo jeśli tak ma być wytłumaczyć dlaczego tak musi zostać. Pogadać zawsze warto bo czasem może się okazać, że jesteś tą gotującą się żabą – https://en.wikipedia.org/wiki/Boiling_frog i potrzeba kogoś z zewnątrz żeby sobie to uświadomić 🙂
14 czerwca 2017 at 05:04
Nie inaczej 🙂 Konstruktywna krytyka, przekazana na spokojnie jest zawsze mile widziana i faktycznie może dać „powiew świeżości” w zespole. Z kolei krytyka byle skrytykować powoduje tylko i wyłącznie automatyczne zaostrzenie pazurów u osoby krytykowanej 😉