Co to jest?!?!?!. Kiedyś otrzymałem mail o takim właśnie tytule, a zawierający fragment mojego kodu. Kod ten, przyznam szczerze, zbyt elegancki nie był, ale napisałem go w sytuacji rodzaju "Masz to napisać na wczoraj". Ważne, że działał i robił to co miał robić. Nie jestem człowiekiem, który uważa swój kod za święty i sądzę, że umiem przyjąć krytykę, ale ten mail nie spodobał mi się z kilku powodów.
Po pierwsze oprócz mnie został wysłany do dwóch innych osób. Po drugie w kodzie zamieściłem komentarz wyjaśniający co ten krótki fragment kodu robi. Po trzecie treść wiadomości nie zawierała żadnych wyjaśnień jak to zrobić lepiej. Innymi słowy celem tego maila było nie tyle zwrócenie mi uwagi, że coś zrobiłem nie tak, ale bardziej pokazanie innym, że coś robię nie tak.
Całą sytuację nie przejąłem no bo i po co. Na "zaczepki" tego rodzaju mam w zwyczaju nie odpowiadać chyba, że się powtarzają. Kilka godzin później otrzymałem jednak wiadomość od jednej z dwóch osób, do której skierowany był mail Co to jest?!?!?!. Wiadomość ta była skierowana bezpośrednio do autora wiadomości Co to jest?!?!?! i wyglądała mniej więcej tak:
A to CO TO JEST?!?!?!:
Po pierwsze oprócz mnie został wysłany do dwóch innych osób. Po drugie w kodzie zamieściłem komentarz wyjaśniający co ten krótki fragment kodu robi. Po trzecie treść wiadomości nie zawierała żadnych wyjaśnień jak to zrobić lepiej. Innymi słowy celem tego maila było nie tyle zwrócenie mi uwagi, że coś zrobiłem nie tak, ale bardziej pokazanie innym, że coś robię nie tak.
Całą sytuację nie przejąłem no bo i po co. Na "zaczepki" tego rodzaju mam w zwyczaju nie odpowiadać chyba, że się powtarzają. Kilka godzin później otrzymałem jednak wiadomość od jednej z dwóch osób, do której skierowany był mail Co to jest?!?!?!. Wiadomość ta była skierowana bezpośrednio do autora wiadomości Co to jest?!?!?! i wyglądała mniej więcej tak:
A to CO TO JEST?!?!?!:
- Opis błędu numer 1.
- Opis błędu numer 2.
- ....
- Nie krytykuję publicznie czyli wysyłam mail tylko do jednej osoby. Jeśli rozmawiam z osobą, w której kodzie znalazłem błąd to mówię jej o tym w dyskretny sposób.
- Jeśli widzę, że błąd jest powszechnie popełniany to wysyłam maila to potencjalnie zainteresowanych osób i pokazuję przykład błędnego kodu ale nie wskazuję kto go napisał.
- Krytykując staram się zawsze wyjaśnić czemu uważam, że coś jest zrobione źle i jak to zrobić lepiej.
- Staram się aby moja wiadomość/wypowiedź nie była odebrana jako atak. Na przykład zamiast sformułowania Co to jest?!?!?! mail zatytułowałbym Błąd w metodzie SomeMethod. Taki tytuł wiadomość niesie z sobą jakąś informację i sądzę, że jest neutralny w odbiorze.
- Zanim wyślę maila lub pójdę porozmawiać upewniam się jeszcze raz, że błąd to rzeczywiście błąd.
orcid.org/0000-0002-6838-2135
14 comments:
Jako autor pierwszego maila "CO TO JEST" oraz jako osoba, której tyczy się się wpis, chciałem tylko dopisać:
Takie maile zdarzają się w sytuacji, w której funkcjonalność, która ma działać (podobno nawet była testowana) po prostu nie działa, termin pokazu zbliża się nieubłaganie, a ja biedny żuczek, próbuję zrozumieć co autor miał na myśli. Nie widzę sensu przytaczania tego kodu, ale jeśli już mówimy o sensie, to nie widziałem w nim żadnego.
Kiedy terminy naglą, nie czas na konwenanse i mizlenie się do siebie z uśmiechami "bardzo mi przykro, może nie mam racji, ale wydaje mi się, że tutaj coś nie nie działa, ale może się mylę. Przepraszam.". Sorry, produkujemy soft w trybie "na wariata", "pokaz driven development" i jak coś nie działa, przez co np. nie działa inny kawałek kodu, to nie ma co oczekiwać na łaskawe traktowanie. Mnie też nikt po głowie nie głaska, jak coś spapram. Amen.
No i chyba najważniejsze to to, że raczej każdy się stara pisaniu kodu, niezależnie od tego czy ma dużo czasu czy nie i jeśli pojawia się błąd to nikt tego specjalnie przecież nie robi.
WolfMoon, nigdzie nie napisałem, że oczekiwałem na "łaskawe traktowanie". Nie napisałem również, że krytyka powinna wyglądać tak "bardzo mi przykro, może...". Twierdzę natomiast, że krytyka ma sens jeśli jest konstruktywna, a uważam, że Twoja nie była. Abstrahując już od tego czy ten kod był bez sensu czy nie, jak sam zauważyłeś był pisany pod presją nieubłaganie zbliżającego się terminu, a wtedy łatwiej o pomyłki. Zgadzam się, że mogłeś nie mieć czasu na rozpisywanie się w mailu. Czy Twoja wiadomość nie zostałaby jednak odebrana w inny sposób gdyby wyglądała jak poniżej? Czy jej napisanie zajęło by więcej niż 5 minut?
Do: Michał Komorowski
Tytuł: Błędny kod
PRZYKŁAD_KODU.
Niestety ale powyższy kod spowodował sporo problemów i straciłem przez niego sporo czasu. Na przyszłość powinieneś bardziej uważać. Już go poprawiłem, a więc spójrz na niego i zobacz jak powinien wyglądać.
Pracujecie w jednej firmie i wyzywacie się kto pisze gorszy kod ? Nie wiem gdzie pracujecie, ale to nie jest dobry pracodawca, albo wasz kierownik jest do d..., albo jedno i drugie.
Polecał bym pracuj kropka pl :)
pozdr
Adam
Adam, wyciągasz zbyt pochopne wnioski. Po pierwszy całej sytuacji nie na nazwałbym wyzywaniem się ale źle sformułowaną krytyką. Weź również pod uwagę warunki (zbliżający się termin, nerwówka) w jakich to się zdarzyło. Po drugie możesz mi wierzysz, że bez względu na to gdzie bym pracował (pracowałem, będę pracował) gdyby takie zdarzenia powtarzały się to zmieniłbym pracę.
Posta napisałem kiedy przypomniałem sobie o tej sprawie oraz kilku innych, których byłem świadkiem w różnym czasie, w różnych sytuacjach i miejscach, po to aby przedstawić swój punkt widzenia. Zachęcam więc do dyskusji ale na temat tego jak krytykować w sposób konstruktywny, przede wszystkim w kontekście IT ale nie tylko, jakie macie doświadczenia w tym kontekście itp.
To co piszę to oczywiście tylko moje zdanie i jak najbardziej mogę się mylić i bardzo możliwe, że tak jest :)
Poprzedni wpis był trochę skrótem myślowym, który może rozwinę:
cytat: "(podobno nawet była testowana)"
mój wniosek: to znaczy, że nie można sprawdzić czy była testowana ?, to znaczy, że nie ma testów jednostkowych ?, nie ma scenariuszy testowych ?, nie ma continous integration ?
to wszystko w mojej ocenie wpływa na jakość kodu i ktoś za to odpowiada,
cytat: "produkujemy soft w trybie "na wariata""
mój wniosek: źle dobrane terminy, brak dobrego porozumienia z klientem (klient powinien mieć świadomość, że szybko nie znaczy dobrze), kiepska analiza wymagań lub nie aktualna analiza wymagań, ktoś za to odpowiada.
Dlatego sugerowałem, że coś jest nie tak,
a sytuacja która powstała, jak by jej nie nazywać wydaję mi się być tylko pochodną tego o czym napisałem powyżej.
Adam
@Michał: dobrze, będę na przyszłość uważał :) Ale i tak sytuacja była wyjątkowa, bo terminy wyjątkowe i pokaz również był nietypowy (wewnętrzny PR).
@Adam:
To co piszesz to oczywiście prawda, żywcem zaczerpnięta z książek o inżynierii programowania. Osobiście, ja i 1/2 działu zazdrościmy ci takich klientów, wyrozumiałych, wiedzących, że jakość kodu zależy od czasu jaki się nad nim spędzi, że szybko != dobrze oraz "zawsze można zaprosić ich na sok". Tylko, że niestety realia są inne. Jeżeli pracuje się w firmie wielkości Comarchu bądź Signity, to można wynegocjować terminy takie, że nie dość, że kod się napisze, przetestuje, poprawi, skomentuje, to jeszcze napisze się dokumentacje i jest czas zagrać w pasjansa :P
Z doświadczenia pracy w różnych firmach wiem, że z reguły, im mniejsza firma, tym bardziej napięte terminy, a ta w której pracujemy z Michałem, to gigant nie jest.
Dodatkowo tutaj sytuacja jest jeszcze bardziej pokrętna, związana z produktem i stylem pracy nad nim. Dużo było by tłumaczyć i nie koniecznie są to informacje, które powinny pojawić się na forum publicznym.
Co było celem tego postu? Bo autor tego nie sprecyzował.
A co do ostatniej wypowiedzi dot. wielkości firmy, to nie ma i nie powinna mieć żadnego wpływu na proces tworzenia aplikacji. Też pracowałem i w dużych i w małych firmach i w każdej, w której nie było czasu na testy, tworzenie dokumentacji, przychodził taki moment, kiedy wszyscy stwierdzali, że produkujemy buble i szkoda czasu na tworzenie oprogramowania.
Nie napisałem tego wprost ale moim celem było przedstawienie swoich przemyśleń na temat tego jak należy krytykować aby odniosło to pożądany skutek. Dyskusja zboczyła jednak w zupełnie innym kierunku.
W korporacji osobiście nigdy nie pracowałem, ale znam trochę ludzi, którzy pracowali lub pracują i od nich równie często jak od kolegów/koleżanek pracujących w mniejszych firmach słyszę narzekania na szeroko pojęty bałagan: brak testów, brak dokumentacji, napięte terminy... Zgadzam się więc z przedmówcą, że wielkość firmy nie ma tutaj znaczenia. WolfMoon ma jednak rację pisząc, że większe firmy mają lepszą pozycję w negocjacjach z klientem. Choćby z tego powodu, że dla nich kolejny projekt to nie jest przeważnie kwestia "życia i śmierci".
Nie wiem jak to jest w tej konkretnej firmie, ale mogę sobie to wyobrazić z perspektywy firmy, w której kiedyś pracowałem: mała firma, z kiepskim kierownikiem, który tylko wymaga, by soft działał, nie ważne co jest w środku, jak to jest zrobione, jaki jest kod, ma się tylko kręcić, czyli działać. A jak się nie kręci (nie działa) to winny jesteś TY programisto. Kierownik, który nie jest wsparciem merytorycznym dla zespołu bo jest już kierownikiem od dawien dawna i najbardziej z internetu interesują go ciekawe oferty na allegro. Przepychanki na forum mogą oznaczać, że w Waszej firmie nie ma zwyczaju rozmawiania o tym co się robi, każdy patrzy się w swój monitor, nie projektujemy tylko klepiemy. Byleby firma wyrwała zlecenie, niech klient zapłaci, a potem się jakoś to dokończy. Kierownictwo pewnie uważa, że testy jednostkowe są niepotrzebne bo w tak napiętym harmonogramie nie ma czasu na coś, co tylko wydłuża proces produkcji. A my przecież musimy sprzedawać. Sprzedawać byle co!!! Po jakimś czasie sami programiści zauważają, że to co robią jest bez sensu, zwykle nie działa, ciągle są poprawki, przekraczamy terminy, produkujemy praktycznie bez zysku, nie ma przez to premii, obniża się chęć do pracy. Oczywiście ciężką sytuację (stan zespołu) tłumaczy się specyfiką branży, oryginalnym stylem pracy, ciężkim klientem itp. dyrdymałami. Ot, tzw. mydlenie oczu. Itd, itd... Jeśli trochę przesadziłem to celowo.
A teraz coś od serca: warto się zastanowić jak będzie wyglądała moja praca w takiej firmie za 3, 5 lat i więcej. Na ile będę jeszcze miał siłę uczyć się, cokolwiek rozwijać, na ile będę lepszym specjalistą, a nie tylko klepaczem kodu. I podjąć jakąś decyzję, może czasem kosztem, jak by nie było, jednak fajnej atmosfery w pracy. Niektórych rzeczy (firm, ludzi) nie da się zmienić choćbyśmy nie wiem jak się starali. Nie da i już. A finał będzie zawsze taki: Kto nie ma, temu zabiorą i to co ma, a kto ma temu dodadzą, tak że nadmiar mieć będzie.
Widzę, że ktoś podziela moje poglądy ;)
@WolfMoon: Nie wiem jak jest w Sygnity lub Comarchu, bo nigdy tam nie pracowałem, więc trudno mi polemizować.
Mam natomiast 10 lat doświadczenia w zawodowym programowaniu i wiem co wpływa na jakość kodu, poza umiejętnościami samych programistów oczywiście :)
Pracowałem w niejednej firmie i jeżeli mówisz, że u was to się nie da bo jest to bardzo wyjątkowa firma/sytuacja/klient to moim skromnym zdaniem tak nie jest, ale łatwo jest tak myśleć, to pewnym sensie zwalnia od odpowiedzialności.
Co do książek o inżynierii oprogramowania to największą trudnością jest teorie tam zawarte wprowadzić w praktykę, nie zawsze się udaje, ale zawsze warto spróbować.
Klientów nie ma mi co zazdrościć są tacy jak wszędzie :)
@Michał Komorowski: Łatwego życia to ty w tej firmie nie masz ;)
"Łatwego życia to ty w tej firmie nie masz ;)"
Ameryki nie odkryję jeśli powiem, że każda firma ma wady i zalety. Nie chcę tutaj wnikać w szczegóły bo nie o to chodzi. Moje doświadczenie zawodowe jest krótsze niż Twoje bo ok. 5 letnie ale mogę powiedzieć, że jestem zadowolony ze swojej obecnej pracy i mogę się w niej rozwijać. Dyskusja potoczyła się zupełnie inaczej niż sobie to wyobrażałem :)
@WolfMoon:
Zrobiłeś źle i w tym momencie nie powinieneś się zbyt dużo tłumaczyć. Michał zrobił dokładnie to co Ty. Wykazał Twój błąd przed publicznie w sposób jaki nie koniecznie chciałbyś sobie tego życzyć. Zachował on Twoją anonimowość (sam się ujawniłeś) a i tak z Twoich wypowiedzi można wywnioskować że czujesz się urażony... inaczej byś nie odpisywał.
Każdy popełnia błędy. Jeżeli już chcesz ludziom zwracać uwagę na nie, to dołóż wszelkich starań, by nie tylko przyniosło to jednorazową korzyść, ale także aby Twoja uwaga była odebrana pozytywnie i w korzystny sposób wpłynęła na dalszą współpracę.
Nadawanie e-mailowi tytułu "Co to jest", jest delikatnie mówiąc nie szanowaniem drugiej osoby. Tytuł e-maila jest po to, by mógł zawierać konkretne informacje, które w przyszłości pomogły by np. w znalezieniu tego e-maila za pomocą wyszukiwarki w kliencie pocztowym lub generalnie jego późniejszą identyfikację.
A co do dalszej części waszej dyskusji. Proponuje nie kontynuować Wam wypowiedzi w tym wątku, gdyż jakby nie było... po co w internecie jeszcze jeden personalny spór w miejscu w którym ludzie oczekują technicznych i rzetelnych informacji? Zablokuj możliwość dodawania dalszych komentarzy pod tym postem i nie bawcie się w obrażone dzieci ;)
@noisy:
Zgadzam się z Tobą, że dyskusja potoczyła się w zły sposób ale mam jeszcze jedną uwagę w kontekście Twoje wypowiedzi. Moim celem nie było napiętnowanie kogokolwiek, a już na pewno w sposób publiczny. Po prostu pewne zdarzenia jakich jest świadkiem lub uczestnikiem skłaniają mnie do refleksji, które potem materializują się w postaci postów. Nie udało mi się ale starłem się aby nie można było zidentyfikować uczestników zdarzenia oraz tego kiedy miało ono miejsce. Tak jak napisałeś nie podałem tożsamości osoby, która napisała tego maila. Pisząc "Kiedyś otrzymałem mail o takim właśnie..." chciałem również nie ujawniać kiedy go otrzymałem.
New comments are not allowed.