Dołączyłem niedawno jako Java dev do pewnego Software House'u. Pracuję tam 8 miesięcy i ostatnio miałem rozmowę z tech leadem podczas której zasugerował, że nie jest zadowolony z czasu dostarczania zadań i mógłbym trochę szybciej się wyrabiać. Problem w tym, że ja nie widzę sposobu jak mógłbym szybciej zamykać taski, bo uczciwie powiem, że nie obijam się w pracy i każdą godzinę wykorzystuję produktywnie, zdarza się że kodzę po godzinach.
Bardzo często jest tak, że gdy zaczynam rozkminać taska myślę sobie, że kodzenie zajmie mi 2-3 dni, bo wydaje się w miarę prosty, ale po drodze dochodzi wiele niespodziewanych rzeczy typu że coś się wywali i zdarza się że mam cały dzień w plecy na naprawianiu tego. Nie pracuję też długo w tej firmie i na bieżąco uczę się nowych kwestii.
Co do architektura tego softu, który rozwijam jest lekko mówiąc toporna, bo zajmujemy się w głownej części utrzymniem i łataniem bugów, mam też taski gdzie muszę dodać jakiegoś ficzera dostosowanego pod kątem tej starej architektury, bo takie mam wymaganie od tech leada. W rezultacie zdarzało mi się grzebać nad zadaniem 2/3 razy tyle niż było założone początkowo. Myślę że wynika to z tego że architektura tego systemu jest niestandardowa jak wspomiałem wcześniej i sporo rzeczy to typowy spagetti code i przebrnięcie przez to jest czasami sporym wyzwanniem. Dodatkowo dochodzą takie kwestie, że mam odgórne wymagania, że ma być zrobione tak i tak z użyciem tego i tego, bo później trudno będzie coś dostosować jeśli nie użyje tego sposobu lub biblioteki. Z tego powodu musiałem kilka razy zmieniać moje rozwiązanie, bo część funkcji nie byłaby kompatybilna mimo że był zgodny w założeniach i z ustaleniach. Co byście zrobili w takiej sytuacji jeśli wytłumaczyliście szczerze leadowi w czym jest problem a on dalej naciska i podejrzewa że się opieprzacie? Zależy mi na tej pracy, bo nie ukrywam że całkiem spoko płacą.
Ja bym dalej pracował swoim tempem i rozglądał się po rynku pracy. No, ale mi nie zależy na pracy w toksycznej firmie, więc nie wiem, czy to dobra porada.
Jeśli tech lead zamiast zadbać o zrobienie instrukcji jak utrzymać kompatybilność czy tworzyć taski na powolną spłatę długu technicznego zajmuje się szacowaniem wydajności pracownika to ja bym uciekał z takiego miejsca.
Załóżmy, że to nie jest typowy micromanagement + spaghetti i że da się naprawić sytuację.
podejrzewa że się opieprzacie
Ciekawe dlaczego? Może dlatego?
że kodzenie zajmie mi 2-3 dni, bo wydaje się w miarę prosty, ale po drodze dochodzi wiele niespodziewanych rzeczy typu że coś się wywali i zdarza się że mam cały dzień w plecy
Jak utykasz na cały dzień z zadaniem, to już jest trochę za późno. Komunikuj problemy wcześniej i proś o pomoc.
Niestety percepcja ma znaczenie. Musisz coś zrobić, aby twój wysiłek był widoczny.
- poproś o mentora
- wysyłaj drobne kawałki do review
- jak masz już prototyp, to pytaj się leada o ocenę ogólnego podejścia, abyś potem nie musiał wszystkiego przerabiać.
- Robisz review innym programistom? 8 miesięcy to powinno wystarczyć na załapanie obowiązujących patternów.
devops napisał(a):
ostatnio miałem rozmowę z tech leadem podczas której zasugerował, że nie jest zadowolony z czasu dostarczania zadań i mógłbym trochę szybciej się wyrabiać.
Wyraził swoje uczucia i oczekiwania. Miał do tego prawo.
a on dalej naciska i podejrzewa że się opieprzacie?
Co nie usprawiedliwia jego przemocowej postawy. Do HRu gościa i niech go wywalą XD
niespodziewanych rzeczy typu że coś się wywali i zdarza się że mam cały dzień w plecy na naprawianiu tego.
A jak duże macie pokrycie testami? Bo co to znaczy, że coś się wywali cały dzień w plecy na naprawianiu tego? To trochę jakby tam był taki kod, którego się nie da ruszyć.
utrzymniem i łataniem bugów,
Po co utrzymywać bugi?
Dodatkowo dochodzą takie kwestie, że mam odgórne wymagania, że ma być zrobione tak i tak z użyciem tego i tego, bo później trudno będzie coś dostosować jeśli nie użyje tego sposobu lub biblioteki. Z tego powodu musiałem kilka razy zmieniać moje rozwiązanie, bo część funkcji nie byłaby kompatybilna mimo że był zgodny w założeniach i z ustaleniach.
A czy macie code review? I jak często twój kod jest merdżowany? I czy komunikujesz się wystarczajaco z zespołem?
Bo to wygląda trochę, jakbyś pracował niby w zespole, ale w rzeczywistości samemu. Jakby coś nawaliło w komunikacji w zespole, jeśli robisz coś tak, jak ci się zdaje, a potem nagle się okazuje, że jest źle i musisz przerabiać. To nie brzmi jak problem techniczny, tylko jak problem z komunikacją i procesami.
No chyba, że faktycznie robisz PoC i sam dochodzisz do wniosku, że źle podszedłeś do rozwiązania od strony technicznej. Ale wtedy i tak lepiej byłoby się skonsultować wcześniej z innymi programistami, którzy dłużej są w projekcie, czy to dobre rozwiązanie biorąc pod uwagę kontekst projektu. Przegadać coś.
zdarza się że kodzę po godzinach.
Czy ci za to płacą i z własnej nieprzymuszonej woli to robisz?
Pewnie poza jakąś dziwną organizacją w firmie, jest tutaj typowy problem dla programistów - brak komunikacji :P A przynajmniej z tego posta wynika, że komunikacja w zespole/organizacji jest mierna.
Możliwe że w ten sposób chcą Cię zmanipulować byś poczuł że jesteś "słaby" i zaczął robić nadgodziny za darmo by zacząć dowozić na czas.
Spotkałem się z czymś takim w dwóch projektach.
Robić swoim tempem i odpowiadać, że nie da się szybciej. W międzyczasie odśwież cv.
Może notuj (ja tak czasem robię w Excelu) dokładnie ile Ci na co schodzi np.:
08:24 zadanie x123 - szukanie dostępu do bazy x
08:50 zadanie x123 - dodanie nowych tabel i kolumn
09:10 zadanie x123 - opcja edycji danych
zalety:
- będziesz widział na czym Ci dużo schodzi czasu, może faktycznie jest w czymś problem. Może to jakieś kwestie techniczne jak np. wolny dostęp do bazy
- w razie takich rozmów będziesz mógł pokazać na co Ci zeszło tyle czasu i zapytać leada czy ma jakiś pomysł na usprawnienie tego. Gdybym ja się czepiał kogoś o niską wydajność to wolałbym taką rozmowę z konkretami, a nie na zasadzie moje "wydaje mi się" vs "wydaje mi się" rozmówcy
- zobaczą Twoje starania i jeśli Cię zwolnią to raczej później, zyskasz czas na poprawę/znalezienie dobrej pracy
A z takich rad, które można szybko zastosować to wysypiaj się, kofeina, a jak pracujesz zdalnie to porób sobie czasem w pracy serię np. 20-30 przysiadów, popracuj na stojąco. A długoterminowo to dieta pod mózg (polecam książkę "Jedz jak geniusz"), regularne treningi, ureguluj dopaminę.
Być może jesteś dobrym pracownikiem i problem nie jest w Tobie, ale próby poprawy wydajności mogą Ci wyjść tylko na plus.
Jak macie estymowane zadania to policz sobie ile pkt dowozisz Ty, a inni członkowie zespołu. Wiadomo, estymacje nie sa idealne bla bla bla, ale porównaj tez ostatnie 3-6 m, wtedy błędne estymacje uśrednią się i będziesz miał jako takie porównanie.
Do tego co zostało powiedziane powyżej dodałbym:
- Nadawanie odpowiednich priorytetów zadaniom. Szkoda tracić czas na zajmowanie się rzeczami nieistotnymi, które nie zostaną zauważone lub docenione. Lepiej ten czas poświęcić na coś co ma znaczenie dla projektu lub przełożonego.
- Nie klepać kodu na oślep. Przemyśleć cel i rezultat końcowy przed podjęciem działań. Zastanowić się co może pójść nie tak i jak można temu zaradzić.
- Starać się odblokowywać. Czasami to wymaga poproszenia o pomoc.
- Raportować statusy, tak by postęp był widoczny.
- Powoli rozglądać się za nową pracą. Jeżeli Twój przełożony już wyrobił sobie o Tobie zdaniem, to zmiana tego zdania będzie trudniejsza, niż podniesienie swojej efektywności.
devops napisał(a):
Dołączyłem niedawno jako Java dev do pewnego Software House'u. Pracuję tam 8 miesięcy i ostatnio miałem rozmowę z tech leadem podczas której zasugerował, że nie jest zadowolony z czasu dostarczania zadań i mógłbym trochę szybciej się wyrabiać. Problem w tym, że ja nie widzę sposobu jak mógłbym szybciej zamykać taski, bo uczciwie powiem, że nie obijam się w pracy i każdą godzinę wykorzystuję produktywnie, zdarza się że kodzę po godzinach.
Bardzo często jest tak, że gdy zaczynam rozkminać taska myślę sobie, że kodzenie zajmie mi 2-3 dni, bo wydaje się w miarę prosty, ale po drodze dochodzi wiele niespodziewanych rzeczy typu że coś się wywali i zdarza się że mam cały dzień w plecy na naprawianiu tego. Nie pracuję też długo w tej firmie i na bieżąco uczę się nowych kwestii.
Co do architektura tego softu, który rozwijam jest lekko mówiąc toporna, bo zajmujemy się w głownej części utrzymniem i łataniem bugów, mam też taski gdzie muszę dodać jakiegoś ficzera dostosowanego pod kątem tej starej architektury, bo takie mam wymaganie od tech leada. W rezultacie zdarzało mi się grzebać nad zadaniem 2/3 razy tyle niż było założone początkowo. Myślę że wynika to z tego że architektura tego systemu jest niestandardowa jak wspomiałem wcześniej i sporo rzeczy to typowy spagetti code i przebrnięcie przez to jest czasami sporym wyzwanniem. Dodatkowo dochodzą takie kwestie, że mam odgórne wymagania, że ma być zrobione tak i tak z użyciem tego i tego, bo później trudno będzie coś dostosować jeśli nie użyje tego sposobu lub biblioteki. Z tego powodu musiałem kilka razy zmieniać moje rozwiązanie, bo część funkcji nie byłaby kompatybilna mimo że był zgodny w założeniach i z ustaleniach. Co byście zrobili w takiej sytuacji jeśli wytłumaczyliście szczerze leadowi w czym jest problem a on dalej naciska i podejrzewa że się opieprzacie? Zależy mi na tej pracy, bo nie ukrywam że całkiem spoko płacą.
Ok mój szybki solution dla Ciebie:
Miej wywalone jajca kompletnie i zacznij już sobie chodzić po interview, bo jeśli robisz tak jak piszesz, to i tak się Ciebie pozbędą niebawem albo będziesz siedzieć po 16h dziennie przy pracy, żeby team lead miał satysfakcje i swój awans/premie :)
Gdybym to był ja, to bym już sobie zaczął szukać roboty innej i nie zwolniłbym się tylko bym sobie pocisnął OE z priorytetem na nową pracę, a tu bym robił dosłowne minimum i czekał, aż mnie wywalą i miał na to wywaloną lache