Tempo pracy

0

Witam, mam pewną zagwozdkę.
W mojej pierwszej pracy na stanowisku deva patrzono przede wszystkim na prędkość wykonywania tasków. Niestety po 2 misiącach nie przedłużono mi umowy ponieważ byłem za wolny.
Teraz pracuję w firmie gdzie nie ma aż takiego parcia na prędkość. Ale robię przy kobylastym systemie bez dokumentacji, testów, w starej technologii, kod spagetti, marne pieniądze.
Po doświadczeniach z poprzedniej firmy boję się trochę ruszyć dalej aby znów nie trafić do firmy 'byle szybciej', mimo że w aktualnej pracy się nie rozwijam.
Dlatego proszę o opisanie waszych doświadczeń w tym temacie. Jak wygląda ocena pracownika w waszych firmach? Opinie osób które przerobiły już parę zakładów, również były by bardzo cenne.

0

Co z tego, jak ktoś zrobi coś szybko, ale rozwiązanie będzie słabe? Lepiej poświęcić trochę czasu i zrobić coś porządnie, a nie wszystko "na gwałt". Wiadomo, że powinno się ustalić jakiś deadline oraz zakres zadań i poinformować zespół lub przełożonego z wyprzedzeniem, jeśli z jakichś powodów zadanie się przeciągnie. Sam na samym początku starałem się robić wszystko jak najszybciej, ponieważ wydawało mi się, że tak powinno się robić. Dopiero bardziej doświadczone osoby uświadomiły mi, że czasem lepiej poświęcić więcej czasu, przemyśleć rozwiązanie, zapytać innych, co o tym myślą i czy znają lepszy sposób na rozwiązanie problemu, dopracować kod, napisać testy, etc. Nie trzeba będzie potem robić na szybko bug-fixów i stresować się, że coś nie działa, bo nie przewidziałeś jakiegoś przypadku brzegowego.

3

Różne firmy mają różne sposoby na prowadzenie projektów. Jedne ugruntowują swoją pozycję na rynku i robią portfolio, inne chcą się "pokazać" jakie to one nie są szybkie i solidne (czyt. szybkie). Inne mają w dupie wyścigi, robią swój soft lub posiadają mądrego szefa, który wie jak to w życiu bywa i mnoży wszystko (czas znaczy się) jak się da.

Z drugiej strony mamy developera. Są tacy z motorkiem w dupie, co zrobią to samo co ty 3x szybciej. Ja myślałem, że wiele widziałem, ale rzeczywistość mnie nieraz zaskakuje. Ze swojego doświadczenia (w sumie marne 5 lat :P) widzę, że można robić coś szybciej niż reszta mając odpowiedniego skilla i wysoki poziom koncentracji, ale zawsze się znajdzie jakiś człowiek, który i tak robi to samo 2-3x szybciej. Tym nie ma się co przejmować akurat, powoli można się z poziomem podciągać (podglądać jak pracuje) mając takiego na pokładzie.

Pechem (ew. brakiem doświadczenia) można nazwać sytuację, gdy trafia się do firmy, która cię przeciąży, tzn. będzie wymagała absurdalnej wydajności. To jest i tak w większości wina firmy/jej procesu rekrutacji, że nie wyłapali ile umiesz i jak dobrze się czujesz w ich tematach.

Jeśli nie jesteś ultra-wymiataczem, zawsze znajdzie się firma, w której ludzie są jakby z innej bajki, znają (na prawdę znają) dużo technologii i są bardzo dobrzy w tym co robią. Do takiej firmy wg mnie nie ma sensu iść z marszu. Bez skilla po 1. niewiele się z niej wyciągnie dla siebie (nie będziesz w stanie brać udziału w ciekawych dyskusjach itp.), po 2. mogą Cię tam nie chcieć na dłuższą metę. Ew. sam się poddasz i odejdziesz z powodu nadmiernej presji psychicznej.

Ale i tak znacznie więskza szansa, że trafia się do firmy krzak (tzw. Janusz-Soft), więc trzeba byc bardzo ostrożnym i każdy warning podczas rozmowy próbować wycenić i jeśli przekroczy się masa krytyczna warningow/errorów - mówisz NIE bez żalu.

0
Zimny Krawiec napisał(a):

