Niektórzy mogą się zdziwić, ale tak właśnie wygląda praca DOJRZAŁEGO programisty. Przede wszystkim kontakt z ludźmi i rozmawianie. Tiket to tylko wysokopoziomowa abstrakcja tego co ma być zrobione. W 90% przypadków i tak trzeba ustaląć z twórcą co moał na myśli.
11
2
Jak się pracuje w normalnych technologiach (czyli nie frontend i js) to nie ma raczej problemu z uczeniem się nowych frameworków, bo za często takowe nie powstają (no chyba, ze jakies nowe usługi w cloud), np. jak od strony Javy znasz sobie SpringBoota, JPA, Hibernate, MongoDB, Postgres, może Oracle, Elasticsearch, Flywaya, Kafka + Aws/Azure/GCloud, docker, k8s to za wiele więcej nie potrzeba w aktualnych i przyszłych firmach by na spokojnie sobie klepać mikroserwisowe crudy (oprocz wiedzy domenowej) przez następne 5-8 lat zanim wyjdzie coś ciekawego nowego
Edit: no dobra, tak teraz spojrzałem ile tego trzeba ogarniać to może faktycznie jest to całkiem pokaźna ilość
4
@Escanor16:
Jeśli JPA, Oracle, SpringBoot to normalne technologie to aż boje się zapytać jakie są nienormalne.
1
Jak nie chce Ci się uczyć nowych rzeczy to zapraszam do c++, tutaj ludzie na standard z 2011 roku mówią nowoczesny także, nie ma co sie martwić.
10
ledi12 napisał(a):
Niektórzy mogą się zdziwić, ale tak właśnie wygląda praca DOJRZAŁEGO programisty. Przede wszystkim kontakt z ludźmi i rozmawianie. Tiket to tylko wysokopoziomowa abstrakcja tego co ma być zrobione. W 90% przypadków i tak trzeba ustaląć z twórcą co moał na myśli.
Mam takie samo zdanie.
Uważam, że (o ile nie jesteś juniorem/nie pracujesz mniej niz np. 3-6 miesięcy w projekcie) to w tickecie powinno być na tyle informacji, aby taki "samodzielny" deweloper byl w stanie rozpocząć pracę. Na własną rękę dopytywać się o szczegóły.
Przecież jakby każde zadanie miało być w 100% opisane to tam najczęściej nie ma już nic do roboty. Wyklepanie kodu to zazwyczaj ta łatwiejsza rzecz, którą można dać juniorowi.
O ile nie jest to jakieś monotonne zadanie to często też ciężko na samym początku o wszystkie detale. Do tego jest potrzebna analiza, a najczęściej najtrafniejsza analiza odbywa się poprzez próbę wykonania zadania.
Ale jeżeli ktoś Cię krytykuje za dopytywanie się - to już akurat słabo. Pracowalem już w ponad 10 firmach i nigdy nie było problemu z dopytywaniem się o szczegóły, albo gdy prosiłem kogoś o pomoc. Istotne jednak jest to, że faktycznie przychodziłem z gotowymi pytaniam, jakąś wstępną próbą zrozumienia problemu na podstawie dostępnych materiałów - conflue/wiki/historii na slacku/opis taksu w jirze/przeglądu kodu. To często jest super baza wiedzy (nawet jak nieaktualna w przypadku wiki/conflue to jednak da Ci już jakąs podstawę do zrozumienia słownictwa/domeny).
Sam nie lubię (a troszkę to czuję z twojego tonu) podejścia "waszym obowiązkiem jest wytłumaczyć mi o co chodzi". A jednocześnie uwielbiam pomagać jak ktoś mówi: "Sluchaj, przejrzałem tu tu i tu, doszedlem do tego i tego, ale utknąłem na tym - czy jesteś w stanie mi pomóc, a jak nie to skierować do kogoś kto będzie?" I na szczęście coraz więcej ludzi to rozumie.
Widziałem wiele sytuacji i uważam, że takie podejście jest najzdrowsze - nie wymagaj, że wszystko będzie super opisane, buduj sobie siec ludzi w pracy, którzy Ci będą pomagać z różnymi zagadnieniami - jeden ogarnie devopsy i tu Ci pomoże, drugi ogarnia frontend dobrze i lubi o tym opowiadać, a trzeci ma kontakty do tych z biznesu i siłe przebicia, aby wytłumaczyć, że tak sie nie zrobi.
Ale przy tym wszystkim - również dawaj coś od siebie. Pomagaj jak ktoś prosi o pomoc, jak prosisz o pomoc - zrób wcześniej tyle ile faktycznie (w jakimś racjonalnym czasie) jesteś w stanie zrobić/przeanalizować. I zawsze staraj się przedstawić kontekst co zrobiłeś/sprawdziłeś/do czego doszedłeś, a nie "ej, wytłumacz mi to zadanie".
U mnie takie podejście spisuje się od lat. W każdym środowisku - od korpo/banków gdzie aby baze danych postawić to trzeba uderzyć do 20 osób, bo nikt nie wie jak przejść korpo-formalności, po mniejsze firmy gdzie zadanie w jirze jest opisane "Leci outofmemory, (patrz stacktrace z kibany) - do analizy i naprawy".
A co do zmian wymagań na ostatnią chwilę - takie rzeczy się zdarzają i będą zdarzać. Po prostu. Można minimalizować występowanie takich sytuacji sprawną komunikacją, ale i tak dalej to się będzie pojawiać.
0
A jak macie planowaie sprintu, to nie omawiacie kto ma jakie taski i czy brakuje mu jakichs informacji zeby je skonczyc? Ja na swoje 3-4 w sprincie mam zawsze jakis enigmatyczny ale wtedy prosze o doprecyzowanie Acceptance Criteria.
5
Widze, że większość osób komentujących nie rozumie problemu.
OP nie ma problemu z dopytywaniem. To góra wyzywa OPa o to, że zadaje pytania.
Skoro brakuje wymagań, sama wiedza domenową nie wystarcza, aby samemu sobie odpowiedzieć to przecież normalnym jest zadawanie pytań... OP w tym momencie jest deklasowany głupkowatymi komentarzami, że jest "młody" I ma dopytać "seniorów".
0
U nas w zespole mamy między innymi takie "typy" zadań:
- Nie wiadomo co dokładnie lub jak trzeba zrobić - podczas zespołowego spotkania spisujemy w zadaniu w Jirze jaki jest cel i to co wiemy, i ustalamy w jakim kierunku iść, do kogo się odezwać itp.
- Wiadomo co/jak robić - na zespołowym spotkaniu doprecyzowujemy treść zadania i potwierdzamy, że jest wystarczająco jasna, żeby można było robić zadanie
Sam staram się dokładnie opisywać zadania. No i ostatecznie jeśli zbieram jakieś informacje, to też je wpisuję do Jiry lub jakiegoś dokumentu. W głowie wszystkiego nie pomieszczę.
I też nie lubię jak zadanie nie jest opisane lub jest opisane tak, że w sumie ten opis i tak nic nie daje.
0
ledi12 napisał(a):
Niektórzy mogą się zdziwić, ale tak właśnie wygląda praca DOJRZAŁEGO programisty. Przede wszystkim kontakt z ludźmi i rozmawianie.
Jak masz długi staż to zazwyczaj tak jest (ew. na to się zgadzasz dla świętego. spokoju). Ale zapomniałeś dodać że prawie każdy szanujący się dojrzały programista dba o to żeby zawsze mieć odskocznię - prostą, niezobowiązującą, 4fun, bez BS, tylko potrzeba i jej zrealizowanie.
Bez tego robi się nudno.
0
Są wgl. w IT specjalizacje które nie mają takich problemów lub w mniejszym stopniu? Np. Jacyś cloud engineers, devopa, data engineers? Podobno dla Ruby dev nic się praktycznie nie zmienia w technologiach 
1
Zdjecie najlepiej oddaje sytuacje
0
ledi12 napisał(a):
Niektórzy mogą się zdziwić, ale tak właśnie wygląda praca DOJRZAŁEGO programisty. Przede wszystkim kontakt z ludźmi i rozmawianie. Tiket to tylko wysokopoziomowa abstrakcja tego co ma być zrobione. W 90% przypadków i tak trzeba ustaląć z twórcą co moał na myśli.
Jak zwykle wszystko zależy
Raz jeden dostałem taska, pierwszego taska w projekcie do którego trafiłem
Zaproponuj uproszczenie procesu, żeby nie trzeba było tyle klikać
Po przejrzeniu co i jak stwierdziłem i opisałem że 80/20 a może nawet 90/10 tego procesu to konfiguracja/klikanie (że tak to nazwę) które i tak zależało od konfiguracji. Konfiguracja była nie do ruszenia
No i teraz próby dogadywania się co autor miał na myśli
Poczym dostałem informację zwrotną
Za dużo się pytam
Potrzebuje dokładnie opisanych taskow
W innym projekcie był pm czy tam analityk który stosował ozdobniki, ale tak, że to trzeba było konwencję zrozumieć
Np italic na środku to był nowy temat a nie odniesienie się do tego co powyżej
Przykład :
Lorem ipsum
Lorem ipsum
Lorem ipsum
Itp szyfry, także na początku jak dostałem historyjkę to uczyli mnie jak ją czytać
źle,słabo, dziwnie opisane taski to wg mnie nie jednemu siwych włosów dodały, a i kurwowanie nie raz na to było