Trudne zadania

Cześć,
Jaka jest Wasza perspektywa na to, że programista (w moim przypadku junior) nie daje rady wykonać danego taska przypisanego do niego?

Aktualnie właśnie pracuję nad takim zadaniem i podobno nie jest ono mega trudne. Takie stwierdzenie mnie jeszcze bardziej sfrustrowało, ponieważ siedzę nad zadaniem i się wkurzam ciągle.
Denerwuje mnie deficyt wiedzy biznesowej w zakresie tego zadania, a inni by to zrobili kilka razy szybciej pewnie.
Technicznie nic mnie nie zaskakuje za bardzo, tylko ten lakoniczny opis ticketu i domyślanie się wielu rzeczy, czytanie kodu, łażenie po nitce do kłębka i gmeranie.

Nikt do mnie się nie spina, ale zastanawiam się jak się tłumaczyć w razie zgrzytu, bo nie wiem czy brak wiedzy biznesowej w danym zakresie systemu jest dobrym argumentem.
I ogólnie jak się wk****ię to rzucę to wszystko i już. Zamiast realizować zadanie, to kolejny dzień mam się dowiadywać jak to wszystko działa, a ticket wyceniony.

Ogólnie nigdy nie było takich spin, ale ja sam siebie terroryzuję, bo mam chyba nawyki z innych prac (fizycznych lub w korpo na najniższych szczeblach) i tam gonili i rozliczali ostro już po pierwszym miesiącu pracy.

Mysle, ze nie ma powodow do wstydu do tego, ze sie jest przyblokowanym z zadaniem. Najwazniejsze to informowac na biezaco o swoich problemach, wytlumaczyc czego sie nie rozumie i szukac pomocy - na pewno ktos pomoze. Taka otwartosc bedzie doceniona. Spotkalem wielu juniorow, ktorzy przez pare dni nie odzywali sie i potem bylo niezrecznie.

Jesli nie rozumiesz kwestii biznesowej to mozesz tez podpytac PMa/PO jesli takiego macie.

Ja tam bym się wstydził mówić ludziom, że zadanie mnie przerasta. Oczywiście junior, który udaje, że robi to pacan, ale jeśli jesteś chociaż trochę mocny to zepnij poślady i działaj, pokonaj nowe ograniczenia, bo to dopiero początek.

Witamy w prawdziwym żuciu. Tak to wygląda w 90% firm których pracowałem. Koniec z pisaniem jedoplikowych aplikacji na githuba. Praca programisty bądź co bądź jest trochę kreatywna. W budowlance łatwo ocenić czy przeniosłeś te cegły czy nie i zadanie jest ogarnialne przez 90% procent społeczeństwa. Nikt Ci kochones nie urwie jak w pierwszym miesiącu nie wyrobisz normy a jak będzie to probował zrobić to firma nie warta zachodu. Ucz się zgłębiaj temat. Praca programisty to bezustanna nauka technologii, kodu, biznesu albo ludzi.

Pytanie czy jesteś nowy w tej robocie, czy męczysz się tak od dłuższego czasu. Ja w jednej firmie siedziałem prawie dwa lata i nie potrafiłem się odnaleźć tak bardzo, że ciągle chodziłem sfrustrowany i też miałem problem z dowożeniem podstawowych tasków, których nawet nie rozumiałem. Poszedłem do innej pracy i nagle wszystko spoko.

NeutrinoSpinZero napisał(a):

deficyt wiedzy biznesowej w zakresie tego zadania, a inni by to zrobili kilka razy szybciej pewnie.

Technicznie nic mnie nie zaskakuje za bardzo, tylko ten lakoniczny opis ticketu i domyślanie się wielu rzeczy, czytanie kodu, łażenie po nitce do kłębka i gmeranie.

Kiedy pracowalem w IT przez 2 i pol roku to glownie takie zadania dostawalem, z tym ze technicznie nawet mnie zaskakiwaly. Na tym wlasnie wyglada praca programisty (i nie tylko) ze dostajesz na pierwszy rzut oka przerastajace zadania. Przygotuj sie psychicznie na jeszcze trudniejsze zadania bo to dopiero poczatek (pisze z wlasnego subiektywnego doswiadczenia).

NeutrinoSpinZero napisał(a):

Nikt do mnie się nie spina, ale zastanawiam się jak się tłumaczyć w razie zgrzytu, bo nie wiem czy brak wiedzy biznesowej w danym zakresie systemu jest dobrym argumentem.
I ogólnie jak się wk****ię to rzucę to wszystko i już. Zamiast realizować zadanie, to kolejny dzień mam się dowiadywać jak to wszystko działa, a ticket wyceniony.

