Jak wyciągnąć jak najwięcej z dużej odpowiedzialności na początku kariery?

Cześć,
Programuję w backendzie, mam niecały rok doświadczenia i wraz z niezbyt doświadczonym zespołem (średnia z 2 lata) właściwie projektujemy i implementujemy całą nową wersję systemu. W dużej mierze ma robić podobne rzeczy co poprzednia wersja, więc możemy uczyć się z jego błędów oraz zostawiać te rzeczy, które się sprawdziły, ale większość architektury została opracowana przez nas od nowa.

Nie łudzę się, że wszystko będzie super, bo na pewno wieloma rozwiązaniami strzelimy sobie w stopę, a ja jestem jedną z bardziej zaangażowanych osób i chociaż bardzo się staram, to no nie oszukujmy się, daleko mi do odpowiednich kompetencji, a nie ma nikogo wystarczająco doświadczonego, aby skorygował złe decyzje.

Pytanie do Was, czy macie jakieś rady jak najwięcej wyciągnąć z takiego doświadczenia?
Pierwsze co nasuwa mi się na myśl to, że fajnie będzie zobaczyć kiedyś (albo usłyszeć od kolegów jeśli po drodze zmienię prace) konsekwencje swoich wyborów.

Ja sugeruje uciekac jaknajszybciej z firmy, ktora architekture zostawia juniorom.

"If you're the smartest person in the room, you're in the wrong room."

Tak, z takich względów nie podejrzewam, że długo zostanę w tej firmie, ale aktualnie jestem w takiej sytuacji i zamiast wyłącznie narzekać, to chciałbym spróbować coś z tego wyciągnąć.

właściwie projektujemy i implementujemy całą nową wersję systemu. W dużej mierze ma robić podobne rzeczy co poprzednia wersja,
więc możemy uczyć się z jego błędów oraz zostawiać te rzeczy, które się sprawdziły,
ale większość architektury została opracowana przez nas od nowa.

Kto robił starą wersję? Też wy, czy ktoś wcześniej?

Pytanie do Was, czy macie jakieś rady jak najwięcej wyciągnąć z takiego doświadczenia?

Możecie zapisywać gdzieś (np. na firmowym issue trackerze, albo w dokumentacji w repo) opisy tego, co zrobiliście do tej pory jakimi sposobami i jaki był tego efekt. Czyli większa dokumentacja, ale nie dokumentacja "jak korzystać z projektu" tylko dokumentacja procesu developerki, tego co się udało, co się nie udało.

Bo w każdym dłużej prowadzonym projekcie wcześniej czy później pojawi się pewien know-how i refleksja na temat tego, co się sprawdziło, a co nie (i narzekania typu "cholera, w niezłe g**no się wpakowaliśmy, gdybyśmy tylko miesiąc temu zrobili inaczej"). I teraz tak - można taką wiedzą dzielić się jedynie ustnie na spotkaniach z kubkiem kawy w ręku - a można to wszystko ładnie spisać dla potomnych (najlepiej w jakiś uporządkowany sposób, z podziałem na kategorie, tak żeby ułatwić późniejsze przeszukiwanie).

Dzięki spisaniu łatwiej będzie dzielić się wiedzą w zespole, nawet jak ktoś nowy wejdzie w projekt, będzie mógł poczytać historię pewnych decyzji, dowiedzieć się z czego pewne problemy wynikały, nabrać ogólnego oglądu. Także sami będziecie mogli się cofnąć i przejrzeć uprzednio zdobytą wiedzę.

podobne podejście jest widoczne w tym artykule choćby: https://dev.to/jlhcoder/just-in-time-documentation
o czymś takim mówię mniej więcej.

LukeJL napisał(a):

właściwie projektujemy i implementujemy całą nową wersję systemu. W dużej mierze ma robić podobne rzeczy co poprzednia wersja,
więc możemy uczyć się z jego błędów oraz zostawiać te rzeczy, które się sprawdziły,
ale większość architektury została opracowana przez nas od nowa.

Kto robił starą wersję? Też wy, czy ktoś wcześniej?

Ktoś wcześniej, już pracują w innych firmach.

Dzięki za radę, na pewno się przyda!

Kto robił starą wersję? Też wy, czy ktoś wcześniej?
Ktoś wcześniej, już pracują w innych firmach.

Bierz przykład z bardziej doświadczonych kolegów

1. Zanim COKOLWIEK napiszciecie przygotujecie scenariusze testowe i masę testów integracyjnych / akceptacyjnych jeśli faktycznie macie dostarczyć te same funkcjonalności.
2. Generalnie zalecałbym taktykę "ostatni gasi światło" bo ten projekt to raczej będzie masakra i ksiazkowy przykład "marszu ku klęsce".

@Shalom: Mam wrażenie, że patrzysz na wszystkich młodych programistów przez pryzmat siebie za czasów juniora. Niektórzy jednak mają znacznie większą wiedzę i są bardziej ogarnięci bo czytają literaturę branżową zanim podejmą konkretną decyzję dotyczącą architektury. Jeśli napotykają problem to szukają u innych (internet, blogi, książki) rozwiązań. Nie oznacza to automatycznie, że projekt nie odniesie porażki, ale "doświadczeni" seniorzy grzebiący od lat w tym samym gównie mogliby być jeszcze bardziej szkodliwi - bo oni wiedzą lepiej i nie muszą szukać porad bo przecież są "seniorami". Zespół młodych ludzi z odpowiednią dozą pokory może zdziałać naprawdę wiele - głównie dlatego, że będą szukali rozwiązań u mądrzejszych od siebie (choćby online), a nie zawierzali projektu swojemu "doświadczeniu". Dlatego @Shalom więcej pokory życzę również i Tobie.

license napisał(a):

@Shalom: Mam wrażenie, że patrzysz na wszystkich młodych programistów przez pryzmat siebie za czasów juniora.

To leciało jakoś tak: - jeden senior zrobi w miesiąc więcej niż 100 juniorów w rok.

Zespół młodych ludzi z odpowiednią dozą pokory (...)

a chwilę przed

Mam wrażenie, że patrzysz na wszystkich młodych programistów przez pryzmat siebie za czasów juniora. Niektórzy jednak mają znacznie większą wiedzę i są bardziej ogarnięci

No pokora to od Ciebie bije na milę świetlną ;-)

"doświadczeni" seniorzy grzebiący od lat w tym samym gównie mogliby być jeszcze bardziej szkodliwi - bo oni wiedzą lepiej i nie muszą szukać porad bo przecież są "seniorami"

Ignoranta w zespole będzie szkodliwy niezależnie od posiadanej przez niego wiedzy.

license napisał(a):

@Shalom: Mam wrażenie, że patrzysz na wszystkich młodych programistów przez pryzmat siebie za czasów juniora.

Zielonka próbuje pociskać (czy jakoś tak to szło).