Co was motywuje w pracy, a co was wkurza?

zrobione

Brakuje mi pola do dodania czegos wlasnego

Spoko ankieta. Kiedy będzie dostępny jakiś raport?

Mnie strasznie wkurza jak ktoś ma brudne (i śmierdzące) skarpety.
Na drugim miejscu ludzie którzy przełączają klimę.
Potem ci którzy wchodzą do salki spotkań sami i gadają przez telefon przy otwartych drzwiach naprzeciwko mnie.
A na końcu ci co ignorują warningi i komunikaty generowane przez kompilator itp narzędzia.

MichalTHEDUDE napisał(a):

Spoko ankieta. Kiedy będzie dostępny jakiś raport?

Michał pracuję nad tym, chciałabym jednak wypuścić to z artykułem, czyli prócz podsumowania trochę konkretów zebranych z rynku jeszcze umieścić.
Wkleję tutaj rezultaty. Chwila cierpliwości ;)

PS dzięki!

W sumie nie wiem czy ktoś wspomniał :) ale ogólny burdel w kodzie mnie wkurza cytując klasyka Halucynacja, hemoglobina, dwutlenek węgla, taka sytuacja. A tak na poważnie - to dbanie o standard kodu to przecież główny filar naszej pracy. W ankiecie chyba nie było pytania o to czy motywuje/demotywuje nas jakość kodu w projektach.

Mnie wkurza, ze wszystko jest po angielsku, nawet maile miedzy polakami albo ta ankieta.

na drugim miejscu nietechniczni managerowie.

Najbardziej mnie demotywuje to, czego nie widać z perspektywy kierownictwa czy HRu, albo co wynika z braku porozumienia między programistami a kierownictwem.

• zły kod w projektach. Bierze się on albo z kiepskiego zarządzania projektem (nacisk ze strony kierownictwa na szybkość, zamiast na jakość) albo z powodu zatrudniania słabych programistów - słaby programista nie napisze dobrego kodu, bo nie będzie umiał. Czyli: zatrudniajcie dobrych programistów, którzy piszą dobry kod, a nie słabych.
• nierealne oczekiwania kierownictwa. PMowie nie siedzą w kodzie, więc oczekują zrobienia danej funkcjonalności w tydzień, nawet jeśli jest to robota na miesiąc.
• zła komunikacja, brak jasnych wymagań, taski które nie są jasno zdefiniowane.
• zasady pracy, które miały pomagać a przeszkadzają - klasykiem są randomowe faile buildów w Jenkinsie, które uniemożliwiają zmerdżowania gałęzi do mastera. Albo wymóg że "każdy commit musi być zaakceptowany na code review" co może się skończyć sytuacją, że niektóre commity będą wisieć całe tygodnie, bo inni programiści będą zbyt zajęci, żeby zrobić code review. Także zasada, że zaplanowanego sprintu nie da się zmienić (np. dodać task/usunąć w trakcie sprintu) też jest debilna, bo nie pozwala na elastyczność w trakcie sprintu. Produktywność spada na rzecz zachowywania zasad.
• planowanie tasków w sposób czysto biznesowy, bez myślenia o implementacji. Często jeden biznesowy ficzer (np. "zrobić widok panelu klienta po zalogowaniu") to z perspektywy programisty z 10 zadań, które trzeba wykonać, żeby to osiągnąć (bo, np. autoryzacja nie jest do końca zrobiona, bo np. panel klienta składa się z 5 podwidoków, które trzeba osobno zakodować itp.). Tak więc myślę, że należałoby jakoś pogodzić wymogi biznesowe z rzeczywistością programistyczną, a nie że "1 wymóg biznesowy = 1 task". A w modelu pracy na zasadzie ticketów/tasków/issues (jaki obowiązuje w wielu firmach) sam podział na zadania odgrywa bardzo dużą rolę (rodzi to potem nieporozumienia - jeśli PM nie ma świadomości problemów technicznych - on będzie widział, że to jest "ficzer" a nie będzie widział, że tak naprawdę biznesowy "ficzer" to z 10 różnych zadań na poziomie implementacji i zamiast zrobić 10 zadań w backlogu, robi się 1 a potem chamsko się dopisuje kolejne subtaski.

ja bym jeszcze dodał te poranne/popołudniowe godzinne spotkania na których i tak nie pada nic konstruktywnego, a są zwyczajną stratą czasu, z pytaniami w stylu
" a co ty zrobiłeś/ zrobisz dziś dla firmy"
czy motywacyjnymi breloczkami, długopisami, pączkami, czy zdjęciami na tablicy korkowej "on dziś zrobił 300% normy"
przypomina mi się mem z tym ludkiem w płonącym pokoju, mówiącym "This is fine"
:)

