Как сказать, что совет старшего разработчика плох? [закрыто]

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

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

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

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

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

1. У младшего нет всей информации, чтобы понять решение, как оно было принято. В некоторых случаях небольшое объяснение может помочь разработчику преодолеть проблему и справиться с неидеальной ситуацией.
2. У младшего есть ПЛОХАЯ информация. Не забывайте, что вы на самом деле младший. Это эквивалентно тому, чтобы быть подростком в программном плане. Я уверен, что у вас есть много прекрасных идей, но возможно, что вы не знаете всего. Я считаю, что самые стойкие младшие разработчики - это те, кто твердо уверены, что знают, что лучше для кода, компании, мира. Этим разработчикам лучше обрести смирение.
3. Решение сделать что-то определенным образом было принято над головой старшего. Старший все еще работает на кого-то еще в конце концов. На самом деле может быть лучший способ сделать что-то, более эффективный способ написать что-то или лучшее программное / аппаратное обеспечение, чтобы помочь выполнить работу. Бизнес все еще управляет решениями все же. Бизнес-менеджеры, директора, вице-президент и т. Д. Часто принимают решения, которые влияют на процесс разработки. Они находятся вне контроля старшего, и когда младшие жалуются на это, все, что они делают, это усиливают стресс старшего.
4. У старшего просто нет времени, чтобы принять это во внимание. Существуют крайние сроки, и иногда изменение шаблонов, практик и поведения в среднем потоке обходится дорого до этого срока. Так как его шея лежит на разделочной доске, зачастую важнее, чтобы продукт был выпущен функционально и вовремя, чем «отлично написано».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полностью ожидая отрицательных голосов / разногласий для крайне предвзятой точки зрения.

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

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

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

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

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

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

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

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

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

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

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

Это вполне может быть правдой. Есть сыпь разработчиков , которые были в промышленности в течение десятилетий , а не быть в состоянии программного обеспечения приводит - от разработки или наставничества точки зрения (есть разница). Опыт приходит от решения новых задач и отработки новых идей и обучения новым навыкам, но большинство программистов проводят свою жизнь в отделении корпоративного офиса, работая над приложением Payroll со своими верными инструментами Visual Basic и Java, никогда не видя гонок мира в их холодном сером кабинете.

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

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

Тем не менее, он просто просматривает только мой код, и большинство его комментариев связано с правилами кодирования

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

Что мне делать в такой ситуации?

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

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

Вот несколько предложений.

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

Если у вас есть лучший способ сделать это решить ту или иную проблему, просто сделай это .

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

Дело в точке

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

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

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

А пока прочитайте ответ Джоэла Эертона.

Я настоятельно рекомендую не пытаться «не реализовывать его по-своему».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Спросите другого старшего разработчика,
2. Проводите исследования самостоятельно.

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

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

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

Это могут быть стандарты кодирования, общая архитектура, язык или методология. Но это всегда что-то. Много раз просто заявляет очевидное: «Разве все не должно быть лучше задокументировано для наших конечных пользователей?»

Мой тебе совет: не будь тем парнем .

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

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

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

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

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

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

(Немного отредактировано для действий.)

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

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

Несколько мыслей:

1 / это работает? Его путь работает или нет? Есть ли какая-то объективная причина, по которой его путь уступает?

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

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

2 / Звездные программисты говорят ... Почему наплевать? Вы найдете известных программистов глубоко в разногласиях по многим фундаментальным темам, таким как планирование, проектирование, ООП против процедурных, модульное тестирование, обработка исключений, контроль исходного кода, и так далее.

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

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

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

Что мне делать в такой ситуации?

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

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

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

Если вы на секунду подумаете, что руководство не понимает, насколько вы ДЕЙСТВИТЕЛЬНО способны выполнить работу, то вы, вероятно, ошибаетесь. Руководство, вероятно, также понимает, что ваше руководство сейчас будет совершенно бесполезным, если он заменит вас и возьмет на себя вашу работу.

НАСТОЯЩИЕ причины, по которым они вас не переселили, заключаются в том, что, несмотря на все ваши проблемы, которые вы им представляете, вы по-прежнему лучший человек для работы. Очевидно, они слишком высоко ценят вашу работу, чтобы рискнуть передать ее кому-либо еще.

Не стоит недооценивать интеллект руководства ...

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

Позвольте мне нарисовать для вас картину, лидерство с 5-летним опытом работы в компании некомпетентно. Менеджер знает это, рекомендует своему высшему руководителю уволить Ведущего А. Верхний менеджер спрашивает, почему с ним не сталкивались много лет назад, если он настолько некомпетентен. Менеджер выглядит плохо сейчас, тем более что у Lead A вздутая зарплата, которая выплачивается без выгоды ...

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

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

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

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

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

В прошлые выходные. Парень спорил / не соглашался со мной насчет синглетонов. Я сказал, что они не хороши и никогда не должны использоваться, и абсолютно нет причин использовать их. Я связал его с http://www.gmannickg.com/?p=24 и более подробной статьей, на которую он ссылаетсячерез несколько дней после ссоры. В день упоминания другого программиста (DudeB) он использует синглтоны только тогда, когда это уместно (к которому я добавил «никогда»). DudeB ничего не сказал об этом, но DudeB сказал, что DudeB был в проекте, который имел конфликт памяти, потому что все потоки обращались к синглтону. После упоминания этого, показа статьи и упоминания разногласий по памяти, с которыми я спорил, парень сказал, что мы должны согласиться не соглашаться, с чем я согласился, потому что я не люблю говорить о синглетонах (пока я пишу это д'о)

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

У меня совершенно другое / противоречивое мнение по этому поводу.

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

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

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

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

[Репост: потому что я как-то создал здесь второй аккаунт]

Но недавно он снова подошел ко мне, увидел мой код и спросил, почему я не изменил его на его предложение .

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

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

Заказ / и т.д.. = Я хочу, чтобы это было сделано так; и это мой выбор.

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