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

14

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

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

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

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

Даниэль Гратцер
источник
14
Разве не проще всего его игнорировать и, возможно, попросить хотя бы небольшого профессионализма при возникновении ситуации?
zxcdw
25
Абсолютно уверены, что вы сами не фанат, поскольку настаиваете на своем выборе ?
Док Браун
11
@DocBrown Я не беспристрастный, но я уверен, что Perl (мой выбор) лучше подходит для разбора текстовых файлов, чем VB (его выбор)
Daniel Gratzer
4
Вопрос в том, действительно ли этот парень фанат, он же знает только одну вещь и плохо обосновывает, почему он считает это «лучшим», или он действительно очень хорош и выбирает что-то в большинстве случаев, потому что это действительно лучший путь? Я спрашиваю об этом совершенно без сарказма, так как сам обозначил несколько человек в качестве фанатов, прежде чем понял, что они просто знают намного больше меня.
Shivan Dragon
8
@jozefg Я не хочу оставлять модератором неконструктивную и, возможно, самоуверенную тему, но разве переход от VBSD к Ruby - гигантский шаг назад?
maple_shaft

Ответы:

14

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

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

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

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

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

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

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

кодировщик
источник
9
+1 за то, что поставил под сомнение одноразовую природу сценариев. Бывший коллега многозначительно отметил, что большинство временных решений являются постоянными.
Йорис Тиммерманс
12
-1 за категорическое отклонение всех новых языков. Это настолько неправильно, что это подавляет остальную часть совета, который хорош. Это именно тот способ, которым вы получаете гигантскую унаследованную базу кода в C, в то время как ваши конкуренты бегают вокруг вас с помощью Ruby (или Clojure или чего-то еще), потому что они могут выразить логику того, что им нужно сделать гораздо быстрее, чем вы. Чтобы преуспеть превосходно, а не ласково, вам нужно выбрать победителей заранее .
Рекс Керр
2
-1 для обозначения VB & Silverlight как «непопулярного». Вы будете поддерживать ваши непопулярные языки еще долгое время ... tiobe.com/index.php/content/paperinfo/tpci/index.html
deworde
3
D мертв? Для меня это новость, тем более что на прошлой неделе была выпущена новая версия! -1 dlang.org/changelog.html
Гэри Уиллоуби
4
упоминание языков явно: плохая идея.
Надир Сампаоли
16

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

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


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

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

sergserg
источник
6
«Ты работаешь там, а не играешь там». +1
фанкибро
1
Но первый шаг к внесению изменений, которые вы хотите внести, - это доказать их эффективность в безопасной среде.
deworde
9

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

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

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

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

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

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

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

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

Удачи!

GlenPeterson
источник
4
а кто на самом деле хочет учить VB?
Майкл Браун
Фанат любит VB? Я уверен, что вы можете зарабатывать хорошие деньги с VB, но я бегал, крича от этого в моей карьере. Мне все еще не нравятся варианты 1 или 3. Я бы добавил вариант 4: обновите свое резюме и найдите себе новую работу. Также вариант 5: обновить резюме Fanboy и найти HIM новую работу! Если это не вариант, то мой прежний совет по варианту 2 все равно будет применяться.
ГленПетерсон
7

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

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

Примечания:

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

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

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

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

Арсений Мурзенко
источник
1
Linq хотел бы сказать пару слов. ;)
sergserg
@MainMa, не говорите, что C # вряд ли может быть лучше, чем Java. Он работает намного быстрее и имеет много встроенных функций)))
superM
14
Это фанаты все время вниз!
Фрум
2
@superM: «быстрее» настолько субъективно, что я даже не отвечу на этот аргумент. Что касается встроенной функциональности, встроенная функциональность Java выглядит довольно большой для меня.
Арсений Мурзенко
3
«[Выбор языка] объясняется в большей степени предыдущим опытом разработчика», а также текущими профессиональными целями разработчика, т. Е. «Мне нравится повышенное мастерство в X (на доллар компании)».
фанкибро
3

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

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

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

Доминик Кронин
источник
3
Это действительно, даже если новый язык VB?
Надир Сампаоли
Изучение Visual Basic научило меня многим полезным вещам, которых я бы не усвоил, если бы в то время придерживался выбранных языков (C и PL1, если я правильно помню)
Доминик Кронин,
2

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

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

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

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

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

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

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

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

Жанна Боярская
источник
1

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

Питер К.
источник
1
Вы правы (в принципе;).
Яннис
3
Быть пассивно агрессивным?
Гэри Уиллоуби
Есть разница между пассивно-агрессивным и использованием методов для борьбы с напористыми людьми. Конечно, если напористость спускается в догму, то это может привести к пассивно-агрессивному поведению. В этом случае ситуация в любом случае ужасная ... поэтому лучший вариант - уйти. ;-)
Питер К.
0

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

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

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

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

Яно
источник