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

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

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

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

Для некоторой подоплеки, я уже был в похожих ситуациях “слишком хорош в кодировке для моей работы” раньше, хотя никогда в той степени, которую вы описываете. Я мог бы вылечить рак с помощью шаблонного метапрограммирования на С++, но многие из тех, с кем я работаю, едва знакомы с основами Объектно-ориентированного дизайна. Я написал код, который злоупотреблял SFINAE и столкнулся с точной формулировкой спецификаций C++, когда многие проекты, над которыми я работал, все еще использовали старые и багги-версии gcc. Мой подход заключался в том, чтобы просто показать им, насколько удивительны эти инструменты, и все проблемы, которые они могли решить. Мне нравилось объяснять людям маленькие советы по программированию, и им это очень нравилось.

Звучит знакомо?

“Да, но надо иметь хороший уровень, чтобы понять [код Мика], потому что компоненты разумно развязаны”.

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

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

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

У нас есть фраза “поставить тележку перед лошадью”. Один из многих смыслов, связанных с этой фразой, заключается в том, чтобы ставить содержание, о котором вы заботитесь больше всего (умение использовать свои продвинутые техники), над силами, которые должны его тянуть вперед (понимание этих техник вашим сослуживцем). Вы написали код в этом продвинутом стиле, а затем призвали других разработчиков “догнать” этот стиль. Это может быть эффективно, но если с вами что-нибудь случится до того, как они “догонят”, компания внезапно окажется в опасности, потому что никто не сможет поддерживать код.

Как мне избежать этого в будущем?

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

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

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

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

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

Всегда есть причины.

Предыдущий работодатель делал это с моей коллегой. Его уровень мастерства был намного выше нашего. Так что его отпустили.

Почему это имеет смысл?

1. Он был единственным, кто мог поддерживать свой код

2. Он не сотрудничал с

3. Он не следовал стандартам магазина

4. В то время как он поставлял больше, чем нужно, это было нехорошо

5. Простые решения были нужны вместо сложных.

Так часто говорят, что это почти клише, но вы должны быть “хорошей подгонкой” для команды.

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

Все эти мягкие навыки важны, и not имея их вызовет неприятности для вас.

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

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

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

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

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

Гораздо более вероятно, что это проблема с поведением, или босс просто не любит вас по причинам, которые он не может сказать вам, не создавая оснований для иска. Также возможно, что вы самый дорогой и они верят в ЭПЗ (т.е. каждый работник один и тот же).

Если вы действительно настолько хороши, вы можете сделать себя незаменимым в хорошем смысле этого слова:

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

Увольнение незаменимых людей на самом деле является разумной стратегией управления. Когда ваша компания полагается на одного человека, который продолжает выполнять свою работу, и никто другой в компании не имеет своих знаний и/или способностей, это создает огромную ответственность: что, если этот человек попадет под автобус и умрет (отсюда и термин “фактор автобуса”) или просто решит покинуть компанию для нового вызова? Теперь ваша компания застряла в terrible ситуации, потому что никто не может немедленно заменить незаменимого сотрудника, и у вас не было контроля над временем!

Чтобы предотвратить эту ситуацию, у компании есть два варианта. Либо они могут попытаться распространять знания и / или увеличить способности сотрудников незаменимого человека, или они могут потянуть пластырь в один ход, увольняя незаменимого человека в то время как their выбрать и восстановить с потерей сказал работник, когда они готовы к этому процессу.

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

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

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

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

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

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

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

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

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

Я также с интересом отмечаю этот говорящий комментарий от вашего менеджера:

“Но действительно ли это хорошо, как он притворяется?”

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

Людей не часто увольняют за то, что они незаменимы почему людей увольняют ); Это нелепое утверждение. Статья, на которую вы ссылаетесь, ясно определяет, что “огонь” не обязательно означает отпустить их, а скорее сделать незаменимыми (переместить их, заставить не быть вовлеченными в конкретный проект и т.д…)

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

People DO увольняются, потому что они БУДУТ незаменимы и лучше своих сверстников, и поэтому отказываются вносить изменения, которые должны быть сделаны с человеком в зеркале, чтобы хорошо функционировать в команде. Если вы строите мост с кучей туземцев и вытаскиваете ноутбук, в то время как остальные завязывают веревку - вы можете быть умнее или более образованным, но вы стали вредным для команды, и проблема в ВАС.

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

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

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

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

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

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

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

Я читал о том, что с первого же дня на работе вы были destined за это лечение. Вы сказали, что вас наняли, потому что у вас есть навыки, которых нет ни у кого в организации (TypeScript, Node). И теперь, когда вы трудились над созданием элегантного, искусно сделанного, сложного решения all alone, никто не понимает, что вы сделали, и поэтому вы считаетесь ответственностью руководства.

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

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

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

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

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

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

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

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

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

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

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

Решил обновить свой комментарий к ответу:

Документируйте свой код очень хорошо.

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

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

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

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

Правильно ли это? Разве я не должен получить полную похвалу за свою работу? Должен ли я действительно танцевать вокруг чувств каждого? Не имеет значения. Это реальность. Если я не приспосабливаюсь к ней, то я идиот.

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

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

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

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

Для того, чтобы специально ответить на вопрос,

Как избежать этого в будущем?

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

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

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

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

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

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

• Найдите инженера, который лучше вас. Не улучшайте себя, чтобы быть самым умным парнем в комнате. Есть одна цитата (мой гуглинг разделен на Ольгиви/Форд/Соркин), перефразировка звучит так: “Ты не сможешь узнать больше, если окружишь себя плохим талантом”.

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

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

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

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

Как я могу избежать этого в будущем?

Не работайте ни с кем, если вы не уверены, что их стандарт кодирования совпадает с вашим. Что означает отказ от любой работы, если none из следующего применимо:

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

Как я могу избежать этого в настоящее время?

Это было покрыто другими ответами.

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

Нужно поощрять равноправное программирование, рецензирование кода. Посидеть с другим программистом и попробовать вместе писать 2-3 часа. Отбросьте концепции, которые может быть слишком сложно объяснить (например, новые расширенные возможности Java 8), и объясните те, которые проще (наследование).

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

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

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

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

Мы не можем зависеть от него в долгосрочной перспективе

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

• Вы можете либо успокоить руководство с:

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

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

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

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

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

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

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

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

R