Problemy wdrożeniowe

2

Witam, rozpocznę od wstępu, który przybliży bardziej moją sytuację.

Studiowałem kierunek niepokrewny do informatyki, jednak w połowie ubiegłego roku zainteresowałem się programowaniem, a konkretnie językiem C++. Przerobiłem kurs ze strony cpp0x.pl, spodobało mi się więc potem zakupiłem książkę "Język C++. Szkoła programowania." Praty. Przeczytałem ją od deski do deski plus wykonałem ćwiczenia programistyczne po każdym rozdziale. Nie wykonałem jednak jakiegoś większego projektu w tym języku. Pomyślałem, że fajnie byłoby sprawdzić jak dużo mi brakuje, aby załapać się na juniora w tej technologii. Nauczyłem się podstaw Gita i podstawowych komend Linuxowych. Wysłałem kilka CV, ku mojemu zdziwieniu wiedza, którą nabyłem wystarczyła, aby przejść pozytywnie proces rekrutacji w jednej z korporacji. I tak od stycznia rozpocząłem pracę na stanowisku juniora.

W pierwszym tygodniu konfiguracja środowiska. W drugim tygodniu dostałem pierwszego taska. Ogólnie rzecz biorąc zadanie polegało na tym, żeby przekopiować istniejące już w innym miejscu projektu rozwiązanie problemu podobnego do mojego. Szokiem dla mnie było to jak ogromny jest projekt, po którym się poruszam, ogarnięcie zależności pomiędzy poszczególnymi software unitami i to gdzie wstawić konkretne elementy. Choć zadanie szło mi jak krew z nosa to ostatecznie, również dzięki pomocy teamu udało mi się po jakichś 3 tygodniach dostarczyć rozwiązanie pokryte testami. Drugi task polegał na refaktoryzacji sposobu przechowywania danych jednej z klas. Zanim w ogóle ruszyłem musiałem nieco doczytać o bibliotece STL. Tutaj miałem już dużo więcej problemów, ponieważ było wiele software unitów powiązanych z tym refaktoryzowanym i wywaliło się wiele testów. Zadanie znów szło mi jak krew z nosa. Jednak dzięki pomocy teamu, pracy po godzinach i "debuggowaniu dupą" udało się doprowadzić sprawę do końca razem z pokryciem testami w 1,5 miesiąca. Po tym okresie zostałem poinformowany o tym, że pozytywnie przeszedłem okres próbny, co nie było wcale takie pewne.

W kolejnym miesiącu mój zespół dostał nowego ficzera. I tak przez tydzień każdy zapoznawał się z dokumentacją tego jak ficzer ma w ogóle działać. Następnie ficzer został podzielony na poszczególne etapy i tak jeden z nich losowo został mi przydzielony do implementacji i pokrycia testami. No i niestety od dwóch dni nic a nic nie ruszyłem do przodu, choć wcale się przez ten czas nie opierdzielałem i wiem co ma zostać zakodowane. Problem jest w tym, że nie potrafię znaleźć miejsc z projekcie, w których ten kod wklepać. W drugim podejściu próbowałem zacząć od napisania testów, jednak też nie wiem, w którym miejscu projektu je napisać. Dodatkowo nie pocieszający jest fakt, że lider zespołu stwierdził, że moją część jest króciutka i można ją szybciutko klepnąć. No cóż czeka mnie trudna rozmowa z PMem.

Reasumując, dotychczas taski szły mi jak krew z nosa, ale jakoś finalnie udało mi się je realizować. Minęły jednak około 4 miesiące, a ja nadal poważne problemy mam z orientacją w dużym projekcie. Problemy w tym gdzie znaleźć miejsca, w których wklepać konkretne rzeczy. Czuję się jak debil, bo pozostali członkowie zespołu klepią kod aż miło popatrzeć. Osobiście uważam, że powinienem taski realizować szybciej i po takim czasie już orientować się w miarę w projekcie, a co Wy o tym sądzicie? Poza tym moje przygotowanie przed pracą pozostawia sporo do życzenia, myślicie że realizacja samodzielnie kilku większych autorskich projektów sprawiłaby, że nie miałbym takich problemów w pracy?

1

Jest jakaś dokumentacja?

3

"Dodatkowo nie pocieszający jest fakt, że lider zespołu stwierdził, że moją część jest króciutka i można ją szybciutko klepnąć"

