Как стать хорошим командным игроком? [закрыто]

Я программирую (одержимо) с 12 лет. Я достаточно хорошо разбираюсь во всем спектре языков, от ассемблера до C ++, Javascript, Haskell, Lisp и Qi. Но все мои проекты были выполнены мной.

Я получил степень в области химического машиностроения, а не CS или компьютерного инжиниринга, но впервые этой осенью я буду работать над большим проектом по программированию с другими людьми, и я понятия не имею, как подготовиться. Я использую Windows всю свою жизнь, но этот проект будет очень Unix-у, поэтому я недавно купил Mac в надежде ознакомиться с окружающей средой.

Мне посчастливилось участвовать в хакатоне с некоторыми друзьями в прошлом году - как со специализацией в CS - так и достаточно увлекательно, мы победили. Но я понял, работая с ними, что их рабочий процесс сильно отличается от моего. Они использовали Git для контроля версий. Я никогда не использовал это в то время, но с тех пор я узнал все, что могу об этом. Они также использовали много фреймворков и библиотек. Я должен был узнать, что Rails было довольно быстро для хакатона (с другой стороны, они не знали, что такое лексическая область видимости или замыкания). Весь наш код работал хорошо, но они не поняли мой, а я не понял их.

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

И последнее, что мне требуется много времени, чтобы понять код других людей. Соглашения об именовании переменных (которые варьируются в зависимости от каждого нового языка) сложны (__mzkwpSomRidicAbbrev), и я считаю, что слабая связь трудна. Это не значит, что я не разбираюсь в нескольких вещах - я думаю, что я достаточно хорош для своей собственной работы, но когда я загружаю что-то вроде ядра Linux или исходного кода Chromium, чтобы посмотреть на это, я трачу много времени на попытки выяснить, как все эти странно названные каталоги и файлы соединяются. Изобретать колесо - это грех программирования, но я часто нахожу, что самому быстрее написать функциональность, чем часами разбирать какую-то библиотеку.

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

Вопрос: Какие шаги я могу предпринять, чтобы начать «интеграцию» со всеми остальными?

Благодарность!

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

Никто из нас не учился работать в группе или команде по книгам, и ему не давали какие-либо шаги для детей или «Руководство по работе в командах».

Мы просто учимся работать с группами, работая в группах.

Все, что вы слышали о профессиональных программистах, постепенно станет на свои места, когда вы будете работать в команде. Вы узнаете обо всех них один за другим, например, контроль версий, модульное тестирование и т. Д.

Для меня суть

Станьте частью команды.

Я собираюсь выбрать некоторые из ваших предложений и сделать пару общих замечаний:

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

...

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

...

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

Я думаю, что самая важная вещь, которую вам нужно изучить, это:

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

Причина проста: работая с другими людьми, вы должны тратить некоторое время на обмен информацией с этими людьми; тогда как при работе в одиночку обмен информацией происходит в вашей голове. Что естественно быстрее.

Другая важная вещь:

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

Имея в виду эти две идеи, все, что я цитировал выше, имеет смысл. Многие люди не «замыкают» замыкания. Тестирование и анализ кода должны гарантировать качество и снизить риск, когда код создается группой людей со смешанными способностями. Отслеживание ошибок происходит потому, что при создании достаточно больших систем ошибки неизбежны. И бесконечные библиотеки с их соглашениями состоят в том, что без соглашений просто слишком много кода, чтобы изучать или писать его заново каждый раз, когда вам это нужно.

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

Самый эффективный способ - стать частью команды.

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

Я бы порекомендовал вам принять участие в проекте с открытым исходным кодом, который очень активен и поддерживает частое общение по современным открытым каналам (трекер, список рассылки, вики и т. Д.). Открытое общение важно, потому что вы, вероятно, начнете с наблюдения за тем, как взаимодействуют другие люди, поэтому избегайте проектов, которые полагаются на электронную почту между основными разработчиками или неархивированный IRC.

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

Shameless вилка: вы очень приветствуем здесь !

Я не буду повторять то, о чем уже говорили другие "just do it", но добавлю еще одно замечание, о котором я не упомянул: хороший менеджер действительно поможет вам интегрироваться в команду.

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

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

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

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

Я согласен с ЭльЮсубовым в том, что вам нужно много терпения и дать себе и новым коллегам некоторую команду, чтобы научиться работать вместе, пока вы не станете командой. Если вы занимаетесь каким-то командным видом спорта, вы уже должны были это испытать.

Один последний комментарий о том, как много времени нужно тратить на понимание кода других людей. Работа в команде означает, что вы будете работать над чужим кодом, а другие разработчики будут работать над вашим кодом. Иногда код слишком сложен, чтобы переписать его с нуля. Типичное решение - попросить первоначального разработчика пересмотреть ваши изменения, чтобы у вас было больше уверенности в том, что вы ничего не нарушаете в их коде.

Для меня это был большой скачок в переходе от индивидуального программиста к командному программисту: вы работаете над кодом, который понимаете лишь частично, и вам нужно к нему привыкнуть. Это включает в себя гораздо больше общения с вашими коллегами, большое уважение (да, у них странные соглашения об именах для их переменных и что?) И взаимное доверие (даже если у них другой стиль кодирования, я знаю, что они предоставляют рабочий код) ,

Быть хорошим членом команды означает бесстрашно общаться, доверять своим колледжам и преодолевать препятствия в проекте как команде иdeliver project as a team.

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

Было бы полезно выделить некоторых персонажей хорошего члена команды .

а) Хороший член команды - это человек, который ориентирован на цель, а не на себя.

б) Качества: больше думать о картине, чем о самоудовлетворении. Это ключевой момент. Все остальные качества (такие как надежность, конструктивное общение) наследуются от этого

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

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

Вы находитесь в невыгодном положении из-за того, что у вас нет образования по созданию программного обеспечения. В этом образовании преподается несколько вещей (не только как программировать), что для выпускников CS и опытных разработчиков программного обеспечения будет второй натурой. Не то, чтобы это часто возникало на работе (хотя это было для меня когда-то), но NP-hard - это пример термина, который они могут понять, а вы - нет. Возможно, вам не хватает каких-либо знаний в области формальной теории вычислений, но это нормально, если вы готовы узнать об этом. Может быть, мастер в CS в вашем будущем? Похоже, что часть вашего кода может быть идиоматичной, в том смысле, что у вас есть стиль программирования, который кажется вам понятным, но не другим. Обратите внимание на обзоры кода и будьте готовы принять критику и учиться. Это займет работу, и вы можете расстроиться,

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