Mnie denerwuja ludzie ktorzy nie potrafia sobie sami okreslac taskow krotko i dlugoterminowych i pchac projektu samemu do przodu w oparciu o pomysly. Denerwuja mnie ludzie ktorym trzeba powiedziec ze musisz zrobic to, to i to i hu i tyle. Kop odtad dotad z klapkami na oczach i nie patrz na boki.

I jeszcze bus factor bym dodał. Sytuacja kiedy od jednej osoby (Tego czy akurat się pokaże w pracy, czy będzie mieć urlop albo ważne spotkanie itp.) zależy cały projekt.

• Np. admin/devops, który musi dać komuś uprawnienia do repo, postawić Jenkinsa, zreperować serwer czy zrobić inną magię niezbędną do pracy. Dopóki tego nie zrobi, nic się nie da zrobić z projektem.
• Kolega który zna projekt od podszewki (a w projekcie nie ma dokumentacji, więc o wszystko trzeba pytać osoby, które dłużej siedzą w projekcie). Jednak tego dnia się nie pojawia w pracy i nie da się bez niego pracować (skoro to właśnie on jest chodzącą dokumentacją).
• Szef, który musi podjąć jakąś ważną decyzję związaną z projektem, ale akurat jaśnie pana nie ma w firmie i nie wiadomo kiedy będzie.
• Graficzka, który musi dostarczyć grafiki albo design do jakiegoś widoku. Bez tego nie wiadomo nawet jak to powinno wyglądać.
• Programista, który musi wystawić API, żeby dało się pobrać jakieś dane. Jednak z jakiegoś powodu tego jeszcze nie zrobił i nie wiadomo co robić (można podstawić jakieś fałszywe dane - ale to nie zawsze ma sens). Albo programista, który robi moduł X też nie wiadomo dlaczego go nie zrobił (a moduł X jest potrzebny do zrobienia przeze mnie modułu Y, który będzie korzystał z modułu X). Oczywiście, można zamockować - i czasem ma to sens, ale czasem to taka zabawa na sucho.

Czyli ciągła zależność od innych osób, którzy zwykle nawalają. Strasznie demotywuje.

gjab napisał(a):

Mnie wkurza, ze wszystko jest po angielsku, nawet maile miedzy polakami albo ta ankieta.

na drugim miejscu nietechniczni managerowie.

Jest po angielsku nie dla szpanu ale datego, że badane uwzględnia różne terytoria.

mnie wkurza:

• niechęć do wdrażania nowych technologii
• zadania dla samych zadań a nie dla efektów
• gwałcenie zasad dobrych praktyk kodzenia w R (np. linijki z ilością znaków > 80 czy programowanie proceduralne, podczas gdy R wspiera funkcyjne)
• że o podwyżki trzeba się dopominać a powinno być to automatycznie wyliczane
• rozmawianie przez telefon w pracowni
• głośne gadanie o głupotach w pracowni, bo to rozprasza mocno
• ploty
• nie mówienie "cześć"
• szukanie problemów tam gdzie ich nie ma
• ciągłe przekładanie spotkań i terminów
• zamiast zwiększyć pensję i dodać każdemu po trochu pracy, to firma woli zatrudniać nowe osoby i potem siedzimy i oglądamy jutuba przez pół dnia
• spotkania z których nic nie wynika
• ignorowanie potęgi statystyki matematycznej przez zarząd wysokiego szczebla, który o statystyce nie ma zielonego pojęcia i słuchają nie tych co mówią rozsądnie tylko tych co mają największą charyzmę
• rozpieprzanie ogromnej forsy na imprezy integracyjne, a przecież przyjaciół poznaje się w biedzie i na trzeźwo.