Programowanie(nawet hobbystyczne), debugowanie, itd. jest bardziej znosne dla cierpliwych i lubiacych dlugotrwale koncentrowac sie i analizowac.

W swoim własnym, już dużym projekcie uwielbiam pracować, bo wszystko wiem, mam wszystko pod kontrolą, wiem dlaczego tak rozwiązałem dany problem.

A tu się okazuje, że jest coś niezbyt zrozumiałego w kodzie, bo ktoś kilka lat temu podjął taką decyzję, a ja nie mam szans o tym wiedzieć.

NeutrinoSpinZero napisał(a):

W swoim własnym, już dużym projekcie uwielbiam pracować, bo wszystko wiem, mam wszystko pod kontrolą, wiem dlaczego tak rozwiązałem dany problem.

A tu się okazuje, że jest coś niezbyt zrozumiałego w kodzie, bo ktoś kilka lat temu podjął taką decyzję, a ja nie mam szans o tym wiedzieć.

Chłopie, ja jestem w takim projekcie (na szczęście do końca sierpnia już tylko bo się zwolniłem xD) gdzie pewna domena jest tak skomplikowana, że nawet analityk i PO się gubią w tym jak to ma działać :D dokumentacja niby jest ale na bieżąco znajdują się przypadki gdzie nie ma pokrycia z faktycznym stanem aplikacji :D Ja bym się nie przejmował w ogóle - masz blokera bo nie rozumiesz strony biznesowej to ustaw jakieś spotkanie z kimś kto to bardziej ogarnia i tyle. Ważne, żeby się nie bać swojej niewiedzy i dać od razu znać o tym reszcie zespołu ;)

Zamiast realizować zadanie, to kolejny dzień mam się dowiadywać jak to wszystko działa, a ticket wyceniony

Wyceniony w sensie, że została przypisana do niego liczba przewidywanych godzin albo liczba story pointów?

No to idąc w "agile", to w tym momencie tę całą "wycenę" należałoby wyrzucić do kosza i zastosować zasadę "responding to change over following a plan". No bo skoro estymacja się rozminęła z rzeczywistością, to trzeba ją zmienić...

programista (w moim przypadku junior) nie daje rady wykonać danego taska przypisanego do niego?

To znaczy, że nastąpiło jakieś zaburzenie współpracy i task albo został przypisany do niewłaściwej osoby(może coś wymaga większej wiedzy o projekcie niż twoja, jak piszesz, że masz deficyt wiedzy biznesowej), albo task został niejasno opisany ( lakoniczny opis ticketu i domyślanie się wielu rzeczy), albo nikt nie poczuł się do tego, żeby wprowadzić daną osobę w task ( kolejny dzień mam się dowiadywać jak to wszystko działa, - a to raczej powinno być tak, że ktoś z większym doświadczeniem w projekcie powinien cię jakoś wprowadzić do tematu), czy może wreszcie pewne uchybienia są po twojej stronie ( zastanawiam się jak się tłumaczyć w razie zgrzytu, bo nie wiem czy brak wiedzy biznesowej w danym zakresie systemu jest dobrym argumentem. - zamiast się zastanawiać nad wymówkami, lepiej po prostu kogoś spytać, zasięgnąć opinii "eksperta od danego projektu", doprecyzować wymagania biznesowe itp.).

To, co możesz zrobić, to samemu wyjść z inicjatywą, pytać, prosić o pomoc, precyzować, ale też badać projekt samodzielnie (czyli domyślanie się wielu rzeczy, czytanie kodu, łażenie po nitce do kłębka i gmeranie. bo to też część pracy). I może się uda. Gorzej jeśli problem jest systemowy i tego typu sytuacje są nagminne i niezależne od tego, co robisz. Wtedy lepiej się zwijać.

NeutrinoSpinZero napisał(a):

Denerwuje mnie deficyt wiedzy biznesowej w zakresie tego zadania, a inni by to zrobili kilka razy szybciej pewnie.

Bo jakby przyszedł senior to wiedzę domenową miałby w małym palcu? Tylko wtedy, gdyby przyszedł z tej samej biznesowej domeny.

Są Janusze biznesu którzy chcieliby, żeby senior oznaczało doświadczonego programistę nie tylko konkretnego języka ale też biznesu w którym siedzi biznesik Janusz.

Pierwszym przypadkiem nie przejmuj się za bardzo, poznasz domenę.
Od drugiego przypadku uciekać, im szybciej tym lepiej.

