Является ли заказ компании переключением на определенную IDE красным флагом? [закрыто]

Я недавно присоединился к быстро растущему стартапу. За последние 3 месяца команда разработчиков выросла с 4 до 12. До сих пор они были очень невежливы в отношении того, что разработчики использовали для своей работы. Фактически, одна из вещей, которые я изначально нашел привлекательными в компании, это то, что большинство программистов использовали Linux или любую ОС, которая, по их мнению, лучше всего подходила для их усилий.

Теперь пришли приказы без обсуждения, что каждый должен перейти на Eclipse. Прекрасный редактор. Я предпочитаю SublimeText2, но это только мой личный вкус.

Просто чтобы прояснить: мы команда JS, использующая Backbone, а Eclipse просто не очень хорошо понимает код Backbone. Это означает, что те в команде, которые используют / good / IDE (PHP Storm), должны вернуться к выполнению многих видов поиска: поиск-о-о-ждать-где-я-три-назад-назад вместо того, чтобы просто нажимать Ctrl + и использовать назад / вперед - возможно, снижение производительности, скажем, на 15% и удовольствия на 50% ...

Это красный флаг? Кажется капризным и неоправданно контролирующим сообщать разработчикам (не MS), какую IDE или наборы инструментов использовать, если они уже установлены и продуктивны.

«Теперь пришли приказы без обсуждения , что каждый должен перейти на Eclipse».

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

Это звучит как чрезмерное управление заостренными боссами. Имеет ли лицо / команда, принимающее решение, соответствующее понимание этого решения?

Учитывая, что лица, принимающие решения, достаточно квалифицированы для такого решения, отсутствие мнения команды разработчиков имеет как минимум два недостатка:

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

• Руководство, однако опытное, не работает на 100% с разработкой этого конкретного кода. Предполагать, что люди, у которых нет интересного понимания, было бы наивно. Конечно, это может быть так, что менеджеры думали обо всем, что придумывали разработчики, но единственный способ узнать это - спросить.

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

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

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

Но если вы сравните это с попыткой быть наиболее эффективным, то это не стоит того

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

Это не красный флаг сам по себе.

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

Кроме того, это не практично или необходимо консультироваться со всеми для каждого решения . Степень, в которой это необходимо сделать, зависит от культуры организации и важности / сложности решения. Как правило, вы выбираете один из этих менее сложных для консультаций вариантов:

1. Примите решение самостоятельно, если у вас достаточно знаний о плюсах и минусах, и это не является достаточно важным решением, требующим широких консультаций.
2. Проконсультируйтесь с несколькими ключевыми лицами (которые, вероятно, будут старшими разработчиками, наиболее квалифицированными для принятия решения).
3. Поднимите тот факт, что вы принимаете решение для всех, кто может быть затронут (электронная почта, встреча в мэрии, встречи команды). Скажите, что вы считаете правильным решением, но вы готовы изменить это, если появятся новые доказательства обратного. Пригласите людей выступить индивидуально, если у них есть важные мнения
4. Пригласите людей сформировать подгруппу, чтобы рассмотреть варианты и рекомендовать решение. Хороший вариант, если это действительно близкий звонок, вы не знаете ответа и хотите, чтобы вовлеченные лица были вовлечены в решение.

Для чего-то, как разработчик инструментов (который является потенциально спорный вопрос), я бы, вероятно, сделать 2 следует либо 3 или 4 то есть определенно был бы некоторые люди, я бы не стал говорить лично по этому вопросу, но с другой стороны, большинство из ключевых людей получит шанс внести свой вклад в принятие решений.

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