• Obiecanki - juz nie chodzi mi o nie wiadomo jakie, ale przez pol roku w pierwszej pracy (nadal tam jeszcze pracuje) mowiono mi ze dostane mentora (senior), moja kariera bedzie jakos pokierowana, tym czasem uwazam, ze przez pol roku mojej pracy po prostu bylo zmarnowane, nie wiadomo bylo co ze mna zrobic tak naprawde. Teraz jestem w zespole i dopiero teraz cos sie rozkrecarz

• Osoba / osoby, ktore jak potrzebujesz pomocy to nigdy nie podejda, tylko Ty musisz isc do nich, nawet Ci nie odpisza, a trzeba to zrobic na Twoim kompie. A potem odpowiadaja w stylu "No wiesz, nie wiem jak Ty masz to skonfigurowane". Jakos inni potrafia podejsc i pomoc, a tez sa zajeci. Denerwuja mnie takie osoby na maxa.

• Wymagania biznesu - przyslowiowo biznes "wpada" i podaje pewne wymaganie. Praca idzie w ruch, po kilku tygodniach przy review sie okazuje, ze to nie jest wazne biznesowo, na dodatek trzeba rzezbic nie maja konkretych wymagan (nieogar totalny)

• W kwestii finansowej i szacunku (z perspektywy tam gdzie pracuje i jako junior) - wymaga sie wiekszego zaangazowania, by dostac podwyzke. c**j, ze konczy sie projekty, ktore niby sa b.wazne, wymaga sie sporej wiedzy (jak za taki marny hajs), kolega SEO zarabia tyle co ja, a ja musze znac naprawde sporo rzeczy. Mowi sie o ujednoliceniu poziomu developerow (jakos moja pensja nie rosnie, a skille rosna, a senior zarabia 5x tyle co ja). Przy projekcie popelniono blad od podstaw, teraz na moich barkach (ale nie tylko) stoi przerobienie systemu - mam robic takie wazne rzeczy dla core'owego projektu z pensja magazyniera ?

Ostatnie mocno osobiste, ale gdzies musialem to napisac.

Najgorszą rzeczą jaką mnie wkurza to leniwy, głupszy od klienta PM + nie ogarnięci koledzy z pracy. O ile problemy z pieniędzmi, befefitami, projektami można załatwić dobrze napisaną umową to brak kompetencji współpracowników jest ciężko zmienić. Tym badziej to wkurza, że tacy ludzie często pracują w firmach z dobrą renomą

Motywują mnie nowe technologie. Wkurza mnie jak jest nuda i monotonia.

Dobra kawa, klimatyzacja w lecie, fajny zespół też powoduje, że chce się iść do pracy.

Na moim niskim szczeblu kariery motywuje mnie forsa i możliwość rozwoju, a denerwują mnie dziwne procesy rekrutacyjne i czasochłonne zadania rekrutacyjne.

LukeJL napisał(a):

Najbardziej mnie demotywuje to, czego nie widać z perspektywy kierownictwa czy HRu, albo co wynika z braku porozumienia między programistami a kierownictwem.