Jeśli ktoś twierdzi, że coś jest proste i oczywiste, to jest to proste i oczywiste dla niego ;-) Zapytaj lidera zespołu o wskazówki, w którym miejscu kodu zacząć.

0

Trochę podobna sytuacja do twojej. Nowa praca, system wewnętrzny. Tyle, że u mnie wygląda to tak, że na każe pytanie ludzie z teamu odpowiadają rzeczowo i spokojnie tłumaczą, dzięki czemu mija 2 tydzień a ja ogarniam już na prawdę sporo, co gdzie i jak.

1

To że na początku się nie ogarnia jest całkowicie normalne. Fakt że tyle Ci zajmuje ogarnięcie gdzie wprowadzic zmiany może świadczyć o problemie z podejściem do nowych członków zespołu, niekoniecznie z Tobą.

0

Sry za offtop.
Często przyjmuje się juniorów po tutorialu/książce?
Autorze to pytanie nie nawiązuje bezpośrednio do Ciebie czy Twoich kompetencji.

0

Do dyspozycji jest dokumentacja ficzerów powiązanych z tym do zrealizowania.

3

No i niestety od dwóch dni nic a nic nie ruszyłem do przodu, choć wcale się przez ten czas nie opierdzielałem i wiem co ma zostać zakodowane. Problem jest w tym, że nie potrafię znaleźć miejsc z projekcie, w których ten kod wklepać

Już dwa dni temu powinieneś spytać kogoś z teamu o to.

1

Nie bój się pytać jak czegoś nie wiesz. Jak piszesz jest dokumentacja, a to już jest połowa sukcesu. Druga połowa sukcesu to jasno powinno wynikać z dokumentacji co i jak należy zmienić w systemie. Jak nie wynika to jasno z dokumentacji to znaczy, że jest źle opracowana.

0

Jesteś juniorem, więc się uczysz. Nie bój się pytać jak czegoś nie wiesz. Jak piszesz jest dokumentacja, a to już jest połowa sukcesu. Druga połowa sukcesu to jasno powinno wynikać z dokumentacji co i jak należy zmienić w systemie. Jak nie wynika to jasno z dokumentacji to znaczy, że jest źle opracowana.

2

Dodatkowo nie pocieszający jest fakt, że lider zespołu stwierdził, że moją część jest króciutka i można ją szybciutko klepnąć

Akurat takie rzeczy to puszczaj mimo uszu. Praktycznie wszystkie moje taski były szacowane przez kierwonictwo na "godzinkę". Z tzw. godzinki już się śmieję. Dla jasności dodam, że niejednokrotnie task na godzinkę robiłem nieraz 2 tygodnie.

Więc to, że oni by chcieli żeby task był oddany migiem to jest oczywista oczywistość.

1

W drugim tygodniu dostałem pierwszego taska. Ogólnie rzecz biorąc zadanie polegało na tym,
żeby przekopiować istniejące już w innym miejscu projektu rozwiązanie problemu podobnego do mojego.

Copy paste czasem jest najprostszym wyjściem w pewnych sytuacjach (brak właściwych abstrakcji, zbyt przekombinowany projekt), chociaż powoduje to dalszą entropię projektu. Więc jeśli projekt już jest chaotyczny, to robiąc kopiuj wklejki jeszcze bardziej go zaśmiecasz.

Szokiem dla mnie było to jak ogromny jest projekt, po którym się poruszam, ogarnięcie zależności
pomiędzy poszczególnymi software unitami i to gdzie wstawić konkretne elementy.

A dla mnie to nie jest szok. Jeśli firma, która zatrudnia juniorów i wrzuca ich na głęboką wodę z poleceniem "weź przekopiuj i wklej rozwiązanie z innego miejsca projektu", to projekt wygląda, jak wygląda (przed tobą pewnie wiele innych juniorów to samo robiło).

Tutaj miałem już dużo więcej problemów, ponieważ było wiele software unitów powiązanych z tym refaktoryzowanym i wywaliło się wiele testów

Jeśli wywaliło się wiele testów, to należałoby się cieszyć, że te testy były. Gdyby ich nie było, to byś wprowadził ileś bugów do projektu, nawet nie wiedząc (czyli nie taki zły ten projekt). No chyba, że to były fragile tests (np. testy, które odzwierciedlaja 1:1 kod źródłowy i się rozwalą przy każdej najdrobniejszej refaktoryzacji)

