Na podstawie samego tylko tego opisu, nie jestem w stanie stwierdzić kto jest ofiarą a kto nie.
Ja nie proszę o ocenę kto jest ofiarą, bo z oczywistych powodów nie mogę tutaj przedstawić szczegółów, ani tym bardziej dowodów, ale uwierz mi, że dowody mam.
Może Ty, może zespół w którym pracowałeś.
Uważam, że ucierpiał cały zespół. Generalnie zarówno działania kontraktorni, jak i tego seniora uważam za szkodliwe dla zespołu jako całości, bo jak byś się czuł, gdybyś wiedział, że rozmowa z innymi członkami zespołu jest w firmie uważana za niesamodzielność, a twój znajomy doświadcza przemocy ze strony członka zespołu w którym jesteś?
Co do tej "niesamodzielności", to autentyczny przypadek z tej kontraktorni: próbowaliśmy wspólnie z innym członkiem zespołu użyć jednej z funkcji napisanej przez tamtego seniora, ale nie byliśmy w stanie. Finalnie okazało się, że funkcja napisana przez seniora nie działa. Ale próba skonsultowania z seniorem użycia jego funkcji to w tej kontraktorni "niesamodzielność", więc mamy sami się męczyć.
Bonus: po dość długim wspólnym debugowaniu zdecydowaliśmy się zapytać seniora. Senior-frustrat (autor niedziałającej funkcji) nie mógł znieść, że jego funkcja nie działa i najpierw odpowiedział "Ale macie konkretny problem do rozwiązania, czy piszecie kod mający za zadanie użyć wszystkich funkcji w projekcie"? Później nieco spuścił z tonu, ale do błędu się nie przyznał, napisał tylko, że kompilator dziwnie się zachowuje i trzeba to przeanalizować.
Jak byś funkcjonował w zespole w którym jest ktoś, kto próbuje nieustannie się do czegoś u ciebie przyczepić, dla którego to zawsze winni są inni (i ten złośliwy kompilator...), a jego kod jest zawsze idealny (mimo że np. porównuje obiekty w C++ za pomocą memcmp, nie zwalnia zaalokowanych zasobów i używa wskaźników do nieistniejących obiektów).
To mi trochę nie pasuje, bo z reguły osoby które faktycznie są dojeżdżane w firmach, raczej nie zmieniają dwa razy projektów. To (w mojej) opinii robią osoby, które muszą dostać to czego chcą, a jak nie to bojkotują i rzucają papierami.
A czy to ma jakiś związek ze tematem? Podpowiedź: nie, nie zmieniałem dwukrotnie projektu, niczego nie bojkotowałem.
Najpierw nakłamali w rekrutacji, później jeszcze pojawił się ten przemocowiec w zespole, więc zmieniłem projekt. Przedstawiając mi drugi projekt, też nakłamali, więc po kilku miesiącach złożyłem wypowiedzenie.
Jednozdaniowe opisy zadań to jest coś zupełnie powszechnego, więc nie sądzę że możesz się tym bronić.
Chyba jednak nie są takie powszechne, może w januszeksach chcących zrobić szybko i byle jak, bo jednak opisy tasków to jest podstawa komunikacji oczekiwań wobec programisty.
A co powiesz na to, że w drugim projekcie nie było żadnego systemu zarządzania ticketami, a szczegóły tasków były najczęściej przekazywane "na gębę"?
Nie tylko dokumentacja tasków była problemem. Do tej pory pamiętam jak jeden z doświadczonych członków zespołu z rozbrajającą szczerością przyznał kiedyś w rozmowie ze mną, że praca nad projektem odbywa się metodą prób i błędów, oraz że nie rozumie działania własnego commitowanego kodu.
Zresztą w Polsce powszechny jest też np. widok pijanych żuli w parkach i walające się wszędzie butelki, ale powszechność zjawiska nie oznacza, że jest ono dobre. Dotyczy to i jednozdaniowych opisów tasków, i żuli w parkach.
Używanie takich określeń jak "przemocowego zachowania" też raczej nie świadczy dobrze o Tobie, bo sugeruje nie chęć obrony siebie, tylko chęć wywarcia jakiegoś wpływu.
Dlaczego ma nie świadczyć dobrze o mnie, skoro to ten senior zarzucał mi passive-aggressive i robił to właśnie w celu wywarcia na mnie wpływu? Zresztą nie była to jego jedyna zagrywka, robił to wielokrotnie, więc o co Ci chodzi?
A jako, że agresja w celu wywarcia na mnie wpływu = przemoc, więc mam pełne prawo twierdzić, że doświadczyłem przemocy.
Olej sprawę całkowicie, znajdź inną pracę, i postaraj się następnym razem dopasować do zespołu w którym pracujesz.
Przecież napisałem, że już dawno sobie znalazłem nową.
Pomyśl, że być może w starej pracy mieli rację, i postaraj się być bardziej samodzielny,
A co byś mi doradził w zakresie mojej samodzielności, biorąc pod uwagę że jestem programistą?
i być może nie wrzucaj kodu z błędami do mastera
Jakie nie wrzucaj kodu z błędami do mastera? Ja nie proponowałem wrzucania wszystkiego jak leci do mastera, ani tym bardziej nie wrzucałem tam kodu z błędami.
Zdajesz sobie sprawę, że to ten senior wymyślił z tym masterem jako rzekomo moje?
Akurat co do kodu z błędami, to w masterze było tego dużo, ale nie było to moje. Zarówno niedziałająca funkcja, o której pisałem, jak i kod używający wskaźnika do zwolnionego obiektu były w masterze, ale był to kod tego nieszczęsnego seniora. Oba problemy zostały wykryte przeze mnie, więc może dlatego tak na mnie wsiadał.
Pewnym wyjątkiem jest wspomniana kwestia zwalniania zasobów: napisałem kod zwalniający uprzednio zaalokowane zasoby, ale najpierw problematyczny senior miał z tym problem że zwalniam te zasoby, później drugi senior stwierdził, że zwalniania zasobów nie ma w scope, próbowałem się sprzeciwiać, jednak finalnie kazano mi usunąć mi zwalnianie zasobów i w takiej postaci kod trafił do mastera.
na wszelki wypadek, gdyby okazało się że jednak nie masz racji - wtedy Ci to wyjdzie na dobre.
Biorąc pod uwagę, że później dowiedziałem się, że nawet klient stwierdził, że jest zrobione tak źle, że kontraktornia ma poprawiać za darmo, to jednak chyba miałem rację, tylko nie miałem siły przebicia :D