Praca, nietypowe, stresujące sytuacje

Witam.

Chciałbym poruszyć temat sytuacji nietypowych, stresujących w pracy. Nie wiedziałem gdzie umieścić ten wątek więc wylądował tu.
Oczywiście piszę go nie bez powodu. Szczerze mówiąc nie wiem jak w takich momentach reagować.
Może naświetlę kim jestem i czym się zajmuję.

Programowaniem zajmuję się w sumie od dwóch lat. Przez pierwsze pół roku to tylko zabawa, potem zacząłem myśleć o programowaniu poważnie. Zainteresowało mnie i wciągnęło. W sumie od ponad roku pracuję na stanowisku programisty java. Zajmuję się tworzeniem aplikacji webowych. Firma polska odbiorca już nie. Są to sklepy internetowe rzędu agito.pl. - pewnie więcej sesji. Aplikacje są tworzone w springu ale do rzeczy.
Czasem zdarza mi się popełnić błąd albo może inaczej zapomnieć o czymś. Może przykład: pole na formularzu powinno dopuszczać 23 znaki a dopuszcza 24. Jeśli chodzi o problem stricte języka to nie mam problemów. Wszystko co mam do zrobienia zapisuje i analizuję. Staram się tworzyć na papierze algorytmy po czym je implementuje. Czasem te błędy wynikają z niedoinformowania. Mimo wszystko wina jest przypisana do mnie. Cały czas usprawniam proces tworzenia oprogramowania i poszerzam wiedzę. Mimo wszystko zdarza mi się czasem popełnić błąd. Nie wiem jak reagować na takie sytuacje , nie wiem czy to jest normalne, że po roku zdarzają mi się takie błędy. Jeśli ma ktoś sprawdzone jakieś wzorce zachowań, komunikacji w takich sytuacjach prosił bym o ich przedstawienie.
Dochodzi też komunikacja z pewną sobą w teamie. Jest dobry w tym co robi. Mam "zaszczyt" zmieniać jego kod. Często dzieje się to szybko i jest konieczna komunikacja z nim. Strasznie się wywyższa. Jakakolwiek niewiedza, pytanie jest odbierane jak swoista wygrana dla niego. Odpowiedzi skromne albo bełkot i odejście. Szczerze mówiąc może to brzydko z mojej strony ale wolałbym z porzyganym jeść niż z nim coś pisać. Jak z kimś takim współpracować? Oczywiście żadne siłowe rozwiązania nie wchodzą w grę. Już dawno bym je zastosował.
Jeśli ktoś zna jakieś artykuły, książki traktujące o komunikacji w pracy, rozwiązywaniu tego typu sytuacji prosiłbym o info.

Z góry bardzo dziękuję i pozdrawiam.

Weź go na stronę podczas jakiegoś lunchu, powiedz, że musicie porozmawiać, że nie jesteś w pełni zadowolony z waszej współpracy. Powiedz co leży ci na sercu i byłoby dla obojga lepiej (ty lepiej zrozumiesz jego kod, on będzie poinformowany o ewentualnych zmianach i wszystko odbędzie się sprawniej).
Jak nie będzie rezultatu to wal do szefa, on powinien być przeszkolony w kwestii rozwiązywania konfliktów w zespole i na pewno jego mediacje będą znaczyły coś więcej.

Tylko nie przesadź w drugą stronę, tj. sprawiaj wrażenie, że faktycznie bardzo ci na tym zależy, a nie zwalaj winę na brak współpracy z jego strony, bo to wzajemne obwinianie się nie prowadzi absolutnie do niczego.

Tego typu kwestiami zajmuje się cały dział pt. Psychologia pracy i jest bardzo dużo książek na ten temat (zdecydowana większość pod takim właśnie tytułem).

Pracownicy mają obowiązek pomagać innym pracownikiom szczególnie jeżeli sprawa dotyczy kodu, który sam napisali. Ja bym poszedł od razu do szefa.

Jest kilka możliwości jak podejść do takiego... jełopa...

Podejście nr 1:
"Podwładny powinien przed obliczem przełożonego mieć wygląd lichy i durnowaty tak, aby swoim pojmowaniem istoty rzeczy przełożonego nie peszyć"

Podejście nr 2:
Przeczytać http://thc.org/root/phun/unmaintain.html
Jeśli wziankowany element stosuje któreś z tych technik to będąc ich świadomym można to wytknąć lub publicznie napiętnować bez wskazania osoby napiętnowanej...

Podpierdalanie raczej nic nie da.
Jeśli Twój przeciwnik ma mocną pozycję to albo się dostosujesz, albo zmień pracę, albo próbuj coś zmienić, ale bez poparcia będziesz miał pod górkę...
Polityka, psychologia, techniki sprzedaży i prezentacji, negocjacje - to wbrew pozorom nawet w IT się przydaje.