• zły kod w projektach. Bierze się on albo z kiepskiego zarządzania projektem (nacisk ze strony kierownictwa na szybkość, zamiast na jakość) albo z powodu zatrudniania słabych programistów - słaby programista nie napisze dobrego kodu, bo nie będzie umiał. Czyli: zatrudniajcie dobrych programistów, którzy piszą dobry kod, a nie słabych.
• nierealne oczekiwania kierownictwa. PMowie nie siedzą w kodzie, więc oczekują zrobienia danej funkcjonalności w tydzień, nawet jeśli jest to robota na miesiąc.
• zła komunikacja, brak jasnych wymagań, taski które nie są jasno zdefiniowane.
• zasady pracy, które miały pomagać a przeszkadzają - klasykiem są randomowe faile buildów w Jenkinsie, które uniemożliwiają zmerdżowania gałęzi do mastera. Albo wymóg że "każdy commit musi być zaakceptowany na code review" co może się skończyć sytuacją, że niektóre commity będą wisieć całe tygodnie, bo inni programiści będą zbyt zajęci, żeby zrobić code review. Także zasada, że zaplanowanego sprintu nie da się zmienić (np. dodać task/usunąć w trakcie sprintu) też jest debilna, bo nie pozwala na elastyczność w trakcie sprintu. Produktywność spada na rzecz zachowywania zasad.
• planowanie tasków w sposób czysto biznesowy, bez myślenia o implementacji. Często jeden biznesowy ficzer (np. "zrobić widok panelu klienta po zalogowaniu") to z perspektywy programisty z 10 zadań, które trzeba wykonać, żeby to osiągnąć (bo, np. autoryzacja nie jest do końca zrobiona, bo np. panel klienta składa się z 5 podwidoków, które trzeba osobno zakodować itp.). Tak więc myślę, że należałoby jakoś pogodzić wymogi biznesowe z rzeczywistością programistyczną, a nie że "1 wymóg biznesowy = 1 task". A w modelu pracy na zasadzie ticketów/tasków/issues (jaki obowiązuje w wielu firmach) sam podział na zadania odgrywa bardzo dużą rolę (rodzi to potem nieporozumienia - jeśli PM nie ma świadomości problemów technicznych - on będzie widział, że to jest "ficzer" a nie będzie widział, że tak naprawdę biznesowy "ficzer" to z 10 różnych zadań na poziomie implementacji i zamiast zrobić 10 zadań w backlogu, robi się 1 a potem chamsko się dopisuje kolejne subtaski.

zła komunikacja, brak jasnych wymagań, taski które nie są jasno zdefiniowane. - to jest NAJGORSZE co może być!! Totalne rozwalenie porządku pracy, zero organizacji, czasem syzyfowa praca zupełnie od początku!

Hej dzięki za Wasze opinie - nie spodziewałam się aż takiego zaangażowania.
Jesteście świetni!
ja natomiast postaram się zrobić fajny kawałek wiedzy dla kadry managerskiej
By żyło się lepiej. :)
Dzięki wielkie !

PS Jeżeli ktoś jeszcze nie wypełnił ankiety - to jeszcze w tym tygodniu zbieram dane ;)

fozolif napisał(a):

Mnie denerwuja ludzie ktorzy nie potrafia sobie sami okreslac taskow krotko i dlugoterminowych i pchac projektu samemu do przodu w oparciu o pomysly. Denerwuja mnie ludzie ktorym trzeba powiedziec ze musisz zrobic to, to i to i hu i tyle. Kop odtad dotad z klapkami na oczach i nie patrz na boki.

LOL takie rzeczy to chyba tylko w startupach. W dojrzałych firmach dostajesz listę tasków od klientów/biznesu i z tego jesteś rozliczany. Własne pomysły nie wszędzie są mile widziane, a tam gdzie są, to muszą być realizowane zgodnie z narzuconymi celami rocznymi i misją firmy, po akceptacji góry. Oprócz tego nie można robić nic, co nie przyniesie zysku firmie. Jako zysk rozumiem dodatkowy przychód, mniejsze koszty lub oszczędność czasu. Zatem refactoring kodu, który działa i nie narzeka na niego biznes, nie jest mile widziany, podobnie dodawanie funkcjonalności, za które nikt nie zapłaci.

I dlatego bardzo często dojrzałe firmy dają się tak łatwo wygryźć z rynku startupom :P

Planowanie produktu wyłącznie przez ludzi, którzy nie mają styczności z kodem, jest suboptymalne i zwykle się nie udaje.

Programista / architekt: zwykle wie, co technicznie można zrealizować i jakim kosztem; nie zawsze wie, czego chce biznes
Product manager: zwykle wie, czego chce biznes, ale nie zawsze wie, co się da zrealizować i jakim kosztem; czasem miewa nierealistyczne pomysły, a czasem odwrotnie - nie wie, że jakiś potrzebny ficzer można zrobić w godzinę.

