cześć ;]
od jakiś paru tygodni (3-4, sam już nie pamiętam) pracuję jako młodszy programista.
kilka małych rzeczy już załapałem, ale wciąż moja wiedza znacząco odbiega od innych. zrobiłem pare małych funkcjonalności, ludzi w pracy mam spoko, costam mi zawsze podpowiedzą :) mam też opiekuna który (wydaje mi się) ma mega ogromną wiedzę, a przynajmniej przy tej jednej wielkiej aplikacji wie chyba wszystko.
W każdym razie przeważnie jak skończę przychodzi on i... ;D mówi co by tu poprawić. z jednej strony to fajne, bo cośtam się nauczę zawsze, z drugiej to troche wkruzające, bo wydaje mis ie ze cos wymyslilem/zrobilem zeby zdiałało w miarę optymalnie, a potem i tak w 50-60% to muszę zmieniać na jego wizję ;)
co mnie też denerwuje, myslalem ze umiem juz jako tako c#/.net, sam sobie pisałem projekty na uczelnie, a tu w pracy... no lekkie zderzenie ze ścianą szczerze.
jakie u was były początki? szybko staliście się bardziej samodzielnymi pracownikami?
jak to w ogole jest w firmach, jeżeli chodzi o kod. Czy są firmy robiące nieco mniejsze aplikacje, gdzie kod jest 'łatwiejszy', 'brudniejszy' czy jak to tam nazwać? ja niestety pracuje w zespole 25 osobowym, a nad całym projektem siedzi ~80 ludzi... robię głównie w .net i troszkę javascripta jak mi się akurat zadanie we frontendzie trafi.
ciekawi mnie też czy są jakieś małe firmy (albo inaczej - firmy nie mające dużego działu it, gzdie programowaniem zajmuje się taki 'zwyczajny' informatyk), gdzie tworzy się kod raczej na potrzeby wewnętrzne ? (nie wiem jakieś api do komunikacji z innymi firmami, jakieś systemy z formularzami i takie pierdółki?
- Rejestracja:prawie 8 lat
- Ostatnio:prawie 8 lat
- Postów:30
- Rejestracja:około 11 lat
- Ostatnio:około godziny
- Postów:8403
a potem i tak w 50-60% to muszę zmieniać na jego wizję
Wykorzystaj to i dopytaj się szczegółów, dlaczego on uważa, że coś powinno być zrobione tak czy nie inaczej. Często ludzie bardziej doświadczeni zrobili już na maksa dużo pomyłek w przeszłości i teraz wiedzą, czego unikać i co w jakiej sytuacji się może rozkraczyć. Proś o wędkę, a nie rybę. Nie bój się przyznać, że czegoś nie rozumiesz.
Zakładam optymistycznie, że faktycznie tamten "opiekun" ma rację i ma spoko podejście - a nie zawsze tak musi być, osoba doświadczona również może się też mylić, albo mieć różne odchyły nie zawsze sensowne.
A ten fragment:
W każdym razie przeważnie jak skończę przychodzi on i... ;D mówi co by tu poprawić.
z jednej strony to fajne, bo cośtam się nauczę zawsze, z drugiej to troche wkruzające,
bo wydaje mis ie ze cos wymyslilem/zrobilem zeby zdiałało w miarę optymalnie,
a potem i tak w 50-60% to muszę zmieniać na jego wizję ;)
sugeruje jakieś braki w komunikacji (nie wiem z czyjej strony, może nikt nie zawinił, ale jeśli junior robi coś przez jakiś czas, i potem okazuje się, że nie tak jak trzeba - to gdzieś zawiodła komunikacja/organizacja pracy w zespole).
- może za mało/za rzadko się konsultujesz (jak są takie problemy, to lepiej upewnić się np. "zrobiłbym to w sposób X, czy myślisz, że będzie to dobre?")
- może za słabo ci tłumaczą, może zadania są zbyt słabo określone, może zbyt mało poświęcają czasu na wdrożenie cię w system
- może przydzielili cię do złego kawałka kodu (jeśli "opiekun" cały czas się czepia, to może sam powinien robić te taski, które tobie wyznaczył? Niestety, pewni ludzie mają silne poczucie "code ownership" i brak jakiejkolwiek umiejętności delegacji zadań - wtedy cokolwiek zrobisz i tak będzie źle, bo nie będzie tak idealnie jak tamten ktoś by zrobił).
- z drugiej strony może faktycznie masz jeszcze słabe skille techniczne, i piszesz zły kod, nie można tego wykluczyć.
jakie u was były początki? szybko staliście się bardziej samodzielnymi pracownikami?
To zależy. Jeśli wchodzisz do projektu, który jest już rozwijany od jakiegoś czasu, to zwykle na początku będziesz niesamodzielny i będziesz musiał pytać o wszystko. Doświadczenie ogólnoprogramistyczne nie ma nic do rzeczy, bo nowy projekt = nowe wyzwanie. Każdy jest juniorem, jak wchodzi jako nowa osoba do istniejącego już projektu, choćby miał z 10 lat doświadczenia.
Chyba, że zaczynasz cały projekt od nowa. Ale wtedy też raczej nie będziesz samodzielnym pracownikiem, bo samodzielność raczej rzadko istnieje w firmach IT, nawet jest traktowana jak wada w środowiskach, gdzie dużo ważniejsza jest praca zespołowa (mnie się to nie podoba specjalnie, praca zespołowa to zwykle zabójca produktywności, ale cóż).
nieno jasne żę pytam czemu tak a nie inaczej ;) i mi tłumaczy i wtedy wiem. ale trochę to wkurzające ;] ogolnie jest spoko. fakt mało pytam, ale na szczescie mam duzo czasu no i lubie popróbować pół dnia po swojemu a potem dopiero pytać.
no moze te 50-60% to zle powieziane...
a co do reszty pytań wypowie się ktoś? są takie małe firmy które zatrudniaja 'pojedynczych' programistow?
- Rejestracja:prawie 8 lat
- Ostatnio:prawie 8 lat
- Postów:30
- Rejestracja:ponad 8 lat
- Ostatnio:2 minuty
- Postów:712
Ciesz się, bo nie każdy junior ma luksus code review. W mojej poprzedniej firmie gdzie projekty były trochę mniejsze i mniej budżetowe nikt mi niczego poprawiał, zero code review. ma działać i w miarę nie nierozsypywać reszty. W obecnej firmie wygląda to zupełnie inaczej, projekty trochę większe, niektóre na dużo wyższą skalę no i jest code review. Podobnie jak Ty również mam wiele feedback'ów kodu, ale to tylko mnie motywuje do dalszej pracy i nauki.
- Rejestracja:prawie 8 lat
- Ostatnio:9 miesięcy
- Postów:671
łestajs napisał(a):
W każdym razie przeważnie jak skończę przychodzi on i... ;D mówi co by tu poprawić. z jednej strony to fajne, bo cośtam się nauczę zawsze, z drugiej to troche wkruzające, bo wydaje mis ie ze cos wymyslilem/zrobilem zeby zdiałało w miarę optymalnie, a potem i tak w 50-60% to muszę zmieniać na jego wizję ;)
I dobrze, bo zawsze będą zmiany. Nawet jak architektura będzie w sam raz, to się np. niespodziewanie zmienią wymagania klienta i to jest codzienność. Dlatego sztuka polega na pisaniu w taki sposób, żeby w razie potrzeby wszystko się dało łatwo i względnie bezboleśnie przebudować.
co mnie też denerwuje, myslalem ze umiem juz jako tako c#/.net, sam sobie pisałem projekty na uczelnie, a tu w pracy... no lekkie zderzenie ze ścianą szczerze.
Sam akurat nie kończyłem informatyki, ale powszechny pogląd jest taki, że studia tak sobie przygotowują do zawodu programisty.
Pisanie wyłącznie "samemu sobie", co gorsza w myśl zasady "zaliczyć i zapomnieć o kodzie" nie rozwija dobrych nawyków, a wręcz przeciwnie.
jak to w ogole jest w firmach, jeżeli chodzi o kod. Czy są firmy robiące nieco mniejsze aplikacje, gdzie kod jest 'łatwiejszy', 'brudniejszy' czy jak to tam nazwać?
Wedlug mnie lepiej pracować w firmach, która robi projekty na zlecenia zewnętrzne. Częściej będą to bowiem projekty tworzone od zera, albo w każdym razie od wczesnych stadiów. Wtedy można się silić na pisanie wszystkiego czysto i nie ma problemu, że nie znamy historycznego kontekstu systemu.
Firmy produktowe, które robią swój własny soft, przeważnie rozwijają go od dawien dawna (no chyba, że akurat załapiemy się do startupu, gdzie z kolei będzie zjawisko pośpiechu). Wskutek tego nieraz ciągnie się za nimi ogon długu technologicznego i w kodzie trudno się rozeznać, tyle tam jest warstw syfu. Występuje wówczas patologiczne zjawisko "najstarszych górali", którzy są żywą formą dokumentacji i do których trzeba pielgrzymować po oświecające wskazówki, jeśli chcemy zrobić cokolwiek produktywnego.
ja niestety pracuje w zespole 25 osobowym
To już nie "zespół", tylko jakiś kołchoz. Zespół liczący więcej niż 10 osób to sprawa bardzo podejrzana. Nawet Jezusowi to nie wyszło.
Warto zwrócić uwagę, że wielkość zespołu nie ma związku z wielkością samej firmy. Firma może mieć kilkadziesiąt tysięcy pracowników, a mimo to będą w niej małe (normalne) teamy.
ciekawi mnie też czy są jakieś małe firmy (albo inaczej - firmy nie mające dużego działu it, gzdie programowaniem zajmuje się taki 'zwyczajny' informatyk), gdzie tworzy się kod raczej na potrzeby wewnętrzne ? (nie wiem jakieś api do komunikacji z innymi firmami, jakieś systemy z formularzami i takie pierdółki?
Pewnie są, ale ja osobiście nie chciałbym w takiej pracować i z wielu względów bym to odradzał, szczególnie komuś początkującemu.