Solo .NET-програміст переходить до команди [закрито]

Останні 8 років я був сольним програмістом .NET для невеликого стартапу. Я зібрав досить пристойне програмне забезпечення, і я завжди прагнув покращити себе та відповідати кращим практикам, включаючи управління джерелами (SVN / TFS). Я дуже тісно співпрацював з командою інженерів інших дисциплін, але коли це дійшло до програмного забезпечення, я був єдиним програмуванням. Я люблю ремесло програмування і люблю вивчати нові речі, щоб заточувати свої інструменти.

Через 2 тижні я розпочну нову роботу в команді з 20 розробників .NET. Моя позиція буде середнього рівня, і я працюватиму над деякими програмістами з неймовірно вражаючим фоном. Знову ж таки, командний аспект розвитку буде для мене новим, тому я шукаю кілька загальних порад "нового хлопця", які допоможуть мені бути максимально ефективним та легким уживатися з можливим початком роботи.

Що завгодно, включаючи поради високого рівня та невеликі щоденні речі щодо спілкування.

Здебільшого здоровий глузд, але моя порада буде:

Проведіть стільки ж першого тижня з людьми, а не техніками. Не витрачайте перший день, налаштовуючи робочий стіл або щось інше, що ізолює вас від команди. Познайомтеся якомога швидше з однолітками.

Спробуйте розібратися, хто такі робочі коні, а хто також і жуйки. Уникайте нерозумних якомога більше, кожна команда має їх, і ви не хочете вважати їх одним.

Відвідайте будь-які соціальні події в перші кілька тижнів, навіть якщо тільки пиво після роботи чи обіду.

Слухайте і записуйте речі, попросіть однолітків повторити описи процедур, які будуть їх помацати.

Проведіть перші 3-6 місяців, ознайомившись, якщо спеціально не запитаєте певну проблему, не рекомендуйте змін до процедур / архітектури / тощо. Вони будуть працювати з вами по-іншому, і деякі елементи можуть бути поганими - але для цього будуть причини, і вони рідко бувають через халатність чи незнання.

Я сумніваюся, що проблема програмування насправді буде проблемою.

• Вчіться! Зустріч з новими програмістами - це прекрасний спосіб дізнатися нові хитрощі. Переглядаючи їх тип, ви навчитеся декільком фокусам редактора, а перегляд їх коду дасть вам нові ідеї.

• Не турбуйте своїх колег кожні п’ять хвилин, але якщо ви дійсно застрягли, не соромтеся просити допомоги. Занадто багато програмістів застрягли в програмі на два дні, коли запит вашого сусіда вирішив би це за годину.

• Кодові війни - це релігійні війни. Синтаксис може дещо відрізнятися від цього (чи додаєте ви дужки до конвеєрних рядків викликів?), Але з ними рідко варто боротися.

• Спілкуватися. Якщо вони роблять напій щотижня, обов'язково приєднуйтесь до нього. Це може бути так само просто, як їсти разом .

Граючи в захисника диявола, і я скажу, що переконайтеся, що ваші товариші по команді грамотні. Нічого не гірше, ніж працювати в команді, де ніхто, крім вас, нічого не робить «правильним» способом, тому що ви завжди перелічені в людях, які хочуть робити щось не так.

Ви згадуєте, що працюєте в розробниках з вражаючим досвідом, так що це звучить багатообіцяюче, і в цьому випадку я закликаю вас дізнатися, що ви можете, але ніколи не забувайте те, що ви вже знаєте заради «ментального стада». Якщо всі інші роблять щось не так, і ви робите це правильно, не робіть себе на компроміс.

На додаток до Jonno, я б сказав:

Будьте готові до змін. Кожна команда працює по-різному. Гарні команди SW мають правила кодування. Будьте готові прийняти їх, навіть якщо спочатку вони здаються дивними.

Будьте готові до набагато більше спілкування. Коли ви працюєте самостійно, у вас в голові багато детальної інформації. Як тільки ви працюєте в команді, ці деталі (принаймні деякі з них) повинні бути обмінені та передані, і для цього потрібно час.

Слухай більше, ніж ти говориш.

Задавайте більше запитань, ніж ви намагаєтесь відповісти (якщо тільки питання не спрямовані на вас). "Старі таймери" в команді дізнаються, який прогрес ви досягаєте у вивченні коду за допомогою заданих вами питань. Вони, ймовірно, мають ментальний список питань, які їх очікують.

Напишіть свій код, щоб він відповідав стилю, що склався. Це стосується місця, де ви ставите пробіли, фігурні дужки, великі літери, довжину назв змінних, середній розмір методів, щільність коментарів та все інше, що не має значення. Якщо у вас є справді вагомі причини робити щось інакше, то запитайте когось із старожилів, чому команда має заданий стиль. Ви можете дізнатись щось цікаве про історію та особистості команди. Що підводить мене до наступного моменту.

Вивчіть команду. Швидше за все, ніхто з кращих не записується ніде, але це загальновідомі відомості в команді. Команда включає історію того, як проект дійшов до його сучасного стану, помилок, зроблених у минулому, успіхів, зроблених у минулому, уроків, отриманих на цьому шляху. Це згадується в коротких статтях, як "звучить знову як помилка frobnitz". Коли ви бачите / чуєте, що члени команди погоджуються з криптовим коментарем, який хтось робить, можливо, тут залучена краща команда. Запитайте когось.

Не критикуйте код, доки не дізнаєтесь особи та історію. Ви не знаєте, кого ви можете образити.

Задавайте питання і слухайте відповіді. Подумайте над відповідями на попередні запитання, перш ніж задавати наступне, щоб спробувати передбачити відповідь.

Прагніть зробити найкращу роботу, яку, можливо, можете. Звикайте запитувати себе, що хтось із команди подумає про ваш код, якщо їм доведеться внести зміни до нього наступного місяця.

Якщо ви бачите проблему, яку потрібно вирішити, зробіть все можливе, щоб мати готове розумне рішення, перш ніж висловити занепокоєння щодо проблеми. Візьміть на себе відповідальність за реалізацію рішення, коли ви вкажете на проблему.