Wpis z mikrobloga

@g1venchy: to zależy raczej od planowania. Jak przychodzi nowa osoba, to się szuka zadania żeby ta osoba miała okazję poznać projekt od strony kodu. Choćby to miała być jakaś literówka. Ale tak żeby przeszedł ścieżkę kodowania -> wrzucenie kodu -> code review -> merge.
@g1venchy: za dużo zmiennych. Np. w projekcie w którym teraz jestem najgorszy nie był wcale poziom skomplikowania, tylko fakt, że oba systemy: nowy i stary są rozwijane równocześnie i jak się słuchało teamu to w zasadzie nie szło zrozumieć o której części rozmawiają, bo obie robią to samo (tylko inaczej)
@non-serviam: Przechodzi „szkolenie na maszynie” - wciela się w rolę operatora naszych maszyn, żeby dokładnie poznać produkt. Następnie zapoznaje się projektami, które rozwija nasz dział. Później w zależności od sytuacji, dostaje do zrobienia jakieś proste narzędzia albo pierdoły w którymś z projektów na rozgrzewkę i w zależności od tego, gdzie się bardziej nadaje, przechodzi do teamu A lub teamu B i zaczyna pracę ( ͡° ͜ʖ ͡°)