Nowe zadania dla starszych programistów

Mam starszego programistę z ośmioletnim doświadczeniem .NET, od jutra pracuję nad aplikacją zawierającą 11 000 linii kodu. W zespole jest ja i inny programista. Oboje mamy około trzyletnie doświadczenie.

To mój pierwszy projekt jako menadżer (jestem również programistą w projekcie) i po raz pierwszy musiałem przedstawić kogoś do już ustalonej bazy kodu. Oczywiście omówię każdy moduł, proces wdrażania itp. I podam im lokalizację repozytorium kontroli źródła, dokumentację (która nie jest najlepsza) itp.

Jak długo powinienem im dać, zanim będą gotowi do pisania nowych funkcji i usuwania błędów?

Przypisałbym kilka błędów o niskim priorytecie pierwszego dnia, w ten sposób nikt nie krzyczy, jeśli nie zostaną one od razu zrobione, dając nowemu deweloperowi trochę czasu na zapoznanie się z bazą kodu.

Najważniejszą rzeczą do zrobienia jest przegląd kodu całej jego pracy przez kilka pierwszych tygodni. Nie chcesz dowiedzieć się, że facet zmierza w złym kierunku lub że nie przestrzega standardów kodowania firmy miesiącami. Lepiej jest upewnić się, że wie, czego oczekuje się od samego początku, a recenzje kodu zapewniają to. Oczywiście uważam, że recenzje kodu są dobre dla wszystkich pracowników (sprawdzamy 100% naszego kodu przed wdrożeniem), ale są krytyczne dla nowych pracowników i powinny być wykonywane osobiście, w którym można odpowiedzieć na pytania i skierować ich do dokumentacji, której mogą nie mieć widać jeszcze, jeśli zajdzie taka potrzeba.

Czego nie chcesz, to nowy facet przychodzący i używający innego stylu niż reszta z was. Ludzie często próbują nadal używać stylu kodu z poprzedniej pracy, nawet jeśli jest on sprzeczny ze stylem kodu używanym w nowym miejscu, co może powodować zamieszanie i irytację ze strony innych programistów.

Jedną z rzeczy, które zauważyłem nawet w przypadku doświadczonych programistów, jest to, że niektóre z nich nie są tak dobre, jak się wydaje w wywiadzie, przegląd kodu pomoże ci to szybko znaleźć, więc możesz to naprawić. To również zachęci ich do zrobienia czegoś, widziałem, jak nowi pracownicy, którzy nie zostali poddani przeglądowi kodu, wyciągają projekt, nie pokazując nikomu, co robią, a następnie odchodzą na tydzień przed terminem, o którym wiedzieli, że nie zamierzają uderzyć, ponieważ byli nad głowami i tak naprawdę nie ukończyli żadnej części projektu. Lepiej sprawdzać wcześnie i często z nowymi ludźmi, dopóki nie będziesz naprawdę pewien, że się wypracowują.

Poza tym normalne jest, że nowy facet jest przerażony stanem twojego starszego projektu. Nie jest tak zaprojektowany, jak powinien. Spodziewaj się tego, wysłuchaj go i nie odrzucaj automatycznie wszystkiego, co mówi. W szczególności ta osoba wydaje się mieć więcej doświadczenia niż ty lub inni programiści, może zobaczyć rzeczy, których nie wziąłeś pod uwagę. Jednak jako menedżer musisz zrównoważyć proponowane zmiany z bieżącym obciążeniem pracą i terminami. Wszyscy możecie zainwestować trochę czasu w naukę, jak refaktoryzować istniejący kod i zainwestować kilka godzin w swoje oszacowania czasu, aby to zrobić, szczególnie jeśli nowy facet ma jakieś uzasadnione obawy. Prawdopodobnie nie jesteś w stanie wesprzeć całkowitego przepisywania (wiele osób, które przychodzą w nowym wydaniu, uważa, że ​​powinniśmy zacząć od nowa i zrobić to lepiej)