W kolejnym miesiącu mój zespół dostał nowego ficzera. I tak przez tydzień każdy zapoznawał się z dokumentacją tego jak ficzer ma w ogóle działać.
Następnie ficzer został podzielony na poszczególne etapy i tak jeden z nich losowo został mi przydzielony do implementacji i pokrycia testami.

Brzmi jak jakieś patologiczne agile. A raczej najpierw jest waterfall (przez tydzień każdy zapoznawał się z dokumentacją tego jak ficzer ma w ogóle działać), a potem idziecie w agile i dzielicie ten waterfall arbitralnie na odcinki i przydzielacie randomowo do ludzi. Hurra, agile. Programowanie zwinne randomowe.

Zadania nie powinny być przydzielane randomowo, tylko kto się najbardziej na czymś zna, albo ma pomysł jak coś zrobić, to powinien to robić. Poza tym jeśli robicie jakiś konkretny ficzer to ktoś powinien panować nad całością implementacji. A tutaj można powiedzieć, że działacie fragmentami, zapominając, że projekt/ficzer jest całością.

Wygląda tak, jakbyście nie mieli leada/PMa, a jeśli macie to widocznie jakiegoś niekompetentnego, który zostawia ludzi samopas i ma podejście "jakoś to będzie".

lider zespołu stwierdził, że moją część jest króciutka i można ją szybciutko klepnąć.

Jak dla niego można szybciutko klepnąć, to niech klepie. Bo albo:

  • (zakładając, że lider jest programistą) faktycznie on jest bardziej kompetentny, żeby robić. Niech to robi.
  • albo się mądrzy bez pokrycia (szczególnie, jeśli jest osobą nietechniczną, dla nich wszystko to 5 minut roboty. Albo jeśli osobą techniczną, ale jeśli nie widział kodu, nie siedzi w okopach konkretnego projektu/czy nawet konkretnego modułu). Wtedy gość po prostu pieprzy głupoty.

Minęły jednak około 4 miesiące, a ja nadal poważne problemy mam z orientacją w dużym projekcie.
Problemy w tym gdzie znaleźć miejsca, w których wklepać konkretne rzeczy.

Jeśli piszesz w C++, to są tam jakieś narzędzia, które pomagają wizualizować kod, np. https://www.sourcetrail.com/
ale nie korzystałem z tego, bo nie piszę w C++. Chociaż do JSa by się coś takiego przydało. Też miałem z tym problem. Ludzie najpierw piszą przeinżynierowane projekty, a potem liczą, że ktoś się szybko w to wdroży, i to tylko czytając setki plików źródłowych, bez żadnego przewodnika, czy narzędzi do eksploracji kodu. Bezsens (ale to problem całej branży programistycznej).

3

Dodam jeszcze od siebie ze sztuka bycia juniorem polega również na świadomości kiedy spytać kogoś o pomoc. To źle jeśli junior pyta co chwilę o najprostsze rzeczy które można znaleźć w 2min w Google, ale jeśli się nad czymś głowi od dłuższego czasu i nie prosi o pomoc wcale nie jest lepsze. Spójrz na to z innej perspektywy- inni programiści maja tez swoje zajęcia i jeśli nie dajesz jasno znać że utknąłes z czymś to zakładają że wszystko jest OK.

0

Gosciu, wzieli cie na juniora a nawet STL nie znales? :O

2
Aventus napisał(a):

Dodam jeszcze od siebie ze sztuka bycia juniorem polega również na świadomości kiedy spytać kogoś o pomoc. To źle jeśli junior pyta co chwilę o najprostsze rzeczy które można znaleźć w 2min w Google, ale jeśli się nad czymś głowi od dłuższego czasu i nie prosi o pomoc wcale nie jest lepsze. Spójrz na to z innej perspektywy- inni programiści maja tez swoje zajęcia i jeśli nie dajesz jasno znać że utknąłes z czymś to zakładają że wszystko jest OK.

Seniorzy w nowym projekcie / firmie, to tez juniorzy. Wiem z autopsji.

0

Ale jest znaczaca roznica miedzy "juniorem juniorem" a doswiadczonym programista zaczynajacym w nowym projekcie czy firmie.

1 użytkowników online, w tym zalogowanych: 0, gości: 1