Solista .NET Programmer przenosi się do zespołu [zamknięty]

Od 8 lat jestem programistą .NET dla małego startupu. Złożyłem całkiem przyzwoite oprogramowanie i zawsze starałem się poprawić siebie i stosować się do najlepszych praktyk, w tym kontroli źródła (SVN / TFS). Bardzo ściśle współpracowałem z zespołem inżynierów innych dyscyplin, ale gdy chodziło o oprogramowanie, byłem jedynym programistą. Uwielbiam kunszt programowania i uwielbiam uczyć się nowych rzeczy, aby wyostrzyć moje narzędzia.

Za 2 tygodnie zacznę nową pracę w zespole 20 programistów .NET. Moje stanowisko będzie na średnim poziomie i będę pracował pod programistami z niewiarygodnie imponującym doświadczeniem. Ponownie, zespołowy aspekt rozwoju będzie dla mnie nowy, więc szukam ogólnych wskazówek dla „nowych facetów”, które pomogą mi być tak efektywnym i łatwym w stosowaniu, jak to możliwe od samego początku.

Wszystko się dzieje, w tym wskazówki na wysokim poziomie i drobne codzienne rzeczy związane z komunikacją.

Przeważnie zdrowy rozsądek, ale moja rada to:

Spędź tyle samo pierwszego tygodnia z ludźmi, a nie z technologią. Nie trać pierwszego dnia na dostosowywanie pulpitu lub czegokolwiek innego, co odizoluje cię od zespołu. Jak najszybciej poznaj jak najwięcej rówieśników.

Spróbuj szybko dowiedzieć się, kim są konie robocze i kim są tyłki. Unikaj oparzeń jak najwięcej, każda drużyna je ma i nie chcesz być klasyfikowany jako jeden.

Weź udział w wydarzeniach towarzyskich w ciągu pierwszych kilku tygodni, nawet jeśli tylko piwo po pracy lub lunchu.

Słuchaj i zapisuj rzeczy, poproś rówieśników, aby powtórzyli opisy procedur, aby je wszystkie.

Poświęć pierwsze 3-6 miesięcy na zapoznanie się, chyba że zostaniesz zapytany o konkretny problem, nie zalecaj zmian w procedurach / architekturze / itp. Będą działać inaczej niż ty, a niektóre elementy mogą być ubogie - ale będą ku temu powody i rzadko są one spowodowane zaniedbaniem lub ignorancją.

Wątpię, aby strona programistyczna faktycznie stanowiła problem.

• Uczyć się! Poznawanie nowych programistów to świetny sposób na naukę nowych sztuczek. Oglądanie ich nauczy Cię kilku sztuczek redaktora, a spojrzenie na ich kod da ci nowe pomysły.

• Nie przeszkadzaj swoim kolegom co pięć minut, ale jeśli naprawdę utkniesz, nie wahaj się poprosić o pomoc. Zbyt wielu programistów utknęło w programie na dwa dni, a pytanie sąsiada rozwiązałoby go w ciągu godziny.

• Wojny kodowe to wojny religijne. Składnia może się tam nieco różnić (czy dodajesz nawiasy do instrukcji linii?), Ale rzadko warto o to walczyć.

• Uspołecznić. Jeśli robią drinka co tydzień, dołącz do niego. Może to być tak proste, jak wspólne jedzenie .

Grając w Adwokata diabła, powiem, aby upewnić się, że członkowie drużyny są kompetentni. Nie ma nic gorszego niż praca w zespole, w którym nikt poza tobą nie robi niczego „poprawnego”, ponieważ zawsze masz przewagę liczebną nad ludźmi, którzy chcą robić coś źle.

Wspominasz o pracy z programistami o imponującym tle, co brzmi obiecująco. W takim przypadku zachęcam cię do nauczenia się tego, co możesz, ale nigdy nie zapominaj o tym, co już wiesz ze względu na „mentalność stada”. Jeśli wszyscy robią coś złego, a ty robisz to dobrze, nie narażaj się na szwank.

Oprócz Jonno powiedziałbym:

Przygotuj się na zmiany. Każdy zespół działa inaczej. Dobre zespoły SW mają zasady kodowania. Przygotuj się na ich przyjęcie, nawet jeśli początkowo wydają się dziwne.

Przygotuj się na znacznie więcej komunikacji. Kiedy pracujesz na własną rękę, masz w głowie wiele szczegółowych informacji. Gdy tylko zaczniesz pracować w zespole, te dane (przynajmniej niektóre z nich) muszą zostać udostępnione i przekazane, a do tego potrzeba czasu.

Słuchaj więcej niż mówisz.

Zadawaj więcej pytań niż próbujesz na nie odpowiedzieć (chyba że pytania są skierowane do Ciebie). „Stare liczniki” w zespole będą wiedzieć, ile postępów uczysz się w nauce kodu dzięki zadawanym pytaniom. Prawdopodobnie mają w pamięci listę pytań, których oczekują.

Napisz swój kod, aby pasował do panującego stylu. Dotyczy to miejsca, w którym umieszczasz spacje, nawiasy klamrowe, wielkie litery, długość nazw zmiennych, średni rozmiar metod, gęstość komentarzy i wszystko inne, co nie powinno mieć znaczenia. Jeśli masz naprawdę dobry powód, aby robić coś inaczej, zapytaj jednego z dawnych czasów, dlaczego zespół ma dany styl. Możesz dowiedzieć się kilku interesujących rzeczy na temat historii zespołu i osobowości. Co prowadzi mnie do następnego punktu.

Naucz się wiedzy o zespole. Najprawdopodobniej nigdzie nie ma spisanej wiedzy, ale jest powszechnie znana w zespole. Wiedza zespołu obejmuje historię tego, jak projekt osiągnął obecny stan, błędy popełnione w przeszłości, sukcesy w przeszłości, wnioski wyciągnięte po drodze. Mówi się o tym w krótkich stwierdzeniach, jak: „znów brzmi jak błąd Frobnitza”. Kiedy widzisz / słyszysz członków zespołu, zgadza się z tajemniczym komentarzem, który ktoś robi, prawdopodobnie dotyczy to wiedzy zespołowej. Zapytaj kogoś.

Nie krytykuj kodu, dopóki nie poznasz osobowości i historii. Nie wiesz, kogo możesz obrażać.

Zadawaj pytania i słuchaj odpowiedzi. Pomyśl o odpowiedziach na poprzednie pytania, zanim zadasz następne, abyś mógł spodziewać się odpowiedzi.

Staraj się wykonywać możliwie najlepszą pracę. Przyzwyczaj się do zadawania sobie pytań, co ktoś w zespole pomyśli o twoim kodzie, jeśli będzie musiał go zmienić w przyszłym miesiącu.

Jeśli zauważysz problem, który należy rozwiązać, postaraj się przygotować rozsądne rozwiązanie, zanim wyrazisz zaniepokojenie problemem. Przejmij odpowiedzialność za wdrożenie rozwiązania, gdy zauważysz problem.