Brak wiedzy biznesowej, brak znajomości projektu. Tego nie da się nadrobić i przeskoczyć. U mnie w projekcie są story pointy do wyceny a ja jestem względnie nowy w projekcie. Dla tych co siedzą od początku w projekcie jeden story point to jeden dzień pracy. Dla mnie na początku jeden story point to był tydzień pracy. Po pół roku jest już trochę lepiej, ale dalej do jednego dnia mi daleko

Zamiast realizować zadanie, to kolejny dzień mam się dowiadywać jak to wszystko działa, a ticket wyceniony.

Witamy w prawdziwym życiu. Mi też nikt na studiach nie mówił że tak to będzie wyglądać i też byłem bardzo zdziwiony. Ale tak wygląda praca przy rozwoju aplikacji w której nie jest się od początku

Moim zdaniem trudność w wykonywaniu zadań może mieć kilka przyczyn. Mnie osobiście zawsze najbardziej dobijało tworzenie rzeczy, których nie rozumiałem (np. feature który miał słabo opisane wymagania i był z obszaru który nie za bardzo lubię) i moim zdaniem takie problemy mogą pojawić się na każdym szczeblu od juniora do seniora i niekoniecznie musi to być jego wina...

Bywały też sytuacje gdzie problem był bardziej techniczny i najczęściej traciłem czas na rozmyślanie godzinami jak by to najlepiej obejść zamiast po prostu usiąść i nakodzić choćby troche sphagetti, który potem poprawie. Nie zmienia to faktu, że rozprawienie się z takim problemem zawsze dawało sporo satysfakcji i motywacji do kolejnej pracy.

A tu się okazuje, że jest coś niezbyt zrozumiałego w kodzie, bo ktoś kilka lat temu podjął taką decyzję, a ja nie mam szans o tym wiedzieć.

Witamy w prawdziwym świecie :) Ja bym patrzył w testy, bo jest szansa ze są jakieś test-case które opisują to zachowanie.

Zamiast realizować zadanie, to kolejny dzień mam się dowiadywać jak to wszystko działa, a ticket wyceniony.

Normalna sprawa. Przecież na tym polega cała trudność pracy programisty:

1. Musisz ogarnąć domenę i zrozumieć "jak to ma działać" i jeszcze musisz tą wiedzę pozyskać od jakiegoś analityka/PO
2. Musisz ogarnać jak dodać to do istniejącego kodu, tak żeby się wszystko nie posypało

Samo zaklepanie kilku pętli i warunków to mogła by zrobić nawet małpa i to jest zupełny szczegół.

Anyway, idź do analityków/PO i niech ci wyjaśnią aktualne zachowanie i tą nową rzecz którą masz napisać. Po to tam są właśnie.

Do powyższych porad mogę tylko dodać, że jest duża szansa, że task który dostałeś jest po prostu za duży. U nas w pracy jest prosta zasada - Nie wiadomo o co chodzi lub jak coś zrobić to rozbijamy to na części pierwsze - sub taski tak długo, aż wszystko jest jasne i praca rusza.

@NeutrinoSpinZero: psycholog - lub ktos inny kto Cie naprostuje. Poklepali Cie juz po plecach wiec tego nie bede robic (zreszta slaby w tym jestem). Mialem podobne przypadki (ludzi) i jest to meczace :). Dostajesz zadanie ktore powinienes byc w stanie zrobic - nie znaczy to jednak ze zrobisz je w 5 sekund. Z mojego punktu widzenia wyglada ze dostales zadanie ktore moze Cie rozwinac, ktore powinienes byc w stanie zrobic, ktore pozwoli Ci zrozumiec domene i projekt co przyda sie zapewne pozniej. Naturalne jest ze potrzebujesz na to czasu (z tego co piszesz nikt nie ma z tym problemu wiec zakladam ze masz normalny zespol). Ty jednak sie martwisz, wymyslasz jakies historie ze sobie nie dasz rady, ze za wolno i sie nakrecasz. Bo powinienes to zrobic od razu bez wgryzania sie w projekt i domene. Dodatkowo nie wiem czy rozumiesz co oznacza w miare proste - to nie jest rownoznaczne ze mozna to zrobic szybko (wybudowanie domu jest proste ale nie robi sie tego w tydzien). To oznacze ze nie bedziesz tam potrzebowal tworzyc jakiejs magii i tyle. Uwierz mi ze nikt nie uwaza Cie za bohatera ktory rozwiaze problem/zadanie od reki. Wiecej pewnosci siebie (zapisz sie moze na silke - nie wiem czy pomoze ale moze bedziesz mial wiecej testosteronu dzieki temu).

