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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Он был единственным, кто мог поддерживать свой код
2. Он не был соавтором
3. Он не следовал стандартам магазина
4. Хотя он доставлял больше, чем нужно, это было нехорошо.
5. Требовались простые решения, а не сложные.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Также с интересом отмечаю красноречивый комментарий вашего менеджера:

"Но так ли он хорош, как он притворяется?"

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

Людей не часто увольняют за то, что они незаменимы ( почему людей увольняют ); Это нелепое утверждение. В статье, на которую вы ссылаетесь, четко указано, что «увольнение» не обязательно означает отпустить их, а скорее сделать их незаменимыми (путем их перемещения, принуждения их к тому, чтобы они не участвовали в конкретном проекте и т. д.).

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

Людей ДЕЙСТВИТЕЛЬНО увольняют, потому что они ДУМАЮТ, что они незаменимы и лучше своих сверстников, и поэтому отказываются вносить изменения, которые необходимо внести в человека в зеркале, чтобы он хорошо функционировал в команде. ( уволен за плохое отношение )

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

Если вы действительно так велики, как вы себя представляете, вы были бы достаточно умны, чтобы скорректировать свои собственные действия, чтобы сделать КОМАНДУ максимально продуктивной, а не догматически продвигать свою собственную повестку дня (что вы, вероятно, и делаете). Если бы вы это делали, у вас, вероятно, была бы работа в течение очень долгого времени.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы решить вопрос конкретно,

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

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

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

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

• Станьте волонтером на местном Meetup и Hack-athons. Это может заставить вас переработать свой код, потому что цель состоит в том, чтобы сотрудничать, а не строить отказоустойчивую энергосистему, верно?

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

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

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

TL;DR: Найдите более подходящее рабочее место и честно говорите о навыках, которые вам еще предстоит освоить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете либо успокоить управление с помощью:

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

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

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

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

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

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

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

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

Прочтите «Вагон», «Блэкберд» и «Сааб» . Это должно резонировать с вами.

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

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