W mojej pierwszej pracy na stanowisku deva patrzono przede wszystkim na prędkość wykonywania tasków. Niestety po 2 misiącach nie przedłużono mi umowy ponieważ byłem za wolny.

Z tego akurat chyba możesz się cieszyć - nabyłbyś w takiej pracy samych złych nawyków.

Zimny Krawiec napisał(a):

Teraz pracuję w firmie gdzie nie ma aż takiego parcia na prędkość. Ale robię przy kobylastym systemie bez dokumentacji, testów, w starej technologii, kod spagetti, marne pieniądze.

Też brzmi słabo - żeby chociaż rozwój albo kasa była, a tu same minusy.

Zimny Krawiec napisał(a):

Dlatego proszę o opisanie waszych doświadczeń w tym temacie. Jak wygląda ocena pracownika w waszych firmach? Opinie osób które przerobiły już parę zakładów, również były by bardzo cenne.

U mnie to było/jest tak:

  • w pierwszej firmie całkiem OK - kasa słaba jak na IT, ale to była moja pierwsza praca w branży, także cieszyłem się, że w ogóle gdzieś się zahaczyłem. Bardzo dużo się tam nauczyłem. Minusem było prawie ciągłe fixowanie bugów, kod średniej jakości, bo tykany przez dziesiątki programistów i brak testów (jedynie manualne przez testerów). Na plus review kodu - można z tego bardzo dużo wynieść, kiedy robi je osoba z kilkuletnim doświadczeniem.
  • obecna praca - duże korpo. Kasa dwa razy większa niż w poprzedniej firmie (a i tak raczej w okolicach średnich zarobków jak na IT), ale poza tym słabizna, brak rozwoju, pomysł na nasz zespół upadł gdzieś po drodze, każdy coś tam sobie skrobie, brak review, brak osób bardziej doświadczonych, od których można by się uczyć. Siedzę, bo mam na głowie kilka prywatnych spraw - jak wszystko pozałatwiam, to spadam.

Co do ocen pracowniczych, to w 1. firmie było to review (było widać czy dbasz o jakość kodu czy kładziesz laskę) i częściowo czas z issue trackera. To drugie akurat było irytujące, bo zliczano z tego czas pracy i trzeba było wpisywać w tickety czas tak, żeby wychodziło te 8h.
W obecnej firmie to nawet nie wiem - chyba menedżer raz na jakiś czas zapyta się reszty zespołu jak im się ze mną pracuje, jak mnie widzą itp. Pomijam już jakieś fikcyjne i bzdurne korpo procesy, które nawet menadżerowie olewają i realizują tylko dlatego, żeby je odfajkować z listy swoich zadań, z których pewnie rozlicza ich ktoś wyżej.

0
wiciu napisał(a):

Co z tego, jak ktoś zrobi coś szybko, ale rozwiązanie będzie słabe?

Hehe, rozumiem Cię, ale piszesz z perspektywa programisty :) A z perspektywy Janusza wygląda to inaczej - robimy szybko, klient jest zadowolony, bo szybko dostał produkt/nowy ficzer/itp., a ja mam kasę. Kod jest słaby, nie do utrzymania, bez testów i bardziej spaghetti niż westerny Sergio Leone? Super, bo będziemy jeszcze przez dłuuugi czas doić klienta za bugfixy i utrzymanie systemu.

Świetny Lew napisał(a):

Jeśli nie jesteś ultra-wymiataczem, zawsze znajdzie się firma, w której ludzie są jakby z innej bajki, znają (na prawdę znają) dużo technologii i są bardzo dobrzy w tym co robią. Do takiej firmy wg mnie nie ma sensu iść z marszu. Bez skilla po 1. niewiele się z niej wyciągnie dla siebie (nie będziesz w stanie brać udziału w ciekawych dyskusjach itp.), po 2. mogą Cię tam nie chcieć na dłuższą metę. Ew. sam się poddasz i odejdziesz z powodu nadmiernej presji psychicznej.

Z tym się całkowicie nie zgadzam - w takiej firmie można bardzo podnieść swoje umiejętności programistyczne właśnie przez pracę z ludźmi o umiejętnościach i wiedzy znacznie większych od naszych. Poza tym jak widzę w firmie takich ludzi, to świadczy także o firmie - musi być całkiem OK, skoro tyle kumatych osób w niej pracuje.

