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ą.
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 .
źródło
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.
źródło
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.
źródło
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ć.
źródło
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.
źródło