• Хороший менеджмент прислушается к вашим аргументам, искренне благодарю вас за отзывы и пересмотрю их позицию в случае, если вы поднимете новые идеи . Они могут по-прежнему не соглашаться с вами и могут придерживаться своего решения, но они будут благодарны вам за то, что вы подняли его с ними, и вы любезно скажете, почему они придерживаются своего решения. Они могут даже изменить то, как они будут принимать такие решения в будущем, и, если вы сделали хорошие замечания, можете включить вас в свой список «умных людей, которых нужно спрашивать».
• Плохое управление будет защищаться, скажем, что «решение принято» и другие подобные тактики, чтобы избежать столкновения с тем фактом, что они, возможно, приняли неправильное решение. Они могут видеть вас как "нарушителя спокойствия". Компания страдает, как и ваша вера в управление. Это настоящий красный флаг! Убирайся, пока можешь!

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

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

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

В среде IDE против редактора ... почти для всех языков я настоятельно предпочитаю IDE (IntelliJ), потому что он может сделать для вас гораздо больше, чем редактор. Есть некоторые вещи, для которых я возвращаюсь к ST2 или Emacs, но для повседневного кодирования, несмотря на то, насколько мне нравятся оба ST2 / Emacs, IDE почти всегда побеждает.

У каждой команды, в которой я когда-либо был, было множество IDE и редакторов: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - это никогда не было проблемой. Никогда.

Для меня это говорит о недопонимании на высоком уровне организации относительно того, что действительно имеет значение. Что важно, так это позволить хорошим программистам делать то, что им нужно, и использовать инструменты, которые делают их максимально комфортными. Однородность IDE имеет очень мало общего с реальным общением, которое происходит по существенным вопросам архитектуры объектов, модульного тестирования, алгоритмов и т. Д.

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

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

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

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

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

Быть вынужденным стандартизировать IDE звучит как ужасная идея.

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

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

Это массивный красный флаг. У каждой компании есть несколько таких глупых идей, но если другие красные флаги продолжают появляться, просто уходите.

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

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

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

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

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

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

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

Конечно, это плохая идея. Это неизбежно, что команда станет менее продуктивной, поскольку они должны научиться использовать новые инструменты. И даже тогда они не будут столь же эффективны , как с инструментами , они уже ГРОК .

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

Но, конечно, есть и профессионалы, чтобы целая команда использовала одни и те же инструменты. Обмен конфигами, скриптами, плагинами и всем прочим. Что было бы невозможно с разнообразием наборов инструментов.

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

Вы можете «использовать» Eclipse, все еще печатая в SublimeText2.

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

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

Если вы думаете об этом с точки зрения руководства, причина, по которой они могут это делать, заключается в соблюдении законодательства. Компания несет ответственность за обеспечение того, чтобы каждый используемый инструмент использовался на законных основаниях, а также не будет обременять разрабатываемый продукт. (Некоторые редакторы бесплатны для личного использования, но не бесплатны для каких-либо других целей и т. Д.) Аудит каждого инструмента, который может захотеть использовать каждый разработчик, может быть дорогостоящим. Я видел, что в проектах с жесткими временными рамками руководство будет осторожно относиться к тому, какие инструменты / библиотеки / и т. Д. Используются, чтобы минимизировать изменения в дальнейшем в проекте, которые направлены юридическим лицам.

В проектах с более высоким уровнем безопасности также возникает вопрос о том, где IDE хранят временные файлы и какая информация хранится между сеансами.

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

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

И последнее: внедрение процесса на этом уровне может указывать на то, что компания намерена расширить команду разработчиков и хочет иметь определенную структуру, чтобы новые товарищи по команде могли быстрее работать. Если вы думаете, что Rails (или Django) - это «самоуверенный» фреймворк, вы поймете, что наличие структуры помогает легче понимать новые приложения.

Красный флаг - это не столько то, что один IDE / редактор навязывается каждому разработчику, но что это решение, и особенно решение о том, какой IDE / редактор должен был использоваться, принималось не всеми разработчиками, и, возможно, никто из их!?!

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

Получить 12 голосов разработчиков было бы легко. Конечно, было достаточно времени, чтобы сделать это! Вывод был бы болезненным для некоторых так или иначе, и это, возможно, даже в конечном итоге быть Eclipse, в конце концов, но маркировка требование как «красный флаг» в этом случае будет гораздо более спорным.