2
lbz napisał(a)

częściowo czas z issue trackera. To drugie akurat było irytujące, bo zliczano z tego czas pracy i trzeba było wpisywać w tickety czas tak, żeby wychodziło te 8h.

Nigdy się nie pracuje pełnych 8 godzin i jeśli ktoś na górze zakłada, że programista przebywając w biurze przez 8 godzin będzie przez 100% czasu rzeczywiście i efektywnie pracować nad taskami, to z pewnością będzie miał dość zafałszowane wyniki.

Zimny Krawiec napisał(a)

W mojej pierwszej pracy na stanowisku deva patrzono przede wszystkim na prędkość wykonywania tasków. Niestety po 2 misiącach nie przedłużono mi umowy ponieważ byłem za wolny.

Cięzko powiedzieć cokolwiek. Może byłeś faktycznie za słaby i za wolny? A może jednak trafiłeś do Janusz Softa?

Jest różnica między sytuacją, gdzie

  1. ktoś chce zrobić porządnie jakiś task i robi go tydzień, ale zrobi go na tip-top(wysoka jakość kodu, testy, doszlifowanie, pofiksowane bugi, dobra integracja z całością projektu etc.), i go Janusze męczą i ściągają do dołu, że lepiej by było zrobić w jeden dzień ale na odczep się

  2. a drugą sytuacją, gdzie junior się męczy tydzień nad taskiem, ale potem okazuje się, że jakość kodu słaba, testów brak, są jakieś bugi, słabo przemyślane i w ogóle prawda jest taka, że to, co zrobił w tydzień ktoś bardziej doświadczony mógłby zrobić w 1 dzień i to lepiej.

Robić coś wolniej od innych może zarówno profesjonalista dbający o jakość, jak i niedoświadczony junior.

Z drugiej strony mamy developera. Są tacy z motorkiem w dupie, co zrobią to samo co ty 3x szybciej. Ja myślałem, że wiele widziałem, ale rzeczywistość mnie nieraz zaskakuje. Ze swojego doświadczenia (w sumie marne 5 lat :P) widzę, że można robić coś szybciej niż reszta mając odpowiedniego skilla i wysoki poziom koncentracji, ale zawsze się znajdzie jakiś człowiek, który i tak robi to samo 2-3x szybciej. Tym nie ma się co przejmować akurat, powoli można się z poziomem podciągać (podglądać jak pracuje) mając takiego na pokładzie.

trzeba dodać jednak, że zadania programistyczne są różne. To, że komuś się motorek załączy przy robieniu jakichś tasków nie znaczy, że będzie mu się załączał zawsze.

Ja np. przy frontendzie - potrafię szybko programować w JavaScripcie, ale już na taskach bardziej nakierowanych na HTML/CSS moja wydajność jest o wiele gorsza. Wszystko zależy od rodzaju taska. Różni ludzie mają różne skille.

0
LukeJL napisał(a):

Nigdy się nie pracuje pełnych 8 godzin i jeśli ktoś na górze zakłada, że programista przebywając w biurze przez 8 godzin będzie przez 100% czasu rzeczywiście i efektywnie pracować nad taskami, to z pewnością będzie miał dość zafałszowane wyniki.

Zgadzam się. To wynikało na pewno po części z tego, że klient miał dostęp do issue trackera (także miał wgląd w czas pracy).

LukeJL napisał(a):

Jest różnica między sytuacją, gdzie

  1. ktoś chce zrobić porządnie jakiś task i robi go tydzień, ale zrobi go na tip-top(wysoka jakość kodu, testy, doszlifowanie, pofiksowane bugi, dobra integracja z całością projektu etc.), i go Janusze męczą i ściągają do dołu, że lepiej by było zrobić w jeden dzień ale na odczep się

  2. a drugą sytuacją, gdzie junior się męczy tydzień nad taskiem, ale potem okazuje się, że jakość kodu słaba, testów brak, są jakieś bugi, słabo przemyślane i w ogóle prawda jest taka, że to, co zrobił w tydzień ktoś bardziej doświadczony mógłby zrobić w 1 dzień i to lepiej.

