Chyba mam za duże oczekiwania, więc pytanie: jak powinien wyglądać początek pracy programisty z doświadczeniem tzw. regular? Czy ktoś powinien go prowadzić za rękę, czy powinien sam przeglądać projekt i się uczyć? A co, jeśli nie umie czegoś ważnego, np. języka, frameworka?
0
0
Jeśli nie umie języka używanego w projekcie to jak mógł przejść proces rekrutacji?
Jeżeli było wiadome, że ma braki i będzie musiał trochę się poduczyć na początku to nie widzę problemu.
0
Powinien sam przeglądać i działać.
12
W dobrej firmie pracownika wprowadza się zarówno w firmę (jak działa, jakie są procedury, co i gdzie załatwić, co się należy itd.) jak i w projekt (co jest robione, co kto robi i za co jest odpowiedzialny, jakie narzędzia itp). W innych sadza się go przed komputerem i ma się w d...ie całe to wprowadzanie. Która wersja jest lepsza? Odpowiedzcie sobie sami.
8
czy powinien sam przeglądać projekt i się uczyć?
Jak sobie to wyobrażasz w projekcie na kilkaset tysiecy linii kodu? o_O Zresztą tu nawet nie chodzi o jako takie wprowadzenie w kod, bo jak nazwy modułów i pakietów mają sens to sobie człowiek nawet może i poradzi. Chodzi o wprowadzenie do architektury przynajmniej. Trudno cokolwiek zrobic kiedy nie wiesz w jaki sposób dane płyną przez system, co jest składowane w bazie X a co w Y, które akcje są obsługiwane przez jakieś asynchroniczne handlery itd.
6
Moim zdaniem na pewno nie zostawić go samego, przy dużych projektach nawet zdolna osoba, dobrze rokująca (taki nie oszlifowany diament) może się pogubić tym bardziej gdy zespół czasami liczy tylko dwie osoby to już totalnie ciężko takiej osobie się wdrożyć. A przez wszystkie lata nauki może mieć problem z proszeniem o pomoc. W końcu uczą nas, że za niewiedzę się kara.
A czasami osoba przez to, że zostawiliśmy ją samą z np ogromną bazą danych oraz dla tej osoby z totalnie nie czytelnym kodem może spowodować, że ta osoba sama nie będzie wiedziała za co się najpierw zabrać, a co gorsza o co pytać. Trzeba ją w takiej sytuacji nakierować. Interesować się. Doradzać, zobaczyć w jaki sposób najlepiej się uczy.
Dobrą strategią jest też zapraszanie go na spotkania - nawet te nudne. (poczuje, że jest częścią firmy/zespołu, będzie coraz bardziej się otwierać, a przy okazji osłucha się z różnych rzeczy, które mogą być dla niego nowe). Ludzie tez poznają jego imię, zaczną zapraszać na herbatę, pytać o radę/problemy (dzięki temu takie osoby też go naprowadzą co powinien wiedzieć, o co powinien dopytać zespół).
Zdarza się też, że zespół coś tłumaczy osobą trzecim, które przyszły z jakimś pytaniem - powinno się taką sytuację wykorzystać i "regular" sam przeklikał lub zobaczył gdzie znajdujemy rozwiązanie. (przy kolejnym podobnym pytaniu będzie mógł sam spróbować lub z małą pomocą wytłumaczyć).
Zadając takie pytanie na pewno chcesz dobrze dla tej osoby, mam też wrażenie, że masz na myśli konkretny przypadek pracownika, który obecnie jest w firmie ale za mały progres robi, a umowa okresu próbnego czasami się kończy więc, może (totalnie moje przemyślenie) jest jakiś łatwiejszy projekt, inny zespół w którym mógłby się sprawdzić. Jeśli jest w back to może ma bardziej predyspozycje do front lub na odwrót. Można podpytać czy robi jakiś projekt po godzinach, zobaczyć go może dzięki temu też to nas na coś naprowadzi, jak się uczy? może też naprowadzimy go jak powinien usprawnić swój projekt wykorzystując "narzędzia", które przyda mu się w pracy w tedy połączymy przyjemne z pożytecznym.
powodzenia
9
Zostawienie kogos samemu sobie ze stwierdzeniem 'masz google i kod' to najlepsza droga... Do tego, zeby ten ktos sobie poszedl po okresie probnym.
0
Shalom napisał(a):
czy powinien sam przeglądać projekt i się uczyć?
Jak sobie to wyobrażasz w projekcie na kilkaset tysiecy linii kodu? o_O Zresztą tu nawet nie chodzi o jako takie wprowadzenie w kod, bo jak nazwy modułów i pakietów mają sens to sobie człowiek nawet może i poradzi. Chodzi o wprowadzenie do architektury przynajmniej. Trudno cokolwiek zrobic kiedy nie wiesz w jaki sposób dane płyną przez system, co jest składowane w bazie X a co w Y, które akcje są obsługiwane przez jakieś asynchroniczne handlery itd.
A to co, nie ma dokumentacji? No tak, jej prawie nigdy nie ma.
0
Od autora wątku:
@Argath, nie jestem pracodawcą chcącym dobrze dla nowego pracownika. Jestem tym pracownikiem, którego się zostawia z zadaniem, chyba na zasadzie "jesteś programistą, masz doświadczenie = powinieneś umieć ogarnąć". Nie jest to moja pierwsza taka praca, więc mam wątpliwości, czyja to wina.
1
Wdrożenie nowego pracownika (nie juniora)
Nie ma czegoś takiego jak nowy pracownik nie junior. Każdy programista (choćby był seniorem) jak wchodzi do nowego dużego projektu bez dokumentacji, to staje się automatycznie juniorem, ponieważ przecież nie zna projektu, nie wie jak coś zrobić, musi się pytać itp. I powinno się takie osoby prowadzić za rączkę, a nie zostawiać samemu sobie.
I jak dla mnie to powinno się zacząć na długie miesiące przed zatrudnieniem nowej osoby
- trochę "cywilizacji" czyli: testy, dokumentacja, skrypty automatyzujące pracę itp. - tak, żeby nowa osoba mogła sobie od razu na wejściu przeczytać jakieś Readme, odpalić testy, albo jedną komendą zrobić builda.
- jako dokumentację można dołączyć również rysunki, diagramy itp. takie rzeczy łatwiej zrozumieć niż czytać ścianę tekstu
- czysty kod, dobra architektura, zachowanie KISS, DRY - takie projekty łatwiej zrozumieć niż spaghetti kod czy przeinżynierowany kod enterprise. Ale też łatwiej dodać nową funkcjonalność do dobrze zaprojektowanego projektu, niż do spaghetti.
- być może jakieś dedykowane rozwiązanie do wprowadzania w projekt, np. dedykowana przeglądarka komponentów React używanych w projekcie.
a już po zatrudnieniu:
- wprowadzenie ogólne, dłuższa pogadanka na temat projektu, przegadanie architektury, pokazanie przykładowego kodu z omówieniem, może jakieś slajdy, diagramy. No i otwarcie na pytania, dyskusję itp.
- pair programming
- osobiste zaangażowanie innych programistów (czyli "okej, odpowiem ci na twoje pytanie" a nie "sprawdź sobie w necie, bo jestem zajęty").
- jasne (i nie za trudne) zadania na start. Kod bez celu można przeglądać parę godzin, ale jednak potem lepiej już robić coś konkretnego choćby miało to być wydzielenie zduplikowanego kodu do funkcji.
- dobre warunki pracy, brak przeszkadzajek typu hałas, brak zawracania głowy co chwila, zrozumienie na to, że ktoś może chcieć się skupić i celowo nie jest zalogowany na Skype/Slacku itp.
No i czasem duperele mogą mieć znaczenie na minus albo plus: np. dostęp do firmowych repozytoriów, czasem nie tylko tych, nad którymi dana osoba pracuje - np. frontendowiec czasem potrzebuje sprawdzić coś na backendzie (zdarzało mi się, że nie miałem dostępu do repo, albo miałem dostęp tylko do części projektu itp.). Takie coś spowalnia wdrażanie się i powinno się o tym myśleć kilka dni przed zatrudnieniem nowej osoby, a nie robić akcesy dopiero kilka dni po zatrudnieniu.
Powinien sam przeglądać i działać.
Trochę na pewno tak. Ale jednak zbytnie samodzielne przeglądanie i działanie przez osobę, która nie zna projektu kończy się zwykle tym, że będzie robił to, co nie trzeba albo tracił ileś dni na coś, co można zrobić w godzinę. Więc nie jest to do końca dobra rada.
7
Z zasady świadczy to o tym, że w firmie jest kibel. Pozwala to wątpić w jakość wszelkich innych procedur, jak i samych projektów (skoro poprzedników też rzucano na głęboką wodę).
A morał z tego jest taki, że gdy na rozmowie dochodzimy do etapu "a teraz jakie pan ma do nas pytania?", zamiast uprzejmie odchrząknąć, dużo rozsądniej poprosić: "niech mi pan opowie, jak wygląda u państwa proces wdrażania nowych pracowników - jak wyglądałby mój pierwszy, drugi dzień w pracy".
0
To ile czasu trwa takie wdrażanie od momentu przyjścia do pracy, do momenty kiedy nowy pracownik jest juz w stanie robić samodzielnie zadania na firmowych projektach?
0
Nadziany Polityk napisał(a):
To ile czasu trwa takie wdrażanie od momentu przyjścia do pracy, do momenty kiedy nowy pracownik jest juz w stanie robić samodzielnie zadania na firmowych projektach?
To zalezy jak definiujesz regulara. Teraz mamy regularow z 2 letnim doswiadczeniem. Takich pewnie trzeba bedzie dlugo wprowadzac do projektu.
0
mnie wprowadzono i nadal wprowadza się w projekt ciągle ;] jestem już rok "na pokładzie", 70% zadań sam robię, ale niektóre zadania mają dość skomplikowane zależności i wtedy trzeba pytać siniora :D
bardzo mnie denerwowały pierwsze tygodnie gdy senior nie miał czasu, a ja bezmyślnie przeglądałem kod, z którego wyciągnąłęm może z 10% korzyści.
bardzo mnie też zdenerwowało, gdy kierownik kiedyś nieoficjalnie powiedział odnośnie praktykantów/juniorów, że lubi ich rzucać na głęboką wodę, bo wtedy widzi jak sobie ktoś radzi w trudnych sytuacjach - i tak robi odsiew...
co o tym sądzicie?
0
Gleboga woda to szybki i prosty sposob na odsiew slabych developerow. Ale bez ciaglej kontroli latwo sie pozbyc kogos cennego.
0
Ja sie kodu nie boje, ze nie ogarne, ze bedzie trudno. U mnie to wyglada tak, ze na razie robie wszystkie konfiguracje, czekam na dostep do serwerow, a to wszystko trwa troche dlugo, chociaz do kodu apek mam juz dostep do sklonowalem z gitlaba
3
No, najlepiej posadzic kogos przed projektem na 5 milionow linii kodu, dac taska i ma robic. Sorry, nawet uber senior nie da rady.
Tylko Wy wiecie o swoich "custom wspanialych rozwiazaniach" ...
1
Myślę że dobrym rozwiązaniem byłoby pair programming dziennie przez 3 godziny. Nowy w projekcie może na bieżąco pytać, być może nawet zaproponuje lepsze rozwiązanie. I do tego lepiej się zintegruje z zespołem.
0
Mozna posadzic kogos przed projektem, ale powinien moc pytac na poczatku o cokolwiek.
2
dukenukem3d napisał(a):
bardzo mnie też zdenerwowało, gdy kierownik kiedyś nieoficjalnie powiedział odnośnie praktykantów/juniorów, że lubi ich rzucać na głęboką wodę, bo wtedy widzi jak sobie ktoś radzi w trudnych sytuacjach - i tak robi odsiew...
co o tym sądzicie?
Sądzę, że kierownik jest kretynem marnującym czas swój (i pieniądze firmy), współpracowników i praktykantów/juniorów.
Zapewne typowy Janusz "z ambicjami zrobienia biznesu na miarę Billa Gatesa", a którego firemka od lat nie rozrosła się
do rozmiarów o wiele większswych niż około 30 tu pracowników. Prowadząca rekrutację 365 dni w roku, stale "poszukująca
nieoszlifowanych diamentów". Firma która szuka nie wiadomo jakich ludzi, ale odrzuca całkiem sporo sensownych osób,
bo kierownikowi nie spodobał się sposób w jaki praktykant otwiera drzwi do kibla, albo czesze się z przedziałkiem nie w tą
stronę, przez co "nie pasuje do środowiska kulturalnego firmy".
Jeśli chociaż jedno z powyższych zdań jst prawdziwe to czym prędzej stamtąd Spie****. Będzie lepiej tak dla twojej psychiki,
jak i kariery. Jeśli prawdziwe jest więcej niż jedno, to podejmij natychmiastowe kroki ewakuacyjne, poprzedzone rozesłaniem CV.
0
rzecz w tym, że to jedna z lepszych i bogatszych polskich firm, według niektórych rankingów....
0
no i sugeruje, zebys nie rzucal kretynami na lewo i prawo. mozna powiedziec ze dane zachowanie jest kretynskie, ale nie odnosic si ebezposrednio do osoby.
zwlaszcza, ze ten facet wydaje mi się mega mózgiem ;]
1
dukenukem3d napisał(a):
no i sugeruje, zebys nie rzucal kretynami na lewo i prawo. mozna powiedziec ze dane zachowanie jest kretynskie, ale nie odnosic si ebezposrednio do osoby.
zwlaszcza, ze ten facet wydaje mi się mega mózgiem ;]
Dlaczego nie rzucać? Jestem po czołowej polskiej uczelni. Kretynów wśród kadry trochę się spotkało. Ogarnianie jakiejś dziedziny nie przeszkadza w byciu kretynem na innych polach. Widziałem w życiu wystarczająco wielu ludzi by poznać kretyna, nawet jeśli ma tytuł naukowy i IQ wyżej 100. Poza tym widzę u ciebie początki syndromu sztokholmskiego. Przemyśl to.
0
poczatki syndromu sztkokcholmskigo nie ;]
traktuję tę firmę jako miejsce edukacji, wypłaty i fajnej atmosfery między pracownikami - tak będę traktował wszystkie firmy, bo to jest chyba idea bycia pracownikiem - to nie jest służba wojskowa.
też potrafię poznać kretyna, choć mam mniejszy staż. no wlasnie - ja znam faceta, a ty nie.
ja go potrafię ocenić jako bardzo mądrego człowieka po sposobie bycia, wypowiedzach, jego roli i jego szerszego spojrzenia na wiele rzeczy