Dlatego planowanie produktu należy robić przy udziale obydwu stron i dbać o obustronną komunikację.
U nas przytłaczająca liczba ficzerów jest z inicjatywy oddolnej, a pomysły z góry też są zawsze konsultowane z programistami.

Oprócz tego nie można robić nic, co nie przyniesie zysku firmie

Zakładając, że nie ma się programistów o ujemnej produktywności lub złośliwców psujących kod, każda rzecz przynosi jakiś zysk firmie. Pozostaje kwestia priorytetyzacji.

Poza tym programista to nie maszyna, która robi stałą liczbę np. 5 ficzerów na sprint i jak zaplanujesz 2 ficzery więcej, to musisz zrezygnować z 2 innych.
Jeśli programistom dasz do roboty coś, czego nie lubią i czemu wewnętrznie się sprzeciwiają, to będą to dłubać przez 2 lata i wyjdzie z tego jakiś korporacyjny syf. Jeśli pozwolisz im pracować nad tym co lubią, i tylko trochę to ukierunkujesz, to nagle może się okazać, że ten sam zespół ma 10x większą produktywność.

Jeśli programistom dasz do roboty coś, czego nie lubią i czemu wewnętrznie się sprzeciwiają, to będą to dłubać przez 2 lata i wyjdzie z tego jakiś korporacyjny syf.
Jeśli pozwolisz im pracować nad tym co lubią, i tylko trochę to ukierunkujesz, to nagle może się okazać, że ten sam zespół ma 10x większą produktywność.

Cóż, ty to wiesz, ja to wiem, ale biznes czy korpoludki wiedzą swoje. Tego nie da się raczej wyleczyć.

Programiści nie są po to w firmie żeby robić to co lubią, tylko po to aby wytwarzać produkt który firma może sprzedać. Gdyby nie było zapotrzebowania na takie produkty to świat miałby ich w dupie a oni 'robiliby to co lubią' w piwnicy u mamy. Nie zmienia to oczywiście faktu że planowanie rozwoju produktu bez konsultacji z programistami (choćby dla oceny realności terminów) jest patologią.

Wkurzają mnie imprezy integracyjne. Ogólnie lubię śmieszkować i rozmawiać z ludźmi w pracy, ale mimo wszystko nadal jestem introwertykiem i nienawidzę imprez, tym bardziej że gardzę jakimkolwiek alkoholem.

co sprawia, że pracuje Wam się komfortowo

$$$

co Was deweloperów wkurza i demotywuje

brak $$$

1. Tytuły stanowisk
   Idziesz do firmy, słyszysz że ktoś jest "senior chief operating officer", dowiaduje się że on tylko taski przebija i nie ma mocy decyzyjnej. Potem spotykasz "technical support managera" i dowiadujesz się że to tak naprawdę pracownik drugiej linii helpdesku. Itp., itd.

2. Ludzie nie rozumiejący roli w projekcie. Testerzy i QA regularnie wpieprzają się w buty analityków i projektantów. To może działać jeśli ktoś wie jak działa biznes i organizacja ale osoby po mniej niż roku pracy też tego próbują. Podobnie może się zdarzyć wśród programistów, analityków, business ownerów itp.

Nieprzyjazne biura - za glosne, za zimne/za cieple, swietlowki i to ze przewaznie instalacje sa tak zrobione ze nie da sie punktowo zgasic. Open space.

WhiteLightning napisał(a):

Open space.

Zależy co rozumiemy przez „open space”.

Moim zdaniem pokoje powinny mieć od 5 do 15 osób podzielonych „tematycznie”: programiści z programistami, graficy z grafikami, testerzy z testerami i papierkowi z papierkowymi. Podział powinien być też według projektów, czyli programiści jednego projektu powinni siedzieć w jednym pokoju, a innego w innym.
Wszystko to oczywiście w miarę możliwości.

Absolutnie nie powinni siedzieć tak wszyscy razem zusammen do kupy. To nie kamieniołom.

Pracuje z was ktoś tak? http://www.forbes.pl/g/i.aspx/1200/0/forbes/635163049893986381.jpg dla mnie to wydaje się horror, ale jeszcze gorsze są chyba boksy.