Z tym pkt. 2 nie do końca się zgodzę. Junior to z założenia ktoś kto ma jeszcze wiele do nauczenia się i kogo trzeba po części pilnować (np. pytać o status taska codziennie, czy ma z czymś trudności). Jeśli on - tak jak napisałeś - po tygodniu pracy pokazuje lipny kod, to IMO coś szwankuje jeżeli chodzi o ogólnie pojętą organizację pracy w firmie/zespole.

0
Świetny Lew napisał(a):

Ale i tak znacznie więskza szansa, że trafia się do firmy krzak (tzw. Janusz-Soft), więc trzeba byc bardzo ostrożnym i każdy warning podczas rozmowy próbować wycenić i jeśli przekroczy się masa krytyczna warningow/errorów - mówisz NIE bez żalu.

jakie to są ostrzeżenia na rozmowie?

0

Właśnie, ktoś mógłby podpowiedzieć, mniej doświadczonym, na co patrzeć podczas rozmowy rekrutacyjne, aby nie nadziać się na firmę 'szybciej szybciej'?
I czy ktoś jest w stanie estymować, tak mniej więcej, jaki jest stosunek na rynku tych obozów pracy do firm które podchodzą do tematu poważnie?

7
  1. Czy firma używa VCSa (serio, są takie które nie używają o_O), pisze testy jednostkowe, używa sonara, używa jakiegoś CI, praktykuje Code Review. Jeśli czegoś z tej listy brakuje to trzeba się poważnie zastanowić.
  2. Jaka jest organizacja pracy - scrum/waterfall, jakie są rozmiary zespołów, jak często są releasy, ile trwają sprinty. Duze zespoły + długie sprinty albo waterfall = legacy software i łatanie bugów.
  3. Narzędzia i sprzęt - na czym będziesz pracował. Czy dostaniesz 2 ekrany + jakieś porządne IDE (np. IntelliJ) czy firma da ci 13" CRT i każe klepać w notatniku.
  4. Czy firma zatrudnia testerów.
14

Ja swojego czasu zrobiłem swoją listę pytań do potencjalnego pracodawcy. Czasami zadaje je wszystkie, czasami tylko wybrane. Na niektóre nie ma złej odpowiedzi, bo są jedynie informacyjne.

Kategoria 1. Zarządzanie technologią

  1. Jak wygląda dobór technologii dla nowego projektu.
  2. Jak zarządzany jest kod aplikacji? Jak weryfikowana jest jego jakość?
  3. Jak zarządzane są zadania, bugi i czas pracy programistów?

Kategoria 2. Środowisko i organizacja pracy

  1. Czy firma inwestuje w narzędzia pracy (komercyjne oprogramowanie, dodatkowy monitor, jak często ulepszany jest sprzęt komputerowy)?
    2, Czy możliwe są elastyczne godziny pracy?
  2. Czy możliwa jest praca zdalna? Jeśli tak to jak często?
  3. Jak wygląda kontakt z przełożonym, jak często odbywają się oficjalne spotkania z przełożonymi i w jaki sposób oceniani są pracownicy?
  4. W jaki sposób jest gromadzona wiedza na temat projektu pod względem biznesowym jak i technicznym?
  5. Czy dostęp do zasobów internetowych nie jest blokowany?

Kategoria 3. Zarządzanie projektami

  1. Jak często rozpoczynają się nowe projekty? Czy firma jest głównym wykonawcą? Czy realizuje własne projekty?
  2. W jaki sposób wycenia się czas trwania projektu oraz pojedyńczych zadań?
  3. W jaki sposób realizowane jest zarządzanie jakością aplikacji? jak testowane są aplikacje?
  4. Jakie metodyki prowadzenia projektów są wykorzystywane?
  5. W jaki sposób architektura systemu jest przekazywana zespołom?

Kategoria 4. Zarządzanie wiedzą

  1. Czy odbywają się wewnętrzne szkolenia? Czy firma wysyła pracowników na zewnętrzne szkolenia?
  2. Jak przekazywana jest wiedza pomiędzy programistami, projektami?
  3. Czy i w jaki sposób wykonywane są przeglądy kodu? Czy są realizowane wspólne przeglądy kodu, programowanie w parach lub inne metodyki zwinne?

