Jak w temacie. Czy programistom ktorzy maja juz trochę doświadczenia to sie moze przydarzyc czy raczej nie spotkaliscie takich przypadkow?
Pytam bo zmienialem niedawno prace (z miesiąc temu), część technologii jest dla mnie nowa, a system ktory byl tworzony przez lata bardzo zawiklany. Wolno mi idzie wdrozenie sie, a mam wrazenie ze z racji doświadczenia wymagaja ode mnie więcej.
W tej chwili rozwazam pracę po godzinach by się utrzymać na tym miejscu, robicie tak jak nie ogarniacie na początku? Czy prosto wam idzie wdrazanie sie?
Generalnie to moja pierwsza grubsza zmiana pracy, w poprzedniej bylem kilka lat od poziomu total juniora, więc mieli cierpliwosc - tu boje sie ze bedzie inaczej.
Głównie chodzi mi czy jak pracownik okazuje się wolniejszy niż zakładali to czy bardziej sa skłonni dać mu jeszcze troche czasu czy raczej szybko sie z nim pożegnać bo każda godzina to kasa?
Dobra, a podstawowe pytanie: czy rozmawiałeś o tym w firmie? Przegadałeś problem ze swoimi przełożonymi?
To jest tylko Twój subiektywny odbiór sytuacji, czy oni też uważają, że wdrażasz się znacznie wolniej i mniej ogarniasz, niż inni członkowie ekipy, kiedy oni się dołączali do projektu?
gvim napisał(a):
W tej chwili rozwazam pracę po godzinach by się utrzymać na tym miejscu, robicie tak jak nie ogarniacie na początku? Czy prosto wam idzie wdrazanie sie?
Nie obraź się ale to chyba już drugi temat czy który z kolei że ktoś mówi że musi pracować po godzinach bo coś tam. To że tak Ci idzie to nie jest Twoja wina. Za proces wdrażania odpowiada firma i to że jeszcze nie ogarniasz to po prostu mów managerowi. Oni mają płacone za to by rozwiązywać takie problemy.
Dlaczego masz za darmo tracić swój własny czas? Przez takie coś będzie tylko gorzej.
Bądź transparentym z managerem, szczególnie w pracy zdalnej jak nie widać ile się siedzi.
tak, po trzech miesiącach jeden z moich współpracowników dostał ostrzeżenie i zostałem wtedy osobiście przypisany do weryfikacji jego postępów i wdrożenia przez kolejne trzy miesiące. Po kolejnym miesiącu dostał wypowiedzenie, nawet nie dotrwał do końca okresu weryfikacyjnego.
chłop miał z 4-5 lat expa
cerrato napisał(a):
Dobra, a podstawowe pytanie: czy rozmawiałeś o tym w firmie? Przegadałeś problem ze swoimi przełożonymi?
To jest tylko Twój subiektywny odbiór sytuacji, czy oni też uważają, że wdrażasz się znacznie wolniej i mniej ogarniasz, niż inni członkowie ekipy, kiedy oni się dołączali do projektu?
Nie chce im sugerować, czekam aż pierwsi się odezwą
Nie chce im sugerować, czekam aż pierwsi się odezwą
Bardzo niedojrzała postawa. Jak sam się zgłosisz i powiesz, że masz problem/potrzebujesz pomocy to powinni to docenić - że zachowujesz się odpowiedzialnie, świadomie, angażujesz się i starasz.
A jak poczekasz jak sami się odezwą to raczej przyjdą z pretensjami - że jesteś słaby, nie nadajesz się, zamiast rozmowy i docenienia starań, możesz dostać wypowiedzenie.
Rzadko, ale sie zdarza. Dodatkowo zawsze jest szansa zalapac sie np. na popularne w niektorych firmach zwolnienia grupowe.
Myślę że ludzie są realistami - co możesz wiedzieć o legacy kobyle po 1 miesiącu ? Jak zbudować projekt, dopisać coś do logowania, może napisać jakiś testy dla poprawy code coverage ? Ja też przy pierwszej zmianie pracy wpadłem w taki projekt - wrzucili mnie z nowym gościem co miał 20 lat expa i był w całkiem wielu firmach - obaj całe g..o wiedzieliśmy po miesiącu i juniorzy z tego projektu wymiatali przy nas.
crx napisał(a):
Za proces wdrażania odpowiada firma
a dokłądniej zespół, no, ale kto ma go wdrażać, jak ludzie uważają, że "za to mi nie płacą" albo "od tego jest senior lub proaktywny mid".
Odbębnią swoje i "cyk CSik" albo "cyk 2 etat".
gvim napisał(a):
W tej chwili rozwazam pracę po godzinach
Najgłupszy pomysł. Co wy macie z tą pracą po godzinach? To jest zawsze kręcenie na siebie sznura, będziesz pracował tylko więcej i więcej bo skoro się wyrabiasz, to będą Ci wrzucać więcej.
Po pierwsze: czy masz od kogokolwiek feedback, że idzie Ci za wolno? Czy to tylko Twoje odczucia? Na jakiej podstawie twierdzisz, że idzie Ci wolno? Podaj jakieś metryki. Póki co problem wydaje się być tylko w Twojej głowie.
Po drugie: co to znaczy, że "pracownik okaże się wolniejszy niż zakładali"? W pierwszych miesiącach to będą bardziej patrzeć na Twoją komunikację i zaangażowanie, więc jeśli nie rozumiesz jakiejś części systemu to pytaj, poproś kogoś bardziej wdrożonego o spotkanie itd. Po kilku tygodniach możesz wprost zapytać o feedback i czy hehe chcą przedłużyć umowę. Jeśli by nie chcieli przedłużać to na pewno dadzą znać wcześniej (o ile to nie jakaś januszerka)
gvim napisał(a):
Wolno mi idzie wdrozenie sie, a mam wrazenie ze z racji doświadczenia wymagaja ode mnie więcej.
W tej chwili rozwazam pracę po godzinach by się utrzymać na tym miejscu, robicie tak jak nie ogarniacie na początku?
To jest coś o 180 stopni innego, niż powinieneś zrobić:
powiedzmy, że jesteś programistą w teamie
Programista <---> Team
i wszystko jest fajnie, ale pojawia się problem ponad twoje siły. Ty chcesz go wziąć na bok i samemu rozwiązać. I to oddala cię od teamu:
Problem <---> Programista < - - - - - - - - - - - - - - - - > Team
Ponieważ twoje więzy z teamem stają się słabsze, to może to rodzić nieufność teamu ("nie mogę się z nim dogadać", "on chyba nic nie umie", "on coś się opier*ala i bierze nadgodziny dla niepoznaki") i właśnie to może spowodować to, czego się boisz.
To co powinieneś zrobić, to podzielić się zespołem z teamem i razem go rozwiązać:
Programista <---> Problem <---> Team
Wtedy to przestaje być tylko twój problem. Czyli pół-delegacja zadań (bo jakbyś całe zadanie oddelegował, to też byłoby źle, że sobie nie radzisz).
Natomiast próby rozwiązywania trudnych problemów w teamie samemu nie kończą się dobrze.
W tej chwili rozwazam pracę po godzinach by się utrzymać na tym miejscu,
Skąd pomysł, że jeśli więcej czasu poświęcić, to szybciej ci pójdzie wdrożenie? A nie lepiej zmienić coś w sposobie, w jaki podchodzisz do pracy (szczególnie pracy w zespole)?
Godziny spędzone nad pracą to nie wszystko, a wręcz mogą przynieść odwrotny skutek. Bo im więcej sfrustrowanych godzin spędzonych przy projekcie, tym bardziej będziesz odczuwał zmęczenie, brak skupienia, frustrację, demotywację itp.
Raz wyleciałem po okresie próbnym za obibictwo. Na rozmowie wyjściowej usłyszałem, że gość, co przyszedł miesiąc po mnie, miał w time trackerze nabite 2x tyle godzin, co ja.
Czyli wyleciałeś za uczciwość.
Aktualnie jestem w miejscu gdzie w ciagu 4 miesiecy zwolniono 2 osoby bezposrednio z mojego zespolu.
Nie wiem co o tym myslec: 1 osoba po 1 miesiacu , druga po 3 miesiacach.
Mowa o osobach z doswiadczeniem 4 i 5 lat.
Ktos wpadl na pomysl - "taska wprowadzajacego" tj. ze masz zrobic 1 release na produkcje w ciagu 1 miesiaca - ot takie zadanie sprawdzajace.
No i pierwszy ziomek sie po prostu nie wyrobil... mowil ze zrobi mowil ze zrobi ale nie zrobil ;p wiec polecial...
Drugi sie wyrobil z 1 taskiem ale podobno im dalej w las tym szlo mu gorzej... i uznano ze nie rokuje i tez polecial...
Tez jestem tu nowy wiec srednio co ogarniam.
Pilka w grze i czekamy co dalej... xD
Ale to twoje strachy są jedynie, czy dostałeś jakieś sygnały? Idź jak człowiek do kogoś kto o tym decyduje i powiedz, że minęło ileś tam, chcesz wiedzieć czy spełniasz oczekiwania i jakie są perspektywy. Byłem w projekcie, gdzie bardzo potrzebowali nowego człowieka, bo w ujjjj roboty do zrobienia, po czym przez ponad miesiąc czekałem na dostęp do git'a, a jak już go dostałem, to musiałem się prosić o taski, bo wszyscy tak zarąbani robotą, że nie było kiedy ich rozdzielić.
Spotkałem się z 3 przypadkami, kiedy ktoś poleciał za "wydajność":
- Gość miał dokładnie odwrotne do "get the shit done" nastawienie. Przyszedł do mojego projektu (jako plan naprawczy), dostał zadanie polegające na stworzeniu splash screena w aplikacji mobilnej. Czyli czarny ekran z jakimś tam obrazkiem na środku. po kilku dniach zastanawiał się dalej "jak do tego podejść". Podpytał kilku członków zespołu, dostał właściwie gotowy kod, ale mędził dalej, bo coś tam mu nie pasowało. Akurat nadszedł koniec miesiąca...
- Gość zatrudniony jako jakiś tam ~lead, przez kilka tygodni robił jakąś tam funkcjonalność w aplikacji, nie wrzucał żadnych commitów, na daily mówił codziennie, "no do jutra zrobię, jeszcze jeden drobiazg mi został". Jak w końcu dostał jakieś konkretniejsze zjebki i nakaz wrzucenia tego co ma do repozytorium, to okazało się, że zrobił bardzo niewiele, a i to co zrobił raczej już zostanie na tej gałęzi, na którą wrzucił zmiany.
- Kolejny gość miał totalnie wyrąbane i się z tym obnosił. Kariera zakończyła się chyba po tym, jak puścił "hymn naszego zespołu" naszej manago. Dobra i sympatyczna kobieta, ale tego nie wytrzymała:
Dzięki wszystkim za wypowiedzi. Może faktycznie nadinterpretowuje. Poczekam jeszcze miesiąc i pójdę do kierownictwa a potem dam znać w tym wątku czy jestem lękliwa dupa, czy muszę popracować nad prędkością. Postaram się też nie zamykać z problemem jak mówi LukeJL (choć każdy ma swój task a i przed leadem trochę wstyd męczyć o pomoc mając kilka lat expa)
czy muszę popracować nad prędkością
no przecież jak zespół wycenia zadanie i mieścisz się w tych szacunkach to nie musisz, a jeśli nie nadążasz to ewentualnie wtedy.
I to bardzo ewentualnie. Jesteś w nowym projekcie, nie znasz domeny, nie znasz kodu itd. Męcz kolegów. Jeżeli zespół jest w miarę normalny, to nikt nie będzie miał nic przeciwko wyjaśnieniu ci czegoś przez 15 minut, żebyś zaoszczędził 2 dni.
LitwinWileński napisał(a):
czy muszę popracować nad prędkością
no przecież jak zespół wycenia zadanie i mieścisz się w tych szacunkach to nie musisz, a jeśli nie nadążasz to ewentualnie wtedy.
A na forum tu ktoś pisał że jak się przekracza estymaty tzn że estymaty były złe :P W sumie się z tym zgadzam, ale scrum masterzy i team leadzi niekoniecznie :P
@gvim: Moja hipoteza jest taka, że forum mocno wypacza rzeczywistość. Większość z nas pracuje w normalnych projektach, z normalnymi ludźmi, zdarzają się jakieś drobne upierdliwości. Ale o tym nikt nie pisze, bo co tu pisać, jak zadania są normalnie rozpisane, wyceniane (albo nie wyceniane), ludzi nie rozlicza się ze story pointów i nie sprawdza, szpiegami, czy na zdalnym nie uśpił im się komputer. Piszemy tutaj jak coś pójdzie nie tak, albo bardzo nie tak i łatwo można sobie zbudować wyobrażenie jednej wielkiej patologii.
Skoro cię przyjęli, to byłeś najlepszym kandydatem na jakiego ich stać, więc nie ma się co za bardzo stresować. Widzieli kogo zatrudniają i czego można się spodziewać. Możliwe, że nie mają za bardzo doświadczenia we wdrażaniu nowych ludzi do projektu, a dawanie feedbacku w PL jest raczej mało popularne.
Sam miałem ostatnio taką sytuację, że gość, dla którego jest to pierwsza praca, po roku, przed przedłużeniem umowy, pyta mnie drżącym głosem, jak wypada, bo umowa mu się kończy i czy firma ja przedłuży. Oczywiście moja, team lidera, managera itd. że nikt z nas nawet nie pomyślał o powiedzeniu wcześniej "grejt dżob", bo wydawało nam się to oczywiste. Pracujemy raczej z doświadczonymi ludźmi i wszyscy raczej wiedzą, że jest OK. Trafił się świeży gość, dla którego to pierwsza praca w życiu i daliśmy ciała. Szkoda, że młody się niepotrzebnie stresował.
Dobra rada - idź i zapytaj. Nawet jak się dowiesz, że to koniec przygody, to przynajmniej będziesz wiedział wcześniej. W dodatku wykazanie zainteresowania, to też pokazanie, ze nie masz wszystkiego w dupie, zależy ci na tej pracy, chcesz zwiększać swoją wartość dla pracodawcy. Na 100% sobie tym nie zaszkodzisz. Podejrzewam, że to raczej strach jak przy odebraniu wyników tesu na AIDS, po wycieczce do Tailandii ;)
piotrpo napisał(a):
- Kolejny gość miał totalnie wyrąbane i się z tym obnosił. Kariera zakończyła się chyba po tym, jak puścił "hymn naszego zespołu" naszej manago. Dobra i sympatyczna kobieta, ale tego nie wytrzymała:
Ja bym jeszcze to dodał https://streamable.com/upjjvu
WhiteLightning napisał(a):
Rzadko, ale sie zdarza. Dodatkowo zawsze jest szansa zalapac sie np. na popularne w niektorych firmach zwolnienia grupowe.
O ile jest się na UoP.
A tak apropos pytania autora - miałeś jakiś duży przeskok stawki w związku ze zmianą pracy? Jeśli tak, to może warto co nieco posiedzieć po godzinach, żeby nadrobić braki w nowym stacku, bo jeśli przeskok był spory, to szkoda by było wracać do niższych widełek.
PaulGilbert napisał(a):
A tak apropos pytania autora - miałeś jakiś duży przeskok stawki w związku ze zmianą pracy? Jeśli tak, to może warto co nieco posiedzieć po godzinach, żeby nadrobić braki w nowym stacku, bo jeśli przeskok był spory, to szkoda by było wracać do niższych widełek.
A nie można po prostu przestać myśleć o sobie jako części taniej siły roboczej ze wschodu? Rynek jest globalny, można pracować zdalnie dla firm z zachodu, które płacą w porządnej walucie, mają dobrą kulturę pracy i nie zmuszają do nadgodzin. Nie trzeba brać udziału w wyścigu szczurów, projekty są na ogromne pieniądze, a to nie jest jakaś łaska, że firma ci płaci. Ty ich potrzebujesz, żeby pracować i płacić rachunki, a oni ciebie, żeby firma zarabiała. Nie mówię, że masz się traktować jak księżniczkę, bo trzeba to
wypośrodkować odpowiednio, ale nie można iść w tę stronę, że masz firmie dziękować, bo jest łaskawa płacić ci więcej i siedzieć po godzinach, bo jeszcze cię wywalą. Jak nie oni, to zapłacą inni ¯\(ツ)/¯
Jeśli ktoś wchodzi w nowy stack, to chyba powinien się przyłożyć do nauki przynajmniej trochę...
PaulGilbert napisał(a):
Jeśli ktoś wchodzi w nowy stack, to chyba powinien się przyłożyć do nauki przynajmniej trochę...
Nie odbieraj tego jako jakiś atak, widziałem twoje posty i wiem, że jesteś mądrym gościem.
Po prostu trochę mi przykro i boli mnie dupsko, bo te rady ciągną w dół nowych (w sensie takiego zdrowego podejścia do pracy) programistów, którzy później się nakręcają na nadgodziny. Brzmi to też jak syndrom oszusta - skoro go przyjęli, to znaczy, że potrafi wykonywać robotę za którą mu płacą, a reszty nauczy się w godzinach pracy. Wtedy będzie nam się pracowało przyjemniej
@PaulGilbert: ja do tego podchodze zupelnie inaczej, pracodawca wie ze to dla mnie zupelnie nowy stack i ucze sie tego w pracy, o godz 16 zamykam laptopa niezaleznie czy cos wiecej sie nauczylem czy nie, czy posunalem sie z taskami do przodu. to jest ryzyko pracodawcy a nie moje, jak takie rzeczy byly komunikowane to czas na nauke powinien byc w godz pracy.
zawsze tak do tego podchodzilem i bylem dosc asertywny caly czas i moim zdaniem lepiej na tym wyszedlem zyciowo od ludzi ktorzy siedzieli wieczorami po godzinach.
mam czas na hobby, relax, rodzinę niezaleznie od tego czy technologie w projekcie sa dla mnie nowe czy nie
@tmk3 @kimikini Pewnie macie rację chłopaki.
To moje spojrzenie to pewnie takie trochę za bardzo subiektywne, bo sam generalnie lubię się uczyć i robię to po godzinach i w weekendy.
Syndrom oszusta chyba też mi się właśnie trochę włącza, bo ostatnio dostałem ofertę, która uważam, że mocno przewartościowuje moje talenty. :-)
Ogólnie chciałbym zaapelować też tutaj do ludzi, programistów aby nie robili nigdy darmowych nadgodzin. Nie wiem w ogóle co to ma być. Dzisiaj auto od mechanika odebrałem i na fakturze policzył mi godzinówkę 200 zł brutto, aż mi gały wylazły. Tak samo wróciłem od dermatologa, 15 min konsultacji 300 zł.
A jak widzę że ktoś robi tzw. pro-bono w firmie za free wieczorami to po prostu psujemy sobie nawzajem branże. Pewien portal ostatnio robił taka reklamę na autobusach to widziałem taki napis jak "szanuj się" i to ma mówić by nie aplikować na oferty gdzie nie ma podanych widełek, ale ja sobie pomyślałem właśnie o tym by się szanować także by nie robić za free. Wiadomo pasją pasja, ale miejmy takie wewnętrzne poczucie że pracując po pracy sami na siebie kręcimy bata. Product Owner ze Scrum Masterem tylko się cieszą potem, a w tym samym czasie pewnie grają w squasha. Hehe. Dobranoc.
crx napisał(a):
A jak widzę że ktoś robi tzw. pro-bono w firmie za free wieczorami to po prostu psujemy sobie nawzajem branże.
Może chcą "zachować twarz" i uchronić się przed wstydem, że czegoś nie wiedzą i konsekwencjami utraty pracy.
Ale zamiast się samobiczować, to myślę, że warto spojrzeć na szerszy kontekst. I może trzeba wreszcie to powiedzieć: bycie programista to bardzo trudny zawód i nikt go nie umie dobrze:
- większość programistów nie umie nawet dobrze programować
- jak umieją programować, to mogą nie umieć w inne rzeczy, które są ważne (np. wdrażanie się w nowe projekty to cały osobny skill, komunikacja to też osobny skill itp.)
- programowanie jest zwykle pracą zespołową, więc wystarczy, że team jest dysfunkcyjny w jakiś sposób (np. słabi programiści w teamie napisali tonę spaghetti. Albo seniorzy są nieprzyjaźni albo niepomocni. Albo PM nie umie w zarządzanie zespołami) i już ciężko w takim teamie się odnaleźć.
Czyli w takim systemie bardzo łatwo stać się słabym pracownikiem czy to z własnych braków kompetencyjnych czy z powodu przebywania w dysfunkcyjnym teamie i użerając się z kodem pisanym przez słabych programistów (czy ogólnie użerając się z artefaktami tworzonymi przez osoby mało kompetentne - np. opisy tasków to nie kod, a też mogą być słabo opisane i później spróbuj się domyśleć, o co tam chodziło).
A tutaj mamy tak:
gvim napisał(a):
system ktory byl tworzony przez lata bardzo zawiklany.
czyli to, o czym mówiłem - niekompetentni programiści napisali spaghetti/overengineering i to nie twoja wina.
Wolno mi idzie wdrozenie sie,
jednak to może już świadczyć o twojej nieumiejętności wdrażania się.
a mam wrazenie ze z racji doświadczenia wymagaja ode mnie więcej.
a to o chęci zachowania twarzy, o której wspomniałem, jeśli się przejmujesz, co o tobie myślą inni pracownicy.
więc mieli cierpliwosc - tu boje sie ze bedzie inaczej.
jeżeli nie będą mieć cierpliwości, to lepiej dla ciebie, jeśli cię zwolnią. Czy chciałbyś pracować w takiej firmie, która zatrudnia kogoś do wejścia w zawikłany system i przy pierwszych trudnościach ma pretensje, że wolno mu idzie? Przecież to by pachniało JanuszSoftem na kilometr. Ale jak dobrze rozumiem, to tylko twoje niepotwierdzone obawy.
Dobra mineło kilka miesięcy pracy w firmie.
Jak ktoś jest ciekawy, jak się potoczylo.
To po 2-3 miesiącach wdrożyłem się na tyle że większość tasków mieszcze się w estymacie bez specjalnej spinki.
Początki faktycznie miałem ciężkie z tego względu że chciałem wszystko zrozumieć, a inni wychodzili z założenia by nie zadawać pytań tylko robić ticket.
Teraz okazuje się że osoby pracujące rok, dwa w projekcie przychodzą do mnie z pytaniami.
Dzięki wszystkim za wpis w temacie, Faktycznie nie było sensu się stresować.