Соло .NET программист переходит в команду [закрыто]

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

Через 2 недели я начну новую работу в команде из 20 разработчиков .NET. Моя должность будет на среднем уровне, и я буду работать под руководством некоторых программистов с невероятно впечатляющим опытом. Опять же, командный аспект развития будет для меня новым, поэтому я ищу несколько общих советов для «новых парней», которые помогут мне быть максимально эффективными и легкими в освоении с самого начала.

Все идет, в том числе советы высокого уровня, и небольшие повседневные вещи о коммуникации.

В основном здравый смысл, но мой совет будет:

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

Постарайтесь быстро выяснить, кто такие рабочие лошади и кто такие задницы. Избегайте бомжей как можно больше, у каждой команды есть они, и вы не хотите быть классифицированными как один.

Посетите любые общественные мероприятия в первые несколько недель, даже если только пиво после работы или обеда.

Слушайте и записывайте вещи, попросите сверстников повторить описания процедур, которые будут их раздражать.

Потратьте первые 3-6 месяцев на знакомство, если только у вас конкретно не спросили о конкретной проблеме, не рекомендуйте вносить изменения в процедуры / архитектуру / и т.д. Они будут работать по-другому для вас, и некоторые элементы могут быть плохими - но будут причины для этого, и они редко происходят из-за халатности или невежества.

Я сомневаюсь, что сторона программирования на самом деле будет проблемой.

• Учить! Знакомство с новыми программистами - отличный способ научиться новым трюкам. Наблюдение за их типом научит вас нескольким трюкам редактора, а просмотр их кода даст вам новые идеи.

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

• Кодовые войны - это религиозные войны. Синтаксис может несколько отличаться (вы добавляете квадратные скобки в операторы с единственной строкой?), Но с этим редко приходится бороться.

• Общаться. Если они делают напиток каждую неделю, обязательно присоединяйтесь к нему. Это может быть так же просто, как есть вместе .

Играю в Devil's Advocate, и я собираюсь сказать, что ваши товарищи по команде компетентны. Нет ничего хуже, чем работать в команде, где никто, кроме вас, не делает ничего «правильного», потому что вас всегда численно превосходят люди, которые хотят поступать неправильно.

Вы упомянули о работе с разработчиками с впечатляющим опытом, так что это звучит многообещающе, и в этом случае я призываю вас узнать, что вы можете, но никогда не забывайте то, что вы уже знаете, ради «стадного мышления». Если все остальные делают что-то не так, а вы делаете это правильно, не идите на компромисс.

В дополнение к Йонно я бы сказал:

Будьте готовы к изменениям. Каждая команда работает по-разному. У хороших команд SW есть правила кодирования. Будьте готовы принять их, даже если изначально они кажутся странными.

Будьте готовы к гораздо большему общению. Когда вы работаете самостоятельно, у вас в голове много подробной информации. Как только вы работаете в команде, эти детали (по крайней мере, некоторые из них) должны быть переданы и переданы, и для этого требуется время.

Слушай больше, чем говоришь.

Задайте больше вопросов, чем пытаетесь ответить (если вопросы не направлены на вас). «Старые таймеры» в команде будут знать, насколько вы продвинулись в изучении кода по заданным вами вопросам. У них, вероятно, есть мысленный список вопросов, которые они ожидают.

Напишите свой код в соответствии с преобладающим стилем. Это относится к тому, где вы ставите пробелы, фигурные скобки, заглавные буквы, длину имен переменных, средний размер методов, плотность комментариев и все остальное, что не должно иметь значения. Если у вас есть действительно веская причина, чтобы действовать по-другому, спросите одного из старожилов, почему у команды такой стиль. Вы можете узнать некоторые интересные вещи об истории команды и личностях. Что подводит меня к следующему пункту.

Изучите знания команды. Скорее всего, ни один из знаний нигде не записан, но это общеизвестно в команде. История команды включает в себя историю того, как проект попал в его текущее состояние, ошибки, сделанные в прошлом, успехи, сделанные в прошлом, уроки, полученные на этом пути. В кратких комментариях это упоминается как «снова звучит как ошибка Фробница». Когда вы видите / слышите, что члены команды соглашаются с загадочным комментарием, который кто-то делает, вероятно, в этом задействованы знания команды. Спроси кого-нибудь.

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

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

Стремитесь сделать самую лучшую работу, какую только возможно. Привыкайте спрашивать себя, что еще кто-то в команде будет думать о вашем коде, если он должен будет изменить его в следующем месяце.

Если вы видите проблему, которую необходимо решить, приложите все усилия, чтобы найти разумное решение, готовое предложить, прежде чем высказывать озабоченность по поводу проблемы. Возьмите на себя ответственность за реализацию решения, когда вы указываете на проблему.