Jak się rozwijać?

Cześć,
Pracuje już od około 2.5 roku jako programista, jednak większość tego czasu przepracowałem w firmie gdzie kompletnie nikt mojego kodu nie doglądał,
zadania były tylko zgłaszane na zasadzie - jest błąd i trzeba go naprawić, jest nowa funkcjonalność i ma działać. Zero refactoru czy jakiś nowocześniejszych technik. W projekt
wdrożyłem się dość szybko, tak samo jak szybko wykonywałem swoje zadania.

Od około pół roku pracuję jednak w innej firmie, bardzo duży projekt rozwijany od wielu lat, w podobnej technologii. Jednak tutaj, w moim zespole już dużo bardziej dba się o poziom kodu. Często gdy dostanę zadanie, wydaje mi się że mam pomysł jak to zrobić, jednak przy pierwszym pytaniu do bardziej doświadczonej osoby okazuje się że ona to widziała zupełnie inaczej i muszę przerabiać swój kod. Oprócz tego wszystko idzie mi dość wolno, myślałem że z biegiem czasu ogarnę projekt w dobrym stopniu ale jednak ciągle czegoś nie wiem, ciagle się z czymś męcze i mi dość wolno idzie. W zespole są osoby o niższym doświadczeniu 'komercyjnym' które mam wrażenie dużo lepiej sobie radzą na codzień z zadaniami, ogarniają od razu wszystkie stosowane patterny i techniki, potrafią otwarcie dyskotować i argumentować swoje pomysły na rozwiązanie. Gdy ja o coś pytam to się stresuję (ponieważ mam gdzies w sobie że po takim czasie pracy już raczej to o co pytam powinienem wiedzieć) przez co mówie strasznie nieskładnie i inni mają problemy ze zrozumieniem o co dokładniej mi chodzi.

Generalnie chodzi o to że czuję się dość słaby, jednak ciężko mi jednoznacznie stwierdzić z czego, po prostu chciałbym móc w teamie równie swobodnie co reszta wymieniać poglądy, mieć swoje za i przeciw w dyskusjach jakie rozwiązania zastosować przy danym problemie i dużo szybciej uwijać się z moimi zadaniami. Zdaje sobie sprawę z tego że po prostu powinienem się douczyć, jednak za bardzo nie wiem z czego - jedyne co przychodzi mi do głowy to jak najwięcej analizowac i zgłebiać cudzy kod, jednak tutaj nadal nie wiem, czy dany kod jest napisany prawidłowo, czy może obecnie już się czegoś nie stosuje i rozwiązuje inaczej. W domu staram się douczać nowszych technologii (w pracy jest dość przestarzała - Winforms) ale kolejne tutoriale czy małe aplikacje pisane aby ogarnąć framework nie przekładają się na tę 'ogólną' wiedzę. Więc - jak wkoczyć na ten 'level' wyżej, gdzie będe już mógł być bardziej odpowiedzialny i pewny siebie w swoich rozwiązaniach? Jakieś rady lub pomysły co mogę poprawić?

1. idźcie na piwo, zaproponuj wspólne wyjście - integrację, a jak nie wiesz jak, to dopytaj kiedy najbliższa impreza
2. rozmawiaj z ludźmi, którzy mają długi staż przy projekcie i czytaj ich kod
3. Profit :)

Te różne patterny o których piszech to chociaż ogarniasz z nazwy?
W pracy tego nie miałeś.
Robiłeś wcześniej coś z tym w szkole?

ps
Sytuacja to nie twoja wina tylko słabej rekrutacji że cię w ogóle dopuściła do pracy albo dopuściła na tym stanpowisku zamiast dać stanowisko juniora.

Ok, to zacznij od przeczytania Clean Code wujka Boba.
I możesz równolegle zacząć czytać o SOLID i starać się zrozumieć dlaczego tak a nie inaczej.
to Ci da podstawy do dyskusji i zrozumienia kodu. Następnie możesz poświęcić czas na wzorce.
To będzie lepiej spożytkowany czas dla Ciebie teraz niż nauka technologii których nie używasz jeszcze. Potrzebujesz podstaw teraz, ale nie technologii a samej inżynierii.

Wychodzi na to, że czlowiek profesjonalnie programuje już w sumie trzeci rok, bierze kase regulara albo nawet seniora. Fajne te rady, żeby zaczął czytać Head First Design Patterns i podobne podstawy. Zespół na piwie ma się z nim zintegrować czyli pomagać mu w nauce zamiast mieć w nim pełnoprawnego członka zespołu.

Warto tez zainwestowac w TDD

(Op tutaj)
Takie podstawy jak ogólne 'duże' design patterny raczej ogarniam, to samo tdd i takie podstawy jak solid. Mimo to i tak czuję się o wiele gorszy niż inni, np : zaczynamy jakiś projekt i Zaraz sypia się propozycje że tutaj będzie super zastosować patter event agregator a tutaj możemy zrobić serwis który się komunikuje z tym i tym żeby coś ładnie przeparsowac tak a nie inaczej. Teraz już wiem czemu ktoś wpadł na taki pomysł ale no właśnie- chodzi o to żebym w domu mógł samemu się szkolić w tego typu wyborach architektonicznych. Nie wiem za bardzo jak to ująć, chodź o taką ogólna naukę ale bardziej konkretnych , często wykorzystywanych wzorców, jednak nie tych najbardziej oczywistych (typu MVVM czy mvc ).

Co do Clean code- dzięki za przypomnienie , zacząłem zaglądać: )

Co do zarobków- nie wiem na jakiej podstawie sądzisz że są seniorskie, raczej średnio wysokie juniorskie : )

To, że 10 innych osób rozwiązałoby dany problem inaczej niż ty jeszcze nie świadczy, że coś jest z twoim rozwiązaniem nie tak. Świat koderki jest zapchany ćwierć, pół i całymi debilai. Gorzej, jak sam to przyznajesz iż to oni mają rację po poznaniu ich rozwiązania i umiesz wskazać powody dla których twoje jest gorsze.

Nie lam sie - masz 2.5 roku doswiadczenia - jests silnym juniorem/poczatkujacym regularem. Jestes normalny, nie jestes geniuszem. To naturalne ze osoby z wiekszym doswiadczeniem beda rozwiazywaly problemy "inaczej". Pisz/cwicz/mysl. Reszta przyjdzie sama. Z drugiej strony przeczytanie Clean Code zawsze jest dobre (tam nie ma magii - o wiekszosci wiesz, ale i tak sie przydaje przypomniec jak wazne to rzeczy)

Ok to co do tego typu rozwiązań, spróbuj zainteresować się czymś związanym z architektura właśnie, np DDD :
https://oprogramowaniu.pl/materialy-o-ddd/

A co do wstawiania wzorców na etapie projektowania, to trzeba być z tym bardzo ostrożnym, żeby nie dostosowywać rozwiązania do wzorca. Nie o to chodzi. Co nie znaczy że przy doświadczeniu pewnych rzeczy nie widać od razu.
I to też rada dla Ciebie : bierz udział w takich rozmowach, pytaj czemu tak - to dam się będziesz uczyć tego.

Ja nie raz i nie dwa posiadałem odmienną opinię na temat rozwiązań jakie warto by byo zastosować w różnych projektach. Z czasem jednak wychodziło na to, że to ja miałem pierwotnie rację, gdy projekty zabrnęły dokładnie w te ślepe uliczki których się spodziewałem. Oczywiści nikt mnie nie słuchał.