Работа с Fanboys [закрыто]

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

Мысли, которые мне приходилось иметь дело с этим:

1. Смейтесь - "Хаха, да, может быть, язык Х немного проще, наверное, я мазохист!"
2. Пойдите с этим - я действительно предпочел бы избежать этого, поскольку я не могу позволить себе падение производительности, связанное с освоением нового языка.
3. Hide your language - станьте скрытным программистом и скрывайте мой монитор всякий раз, когда я пишу сценарий или автоматизирую что-то.

Что бы вы предложили для этой ситуации?

Мало что выпрыгивает из вопроса.

• Это действительно одноразовый сценарий? Если это так, странно, что это обсуждается.
• Вы уверены, что одноразовый скрипт останется как есть? Многие продакшн-ролики были одноразовыми сценариями.
• Собираетесь ли вы переписать скрипт, если он продвигается и нуждается в интеграции в систему?
• Является ли выбор языка чисто синтаксическим или это язык из другой сферы?

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

Мой взгляд на эту ситуацию таков:

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

Это потому, что никто не знает, как написать безопасное и быстрое программное обеспечение на неизвестном языке, и у него есть все, что нужно усвоить разработчикам. Глупый сценарий должен быть поддержан в течение 20 лет или переписан. За 20 лет в среднем магазине меняется не менее 50 разработчиков. Если каждый из них пишет несколько необычных сценариев на новом языке, вам нужно 50 языковых сред выполнения, 50 различных экспертных знаний в команде, и кодовая база содержит ошибочный код на 50 языках. И некоторые языки больше не поддерживаются в Windows или Linux. И нуждается в этом исправленном 10-летнем нестандартном сервере, без доступных запчастей, 24/7.

Кроме того, никто не хочет поддерживать мертвые языки, такие как VB, Silverlight, D и т. Д., Когда кодовая база, вероятно, изживет сам язык.

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

Ты там работаешь , а не играешь там. В конечном итоге это не в ваших руках.

Даже если он не твой босс, я бы рассмотрел все углы здесь. Тебе бы понравилось, если бы он знал Фортран и однажды ты унаследовал весь его код. Вы должны выучить новый язык с нуля на лету , это ужасно стресс. Теперь представьте его сторону, вы можете написать свои сценарии с использованием Cobol, а он может не знать Cobol.

Используйте то, что знает большинство вашей команды.

"2. Иди с этим"

Это единственный разумный ответ. У вас есть прекрасная возможность здесь.

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

• Я получил ценную информацию о программировании на каждом изученном языке. Даже наименее практичный язык ( кашель XSLT кашель ) имел свою привлекательность и был полон интересных возможностей для обучения (и оплачивал свои счета в течение нескольких лет). Постоянное обучение - одно из больших преимуществ программиста.

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

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

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

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

Удачи!

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

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

Примечания:

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

  Например, я вряд ли представлял бы контекст, в котором Java была бы «лучше», чем C #, или C #, «лучше», чем Java.

• Помните, что выбор языка очень часто субъективен и объясняется скорее предыдущим опытом разработчика, а не некоторыми основанными на фактах элементами.

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

Ответ 2) Иди с этим.

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

Это беспроигрышный. Наслаждайтесь!

Ответ: вы не имеете с этим дело. Спор с ними просто уводит аргументатора до его уровня (где он побеждает вас с опытом) и в конечном итоге неконструктивен, потому что он недалекий.

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

Проблема здесь в том, что фанат связывает язык со своей индивидуальностью, и любой негатив, связанный с этим языком, является личным. Не атаковать и не защищать. Просто не обращай внимания.

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

Даже вещи, которые, по моему мнению, ниже уровня обмена, мои товарищи по команде часто чувствуют по-другому. Например, у меня есть псевдоним rgrep в моем .profile. Это просто оператор поиска с параметром, поскольку у меня нет доступа к реальному rgrep на этом сервере. Товарищ по команде получил ветер и хотел его в вики. Да, заявление в одну строку. Очевидно, у нас не было споров о языке реализации - это должен был быть UNIX. Но это подчеркивает необходимость делать то, что другие члены команды могут понять.

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

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

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

Пассивно-агрессивные варианты 1,3 приводят к еще большему эмоциональному стрессу, поэтому дайте мне 2) взять его на подбородок.

Несколько общих советов на дороге: 4) Если вы не научились умнее слушать старшего, изучите язык / дизайн компилятора. Выберите язык и узнайте, какие мысли были на нем. Какой компромисс между функциями, производительностью и выразительной силой. Какие еще варианты есть. Одно это даст вам сверхчеловеческое программирование. Учите даже НБЛ , это будет огромно.

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

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