Aktywne Wpisy
Lolenson1888 +21
Uwaga konkurs
Kupię dowolny, wybrany prezent na Mikołaja każdej osobie, która poda mi jakąś zaletę Minety Rajovicia (oprócz wysokiego wzrostu)
#mecz
Kupię dowolny, wybrany prezent na Mikołaja każdej osobie, która poda mi jakąś zaletę Minety Rajovicia (oprócz wysokiego wzrostu)
#mecz
źródło: 416dfff53e18b9d3eec9d369076a71cd31fa9c9e7bcee53db0990c11fb192167
Pobierz
SereneCipher +1
W jaki mało inwazyjny sposób zabić kogoś w książce? Że niby przypadek itp Bo pisze pisze i muszę się pozbyć typa i nie wiem jak.
1. Ośmieszanie kodu lub osoby
• „Kto ci pozwolił coś takiego napisać?”
• „To wygląda jak kod juniora po trzech piwach.”
• „Masz w ogóle pojęcie, jak działa Python?”
Często w komentarzach do code review lub na spotkaniach publicznie.
⸻
2. Wymuszanie „jedynie słusznych” rozwiązań
• Każde rozwiązanie inne niż lidera jest „złe”, nawet jeśli poprawne.
• Brak miejsca na styl zespołowy lub dyskusję.
• Argumentacja: „Bo ja tak robię od 10 lat” zamiast „bo standard X to rekomenduje”.
To niszczy kulturę inżynierską i blokuje rozwój zespołu.
⸻
3. Publiczne krytykowanie lub ośmieszanie na spotkaniach
• Wyciąganie błędów na daily, retrospektywach, czy przed klientem.
• Robienie z błędów innych „żartów”.
• Wyraźny ton wyższości.
To już klasyczna forma upokorzenia publicznego.
⸻
4. Sabotowanie wkładu innych
• Odrzucanie PR/merge requestów bez sensownego powodu.
• Ignorowanie zgłoszonych pomysłów.
• Nadpisywanie cudzych commitów bez konsultacji.
Osoba traci poczucie wpływu na projekt.
⸻
5. Nadmierne micromanagement w sferze technicznej
• Lider „siedzi na plecach” i komentuje każdy detal.
• Nie pozwala nikomu podjąć samodzielnej decyzji.
• Każdy plik musi być „po jego myśli”.
To nie mentoring, to kontrola i brak zaufania.
⸻
6. Podważanie kompetencji bez podstaw
• „Nie rozumiesz tego, więc nie możesz dotykać tego modułu.”
• „Lepiej zostaw to komuś bardziej doświadczonemu.”
• Zlecanie tylko prostych, „bezpiecznych” zadań jednej osobie.
To subtelna forma izolacji i degradacji.
⸻
7. Ironia i pasywna agresja
• Komentarze typu: „Ciekawe podejście… odważne, ale niepraktyczne.”
• „Zabawne, że to w ogóle działa.”
Taki ton rozbija zespół i buduje lęk przed feedbackiem.
⸻
8. Celowe tworzenie niejasnych wymagań lub reguł
• Lider zmienia standardy w trakcie projektu.
• Nie ma spisanego style guide, ale ciągle „czepia się stylu”.
• Każda decyzja jest arbitralna i zależy od jego humoru.
Efekt: inni czują się niekompetentni, choć zasady są niejasne.
⸻
Skutki technical bullyingu
• Spadek motywacji i kreatywności,
• Strach przed code review,
• Unikanie własnych pomysłów,
• Poczucie, że „i tak zawsze robię źle”,
• Ostatecznie: chęć odejścia z zespołu lub zawodu.
@login-znaki-alfanumeryczne: Nie ma chyba lepszego określenia XDD
Aż mi się przypomniała akcja jak na początku kariery aplikowałem na staż w CCC no i na technicznej rozmowie trafiło mi się takich trzech niewyżytych k---------y co chcieli pokazać jak to oni nie są ogarnięci, no i pytali mnie z takich gówien gdzie nawet teraz bym nie wpadł na takie pytania przy rekrutowaniu kogoś, a to był staż XD
Po 15
@Nighthuntero: gratuluję refleksu, żałuję że nie zrobiłem tego samego jednemu dziadowi z Ericsonna