Zastanow sie co by bylo jesli kazal bym Ci przebiec 5km. Zalamalbys sie bo nie ma szans aby to osiagnac od razu (jesli nie biegasz) czy zalozylbys ze po paru miesiacach uda Ci sie to zrobic w dobrym czasie. Bo na razie wyrzucasz sobie ze na poczatku Ci to nie wychodzi.

NeutrinoSpinZero napisał(a):

Cześć,
Jaka jest Wasza perspektywa na to, że programista (w moim przypadku junior) nie daje rady wykonać danego taska przypisanego do niego?

To normalne, junior powinien być w stanie wykonywać swoje zadania, ale z pomocą kogoś.

Aktualnie właśnie pracuję nad takim zadaniem i podobno nie jest ono mega trudne. Takie stwierdzenie mnie jeszcze bardziej sfrustrowało, ponieważ siedzę nad zadaniem i się wkurzam ciągle.
Denerwuje mnie deficyt wiedzy biznesowej w zakresie tego zadania, a inni by to zrobili kilka razy szybciej pewnie.
Technicznie nic mnie nie zaskakuje za bardzo, tylko ten lakoniczny opis ticketu i domyślanie się wielu rzeczy, czytanie kodu, łażenie po nitce do kłębka i gmeranie.

No u mnie ticket to zwykle jedno zdanie tytułowe, opisu nie uświadczysz, najwyżej jakieś załączone maile. A potem większość roboty to dowiedzieć się o co chodzi.
Czytanie kodu itepe, czasem to i z tydzień w debugerze bez napisania linijki, żeby ogarnąć co się dzieje. Tak wygląda praca z legacy code i trudną domeną biznesową.

Nikt do mnie się nie spina, ale zastanawiam się jak się tłumaczyć w razie zgrzytu, bo nie wiem czy brak wiedzy biznesowej w danym zakresie systemu jest dobrym argumentem.
I ogólnie jak się wk****ię to rzucę to wszystko i już. Zamiast realizować zadanie, to kolejny dzień mam się dowiadywać jak to wszystko działa, a ticket wyceniony.

Brak wiedzy domenowej to jest właśnie argument, jesteś młodym programistą, a nie specjalistą od strony biznesowej. Pogadaj z nim kto ogarnia domene.

Brak wiedzy biznesowej to norma. Nie dość, że każdy projekt ma inny stosunek wiedzy domenowej do technicznej, to jeszcze sposób przekazania tej wiedzy jest inny. Nie wszystko da się załapać tak od razu. Ważne, żeby próbować samemu dojść czemu coś działa w taki a nie inny sposób. To, że czego się nie umie, nie znaczy, że nie warto się przygotować na spotkanie w zespole. Można spytać gdzie ogólnie szukać jakiejś rzeczy i samemu próbować. Jeśli nie wyjdzie, powiedzieć na spotkaniu: szukałem tu i tu, znalazłem to i nie znalazłem czegoś innego. Efekt? Koledzy z zespołu widzą starania i wiedzą, że nowy pracownik nie jest supermanem i nie przeskoczy pewnych rzeczy.

A. I jakby co to nie sugeruj się za bardzo ludźmi z internetowego forum. Jednak większość z nich pracowała w góra kilku firmach i jest całkiem spora szansa, że zwyczajnie w żadnej z nich nie mieli projektu mocno osadzonego w kontekście biznesowym. Jeśli ktoś po prostu dostawał dokumentację i polecenie "zrób to" to zwyczajnie Cię nie rozumie i nawet nie odnosi się do tego co napisałeś, tylko do swojego wyobrażenia o tym, co napisałeś.

Dziękuję za wypowiedzi. Dobrze, że napisaliście jak to wygląda z perspektywy innych programistów.
Wygląda na to, że naoglądałem się za dużo Silicon Valley i za bardzo chcę być wymiataczem, który siądzie i zacznie napierniczać w klawiaturę, a o 5 nad ranem wyjdzie całkiem super feature.
Może za bardzo jestem perfekcjonistą, chciałem, żeby mnie postrzegano jako super developera, ale jednak życie to film.

Od początku kierowałem się tą słynną prezentacją Wojciecha Seligi
Więc zacząłem postrzegać ten zawód, że nie jesteś dobry jak nie siądziesz i nie zaczniesz napierniczać ficzer za ficzerem jak szalony, ledwo łapiąc powietrze w płuca jak Pan Wojciech w swoim wystąpieniu.

Wiem, że to nie prawda. W sumie też tak byłem wychowany, czyli ochrzan za powolną/nieefektywną/niedoskonałą pracę, mimo że często nie wiedziałem jak daną rzecz zrobić.

