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

12

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ą.

219558af-62fa-411d-b24c-d08dab
źródło

Odpowiedzi:

19

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.

Jonno
źródło
1
Piwo w porze lunchu? Musisz być Europejczykiem: P Większość ludzi pomyślałaby, że jestem alkoholikiem, gdybym to zrobił tutaj, na wybrzeżu Pacyfiku w USA.
Edward Strange
@Crazy Eddie: Jestem Kanadyjczykiem, a moja firma płaci za piwo i każe je przynosić do biura w każdy piątek ...
Steven Evers
@SnOrfus - Doświadczyłem obu skrajności w Kanadzie. Myślę, że „dozwolone piwo” spada.
Scott Whitlock,
„niektóre elementy mogą być ubogie - ale będą ku temu powody i rzadko są one spowodowane zaniedbaniem lub ignorancją”. Miałeś mnie do tego oświadczenia. Z mojego doświadczenia zawodowego wynika, że ​​niektóre rzeczy źle wykonywane z powodu ignorancji są dość powszechne. Jeśli nie zostało to zrobione z niewiedzy, to zostało zrobione z ograniczeń czasowych.
wałek klonowy
@Snorfus - jeśli znalazłeś firmę w USA, która to zrobiła, prawdopodobnie byłaby to jedyna: PI sądzi, że prezesi i inne wysokie i potężne typy mogą pić podczas lunchu, ale większość miejsc ma to w podręczniku, „Nie wnoszenie alkoholu do pracy”, jeśli nie bardziej rygorystyczne. Chociaż nasze miejsce to ma i ci z nas, którzy warzą ten produkt, przynieśli próbki smaku do handlu; po prostu nie pijemy ich w pracy.
Edward Strange
8
  • 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 .

Carra
źródło
3

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.

Wayne Molina
źródło
Szczerze mówiąc, nie chciał, aby dodać cudzysłowy wokół niego, bo mocno wierzę, że jest prawo i niewłaściwy sposób oprogramowanie do zapisu, ale nie miałem ochoty hashuje tego starego argumentu :)
Wayne Molina
2

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.

wolfgangsz
źródło
2

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ć.

jimreed
źródło
1

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.

Rick Liddle
źródło