Jeśli masz trochę czasu, w którym nie oczekuje się od niego pełnego udziału (i pełnego rozliczania swojego czasu przez klienta), może to być również czas, kiedy może zacząć od refaktoryzacji rzeczy, które chciałeś zrobić, ale których nie chcesz ” miałem czas do zrobienia. Czasami dobrze jest wykorzystać okres szkolenia nowej osoby, aby zająć się niektórymi sprawami, których nie ma w planie projektu. Mogą nauczyć się podstawy kodu i jeśli to, co chcą zrobić, nie działa, nie wpłynąłeś na istniejące harmonogramy, ponieważ nie uwzględniłeś ich w istniejącym harmonogramie. A jeśli to zadziała, możesz mieć dużą wygraną, ułatwiając przyszłą konserwację, bezpieczeństwo lub cokolwiek innego.

Natychmiast uruchamiaj je przy małych zadaniach - rzeczach, które nie wymagają większego obrazu.

W miarę, jak stają się bardziej pewni siebie i zaznajomieni z bazą kodu, uczą się coraz większych zadań. To, jak szybko to się dzieje, zależy głównie od nich.

Zawsze lubię przypisywać mi zadania od samego początku, mając na uwadze, że przekopanie kodu zajmie znacznie więcej czasu, a w ciągu pierwszych kilku dni / tygodni zostanie zadanych wiele pytań.

Uważam, że nie jestem w stanie całkowicie owinąć głowy wokół projektu, dopóki nie będę musiał wejść i naprawić lub zmienić coś.

Również ... Bez względu na to, jak myślisz, jak dobrze wyjaśniłeś, jak działa projekt, zawsze pojawia się „och, tak, zapomniałem ci powiedzieć”, „natrafiliśmy na ten problem, więc zrobiliśmy to”, które nie zostały dokuczone, dopóki faktycznie zaczynasz pracę.

Jak długo?

Jak długa jest lina?

Kiedy jest mu wygodnie: kiedy naprawia swój pierwszy błąd -> jest gotowy .

W społeczności open source każdy, kto chciał dołączyć do projektu, najpierw zajmuje się drobnymi problemami. Jeśli on lub ona poradzą sobie bardzo dobrze z problemem, ważniejsze zadanie zostanie mu przypisane. W ten sposób staną się głównym deweloperem projektu.

Ten starszy programista ma osiem lat doświadczenia w .NET, więc możesz przypisać mu kilka prostych błędów do naprawienia. Jeśli łatwo mu sobie z nimi poradzić, możesz przypisać mu złożone problemy, które pomogą mu zapoznać się z całą aplikacją. Potem mógł zacząć pisać nowe funkcje i analizować dziwne problemy. Po prostu zrób to, nie ma czasu na konfigurację!

8 lat doświadczenia. Po prostu go wrzucę. Powinien umieć pływać. Jak zauważyli inni, zacznij od małych łatwych zadań. Pozwoli mu on przeszukiwać proces sprawdzania / wyewidencjonowywania kodu oraz wszelkie inne procesy programistyczne, które masz.

Wielokrotnie zmieniałem pracę i byłem ich współtwórcą w ciągu pierwszego tygodnia. Najtrudniejsze zajęło mi tydzień, aby skompilować kod (przynajmniej 100 000 + linii kodu). Pełna wersja trwała 8 godzin dla tego projektu.

W pierwszym tygodniu przepracowałem około 80 godzin (projekt był poważnie opóźniony).

W przypadku tak małej aplikacji i doświadczonego programisty uważam, że jeden dzień wystarczy na podstawowe błędy. Zaangażowane błędy lub drobne funkcje w ciągu tygodnia (gdy już będą jasne na temat problemowej domeny i architektury).

Odpowiedź brzmi: to zależy. Jeśli chcesz, aby naprawił jeden błąd na czymś lub zmienił kolor elementu GUI, to około 5 minut (tutaj trzymamy nasz kod), jeśli chcesz całkowite przeprojektowanie całej architektury aplikacji, która będzie wymagają trochę dłużej.

To naprawdę zależy od zadania, które ma wykonać.