Ale dzisiaj już nie mam takiego ciśnienia, robię w swoim tempie i niech będzie co ma być.

10-cio tysieczniki w 20letnich projektach, w 30letnich technologiach bez dokumentacji i testow - norma xD Nie przejmuj sie, tez mi sie zdarza utknac nawet i tydzien czasami ale nikt pretensji za to nie ma wrecz przeciwnie, sa zachwyceni ze tak szybko udalo sie rozwiazac problem bo kazdy wie w jakim gownie trzeba grzebac. Ja pytam analityka / testera o to zeby mi okreslil:
JAK JEST TERAZ oraz JAK MA BYC, konkretnie palcem pokazal jak dziecku, ze o tu klikam i to to mi sie pokazuje i to jest zle bo powinno byc tak. Zaczynam od tego gdzie klikal, przebijajac sie przez rozne serwery aplikacyjne, kolejky, protokoly i tak po nitce do klebka :P

Ten algorytm stosuje w sytuacji w ktorej kompletnie nie znam projektu, najczesciej go widze pierwszy raz wiec o znajomosci domeny w ogole nie ma mowy. Najczesciej to taki jednorazowy strzal raz na miesiac / dwa sie zdarza

NeutrinoSpinZero napisał(a):

Więc zacząłem postrzegać ten zawód, że nie jesteś dobry jak nie siądziesz i nie zaczniesz napierniczać ficzer za ficzerem jak szalony, ledwo łapiąc powietrze w płuca jak Pan Wojciech w swoim wystąpieniu.
Wiem, że to nie prawda.

Sz. P. Wojciech kilka lat później zachwycał się bootcampami, wszyscy mieli zapierniczać jeszcze szybciej ale za miskę ryżu.

Każda firma chciałby mieć wymiataczy, 10+ w zawodzie, 5+ w domenie, płacić max 70 brutto za godzinę (bez urlopów itp). - nie piszę konkretnie o firmie p. WS

Robiłeś to tej pory taski na czas, i dobrze. Teraz masz kłopot - zdarza się.
Mistrzowie świata, Europy też przegrywają jakiś mecz w eliminacjach. Potężnym innowacyjnym firmom przytrafiają się wtopy. Imperia powstawały ale przegrywały bitwy.
Spokojnie, nie jesteś Aleksander Macedoński, jesteś junior. Rób swoje, tylko może nie trzymaj niespodzianki do ostatniego dnia "Tym razem nie ugryzłem tematu. Nie spodziewaliście się, co?! :)"

NeutrinoSpinZero napisał(a):

Od początku kierowałem się tą słynną prezentacją Wojciecha Seligi

Przecież dokładnie ten sam Wojciech Seliga opowiada o rozwoju programisty:
Gdzie przez pierwsze 5 lat się pytasz jak coś zrobić, a potem się pytasz co zrobić - czyli kwestia ustalań wymagań, dopytywania i ogólnie gadania z biznesem. Im lepszym jesteś developerem, tym więcej czasu spędzasz na meetingach i gadaniu z ludźmi, niż na kodowaniu.

Tomek Pycia napisał(a):

Witamy w prawdziwym żuciu.

Dokładnie, bo tryby korporacji każdego przeżują i wyplują (albo co gorszego).

NeutrinoSpinZero napisał(a):

Cześć,
Jaka jest Wasza perspektywa na to, że programista (w moim przypadku junior) nie daje rady wykonać danego taska przypisanego do niego?

Aktualnie właśnie pracuję nad takim zadaniem i podobno nie jest ono mega trudne. Takie stwierdzenie mnie jeszcze bardziej sfrustrowało, ponieważ siedzę nad zadaniem i się wkurzam ciągle.
Denerwuje mnie deficyt wiedzy biznesowej w zakresie tego zadania, a inni by to zrobili kilka razy szybciej pewnie.
Technicznie nic mnie nie zaskakuje za bardzo, tylko ten lakoniczny opis ticketu i domyślanie się wielu rzeczy, czytanie kodu, łażenie po nitce do kłębka i gmeranie.

A jak myślisz za co tyle płacą w tej pracy? Chyba nie za projekty shopping cart z tutoriali które się pisze z głowy w 5 minut?

Ten temat moglby dolaczyc do tych tematow ktore proponuje sie do przejrzenia wszystkim tym co zamierzaja rozwazyc prace jako programista. Jest wg mnie przykladem "z zycia wzietym" a ilosc stron do przeczytania jest mniejsza niz w Myślisz o przebranżowieniu na zawód programisty? Warto to wiedzieć!

Owszem zdaje sobie sprawe ze to tylko moja subiektywna (niekoniecznie dobra) propozycja.