Kategoria 5. Firma

  1. Czy pracownik pracuje nad jednym projektem, czy też z czasem zmienia się on?
  2. Jak długo realizuje się przeciętny projekt w firmie? Jeśli czas jest trudny do podania mile widziany jest przedział czasowy.
  3. Kto zajmuje się supportem?
  4. Czy firma oferuje różnego rodzaju bonifikaty? Jeśli tak to jakie?
  5. Czy występuje zjawisko nadgodzin?
  6. Czy pracownicy otrzymują premie? Jeśli tak to na jakich zasadach?
  7. czy można wychodzić w trakcie pracy? - Np. w sytuacji awaryjnej gdy trzeba załatwić sprawy prywatne, pojechać do lekarza itd.. Potem taką zaległość odrobić w innym terminie?

Być może nie na wszystkie pytania można otrzymać odpowiedź, jednak kwestie te są z pewnością interesujące i istotne.
Miałem już okazję przekazać owe pytania kilku pracodawcom i zazwyczaj wyniki są zadowalające tzn: chcą na nie odpowiadać :)
Niektóre pytania są pomijane / omijane, niektóre olewane, ale duża część z tego daje dobry obraz firmy.

1

Poza tym co napisali przedmówcy to dużo można wywnioskować z aktywności firmowej w internecie czy w społeczności programistów.

Ciekawe firmy czesto prowadzą jakąś formę aktywizmu - jeśli firma ma bloga o programowaniu, organizuje jakieś konferencje/meetupy czy ma konto na Githubie i wypuszcza rzeczy do open source - to jest to niewątpliwie dobry znak.

Cięzko mi sobie wyobrazić, żeby Janusz Soft prowadził taką działalność na większą skalę.

Też jest tak, że ciekawe firmy przyciągają ciekawych ludzi. Dobry programista będzie uciekał od Janusz Softa. Dlatego możesz też spróbować wygooglować po nazwiskach ludzi, którzy tam pracują. Jeśli widzisz, że jakiś tam pracownik coś ciekawego robi (np. udziela się w open source), to też raczej dobry znak. Jeśli w firmie pracują (z własnej woli przecież) sensowni programiści, to można się spodziewać, że będzie przywiązywana waga do jakości, a nie chodzenia na skróty.

1
Zimny Krawiec napisał(a):

Właśnie, ktoś mógłby podpowiedzieć, mniej doświadczonym, na co patrzeć podczas rozmowy rekrutacyjne, aby nie nadziać się na firmę 'szybciej szybciej'?
I czy ktoś jest w stanie estymować, tak mniej więcej, jaki jest stosunek na rynku tych obozów pracy do firm które podchodzą do tematu poważnie?

Spytać kto, estymuje czas wykonania zadania. Jeśli szef/PM, to uciekaj. Jeśli ludzie techniczni, to zostań.

0

W normalnej firmie przed planowaniem robi się już wstępne szacowanie/research zadań, które przypadają na kolejny sprint. Podczas samego planowania ludzie techniczni w porozumieniu ze stroną biznesową estymują poszczególne zadania. Dlaczego w porozumieniu, a nie samemu? Bo jak techniczni wycenią zadanie na x "mendejsów" to może się okazać, że wtedy to już będzie za późno/nikomu nie będzie potrzebne/itd. Programista nie ma wiedzy o tym jakie układy są zawierane z klientami i raczej nie powinno go to interesować.
Jeśli podczas planowania szacujecie od razu główne cele sprintu to źle. Jeśli podzadanie w ramach celu oszacowaliście na więcej niż 3 "mendejsy" to znak, że robicie coś źle/nie podzieliście dobrze zadań. (imho karty do plannig pokera mogły się składać tylko z 0, 0.5, 1, 2, 3 oraz ?) Wyestymowaliście zadania i sobie nie radzisz? Spoko, szacujcie zawsze z nadmiarem. Nadal nie możesz się wyrobić z zadaniami? To możliwości są trzy: 1) nie masz odpowiednich kwalifikacji 2) nadal źle szacujecie zadania 3) masz pecha i dostajesz mocno researchowe zadania

1 użytkowników online, w tym zalogowanych: 0, gości: 1