@xprime:
Co do pierwszej części wypowiedzi...

Każdy popełnia błędy i produkuje jakieś bugi. Niezależnie od stażu i umiejętności, nie będziesz pisał idealnego kodu. Bardzo wiele z tych błędów jest w gruncie rzeczy banalnych. To też jest normalne.

Wszystko co mam do zrobienia zapisuje i analizuję. Staram się tworzyć na papierze algorytmy po czym je implementuje.
(...)
Cały czas usprawniam proces tworzenia oprogramowania i poszerzam wiedzę.

I o to chodzi! Jeśli jest tak, jak piszesz, i jest tak w wystarczającym stopniu, to od tej strony robisz wszystko OK.

Nie wiem jak reagować na takie sytuacje , nie wiem czy to jest normalne, że po roku zdarzają mi się takie błędy. Jeśli ma ktoś sprawdzone jakieś wzorce zachowań, komunikacji w takich sytuacjach prosił bym o ich przedstawienie.

Podziękować za znalezienie bugu. Naprawić. Zastanowić się, czy nie da się czegoś zmienić w swoim zachowaniu (komunikacji, kodowaniu) by unikać takich bugów w przyszłości. Jeśli wymyśliło się rozwiązanie, wbić je sobie do głowy. Zapomnieć o tym, że popełniło się tego buga.

Nie należy bugów traktować osobiście. One były, są i będą. Trzeba minimalizować ich występowanie i jak najszybciej je naprawiać. Ale i tak będą się pojawiały, w jakimś stopniu. Nie są niczym nienormalnym. Jak ktoś twierdzi, że dobrzy programiści nie popełniają błędów, to gada durnoty. Dobrzy programiści to wiedzą.

Ja przeważnie, jak ktoś znajduje mój bug -- czasem zawodowy tester, czasem kumpel z zespołu -- to po pierwsze, dziękuję. A po drugie, czasami nawet trochę się z siebie naśmiewam lub mówię "no to ładnie spieprzyłem -- dodawanie 2 + 2 okazało się dla mnie zbyt trudne ;)". Ogólnie, nie robię z tego grobowej atmosfery, a raczej wręcz przeciwnie. I robię to specjalnie -- jestem starszym programistą w zespole i chcę, żeby wszyscy -- szczególnie młodsi stażem pracownicy -- widzieli, że ja też produkuję bugi (bo każdy robi) i że nie staram się tego ukryć. Że czasami owe bugi są one durne. Że nieraz wynikają z tego, że za bardzo się spieszę lub z innych błędów w moim procesie. Że znalezienie buga jest dobre i że wypada za nie podziękować. Ja czasami wręcz gratuluję dociekliwości i piszę testerom "nice pick!", bo np. dzięki temu, że przetestowali jakiś kosmiczny przypadek brzegowy, wykryli poważny błąd w sercu aplikacji, który później, na większym zbiorze danych, przejawiałby się pewnie przy co drugim wywołaniu kodu.

Czasem te błędy wynikają z niedoinformowania. Mimo wszystko wina jest przypisana do mnie.

To też się zdarza! Ale wtedy nie tłumacz się z tego. Nie bezpośrednio. I nie obwiniaj. W ogóle obwinianie jest cholernie nadużywane i w większości przypadków jest idiotyczne i tylko szkodzi.

Powiedz raczej, że wpisałeś w walidatorze błędną wartość, 24 zamiast 23 [czyli oznajmiasz, że przyjmujesz ten fakt na klatę] dlatego, że zajrzałeś do starszej wersji specyfikacji i tam pisali właśnie o 24. Nie byłeś jednak świadom tego, że istnieje nowsza wersja, bo w systemie zarządzania projektami została ona opublikowana pod zupełnie inną nazwą, o czym nikt nie poinformował. W związku z tym proponujesz, by w celu uniknięcia podobnych -- zupełnie niepotrzebnych -- błędów w przyszłości [czyli: zwracasz uwagę, że uniknięcie tego błędu to dla Ciebie banał, bo jednak nie nastąpił z Twojej winy], zawsze korzystać z wersjonowania i po prostu podmieniać plik, a jeśli nie, to żeby dorzucać go z tą samą nazwą i zmieniać tylko przyrostek z numerem wersji [czyli proponujesz rozwiązanie].

Ten scenariusz powyżej oczywiście wymyśliłem jako przykład. Rzeczywiste problemy z komunikacją można jednak często sprowadzić do podobnego schematu.

Tylko ten błędów nie popełnia, kto nic nie robi.