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

266

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

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

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

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

learnjourney
источник
26
Вы учитесь больше на ошибках, чем на успехах.
StuperUser
45
Можете ли вы привести пример одной из проблем, с которыми вы не согласны? Я знаю, что это скорее теоретический вопрос, и вы, вероятно, хотите избежать технических дебатов, но было бы интересно услышать, чем закончились разногласия.
Адам Рэкис
140
Я вижу один красный флаг в этом посте. Вас должны были попросить сделать что-то три раза. Один раз должно быть достаточно. Если вы не хотите что-то делать, вам нужно убедить своего наставника, что в этом нет необходимости. Если вы не можете этого сделать, то либо держите нос и делайте это, либо найдите новую работу.
PeterAllenWebb
6
@peterallenweb, действительно, это плохо, когда тебя спрашивают 3 раза, независимо от качества совета. Я думаю, из комментариев здесь мне есть чему поучиться с точки зрения работы в разных командах. :)
Учебная поездка
33
В дополнение к тому, что сказал Питер: рассмотрите его точку зрения: вы просите нового парня что-то сделать, провести техническую дискуссию, больше не возражаете, а затем - через неделю вы обнаружите, что он просто проигнорировал ваш запрос. И это не первый раз, когда это происходит. (Не беспокойтесь слишком сильно - вы, конечно, не первый человек, поступивший прямо из колледжа, попавший в эту ловушку. Пока вы знаете об этих проблемах и работаете над ними, вы будете в порядке.)
Мартин,

Ответы:

233

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

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

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

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

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

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

оборота Джоэл Этертон
источник
47
@Joel Хороший ответ, но остерегайтесь "отбросить" проблемы. Обеспокоенность всегда следует признавать, даже если она недействительна, даже если лучший ответ, который у вас есть: «Я понимаю вашу озабоченность, но сейчас мы должны сделать X из-за Y». Безрассудный отказ от серьезных идей является моральным убийцей и может в конечном итоге уничтожить даже самые здоровые культуры.
Рейн Хенрикс
42
@Joel: много хороших моментов, но это немного снисходительно: «Это эквивалентно тому, чтобы быть подростком с точки зрения программного обеспечения». Уважение, которое старший зарабатывает от младших разработчиков, завоевывается последовательным принятием правильных решений, а не простым фактом возраста или старшинства.
Нил Дж
26
Нет смысла отвечать на вопрос, откуда вы знаете, «хороший» старший разработчик или нет. Похоже, что ответ здесь такой: «не важно просто делать то, что он говорит». Я не говорю, что это неправильный совет; Я просто говорю, что это не отвечает на вопрос. Что бы это ни стоило, я думаю, что единственный правильный ответ - вы узнаете, будет ли он хорошим за 5 лет, когда вы станете старшим.
Кевин
2
@Kevin: Я не могу поспорить с этим комментарием, и я, конечно, не могу рекомендовать младшему разработчику какой-либо метод, чтобы определить способ ответить на этот конкретный вопрос. Часто пожилые люди не могут точно ответить друг другу. Мой ответ был честно ориентирован на некоторые другие аспекты вопроса ОП, которые показались мне более важными, чем то, как определить дерьмового старшего разработчика.
Джоэл Этертон
11
Похоже, что ответу не хватает того смирения, о котором вы говорите. Молодые люди часто думают, что знают все, но разве старшие люди не разделяют один и тот же порок? Это преувеличено в нашей отрасли - большая часть знаний, которые мы имеем, через несколько лет станет менее актуальной. (Пример из реальной жизни - у меня есть наставник в среднем проекте, который сказал, что мы должны «сделать несколько кнопок и написать на них SQL, чтобы сэкономить время». Он был очень впечатлен, когда я показал ему LINQ to Entity и asp.net страница без кода )
Коби
35

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

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

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

JZD
источник
29
ОП - вы оба профессионалы, даже если у вас меньше опыта, так что поговорите с ним на профессиональную тему. Если он не хочет говорить о причинах своих инструкций, он не очень наставник.
Дэйв
10
+1 За «Он больше для успеха проекта, чем вы». Как это правда. Я знаю, что вы, младшие разработчики, не цените, как вам повезло, что у вас нет такого стресса, потому что я не знал, когда был младшим разработчиком. А теперь иди с моей лужайки!
maple_shaft
1
Я также хотел бы предложить, чтобы, если / когда вы будете следовать его советам, сохраните документ о своих опасениях в отношении изменения - если оно произойдет позже, вы можете указать на это, чтобы показать, что вы предсказали ошибку.
Дейнит
4
@DaveE: Похоже, у них уже было обсуждение, и у ОП просто не хватило контекста, чтобы понять мудрость старшего. Иногда есть только так много, что вы можете объяснить, а остальное нужно будет получить из опыта.
Мартин Йорк,
2
@Niphra: возможно. Но без более точной информации я более склонен полагать, что это просто наивный ученик, который знает меньше, чем он думает. Большинство пожилых людей на самом деле знают, что они делают (вы не становитесь старшим инженером, если вы глупы, вместо этого вы переходите в управление).
Мартин Йорк
24

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

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

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

Рейн Хенрикс
источник
4
+1 за разговор. Старший разработчик может лучше (и нести ответственность) уравновесить различные проблемы, но он должен быть в состоянии объяснить свои причины. Объяснение себя юниорам, чтобы они могли учиться, является большой частью того, чтобы быть старшим. И если вы как младший не чувствуете, что учитесь, возможно, пришло время сменить работу.
Яап
+1 за лучшую работу один на один. Время разногласий за закрытыми дверями. Когда дверь откроется и дискуссия закончится, не должно быть никаких ссор, недосказанностей, ни нытья. Не открывайте дверь, пока не доберетесь до этой точки. Если вы все еще не согласны, скажите старшему по его / ее лицу, что вы намерены поднять это его / ее руководителю.
Майкл Райли - AKA Gunny
18

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

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

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

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

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

Уэйн Молина
источник
Я должен признать, что на самом деле я в шоке, что у меня есть семь голосов «против» (на данный момент) и нет голосов «против». Я бы подумал, что мое отношение / пессимистический взгляд / неопрятный тон не будет хорошо сочетаться с людьми :)
Уэйн Молина
На Slashdot объявление о том, что вы ожидаете, что вы будете моддированы, было проверенной и проверенной техникой в ​​поклонении карме.
Carson63000
Я должен буду попробовать это чаще J / K :)
Уэйн Молина
11

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

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

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

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

maple_shaft
источник
11

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

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

Кевин Клайн
источник
9
Слепое высказывание «нам нужно использовать лучшие отраслевые практики» может быть не лучшим способом начать дискуссию. Там может быть очень веская причина, чтобы сделать что-то еще, чем большинство других.
7
Я думаю, что это самый близкий к фактическому ответу. Старший разработчик должен предоставить убедительные причины того, что методы, которые он защищает, являются разумными. Вы не сможете совершенствоваться под наставничеством того, кто не может. Теперь, если вы оказались в своей третьей компании, и все старшие разработчики на всех из них были, по вашему мнению, идиотами, возможно, пришло время более пристально взглянуть в зеркало.
PeterAllenWebb
2
@PeterAllenWebb, «должно быть в состоянии», да, но вам не обязательно спорить час за часом, детально выясняя, почему вы считаете, что данная практика вредна для вас. Иногда на вопрос «почему?» Можно ответить «потому что!»
@ Thorbjørn Равн Андерсен: Я согласен, пока это случайно.
PeterAllenWebb
11

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

HLGEM
источник
Я ценю ваше мышление, но я боюсь будущего и спекулятивного, так как могут быть более сложные ситуации, в которых публикация на форумах может не помочь. Что мне тогда делать?
developer123
4
Копайся в книгах и учись в глубине. Интернет не единственный способ учиться. Присоединитесь к местной группе разработчиков и наладьте контакты с более старшими людьми, которых вы можете найти наставнику.
HLGEM
этот подходит.
developer123
9

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

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

повторный показ
источник
6
Как младший разработчик, этот тип диктатуры сводил меня с ума. Я проголосовал против, извините.
kizzx2
9

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дело в точке

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

Темная ночь
источник
11
@maple_shaft: что вы за команда, если код (и все, кто его поддерживает) должен пострадать, чтобы защитить чувства старших разработчиков?
Яап
1
@Jaap, Прежде всего, я говорю о техническом руководителе или руководителе проекта, это не обязательно должен быть старший разработчик. Во-вторых, речь идет не об их чувствах, а о достижении общей цели как группы. У лидера должно быть некоторое подобие контроля над его группой независимо от того, ошибается ли он. Лидирует тот, кто берет на себя ответственность за некорректный код, неполные функции и пропущенные сроки, поэтому, если он дурак, он будет страдать. Если компания не признает, что он дурак, то компания пострадает.
maple_shaft
2
Если ему уже было сказано изменить его, то проверка кода не удалась. Просто попытка отправить его снова означает, что ему скажут, что это уже не удалось.
Мартин Йорк
2
@ darknight, если предположить, что это не крошечная проблема, изменение парадигм в существующей кодовой базе может иметь серьезные последствия. Когда я думаю о подобных дебатах, мне приходит в голову структура базы данных. Подобные изменения наверняка не будут оценены.
Морган Херлокер
1
Это относится только к очень маленьким единицам работы. Скажем, вы работали в течение двух недель, а код отклонен - ​​как вы получите финансирование на эти две недели?
7

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

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

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

Blrfl
источник
7

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

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

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

Морган Херлокер
источник
6

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

Джим Крэндалл
источник
4

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

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

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

Тим Меерс
источник
3

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

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

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

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

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

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

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

Стивен А. Лоу
источник
2

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

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

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

Амар Джарубула
источник
Спасибо вам, HLGEM и Jarrod за то, что указали на положительные стороны.
developer123
1

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

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

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

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

BBlake
источник
1

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

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

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

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

Димитриос Мистриотис
источник
5
Почти никогда нет веской причины игнорировать лучшие отраслевые практики, за исключением невежества и / или нежелания делать это правильно. Это «лучшие» практики по определенной причине, и люди, которые их придумали, в десять раз умнее и даже старше, чем старший разработчик, который игнорирует или не знает о них.
Уэйн Молина
@ Уэйн М: Хорошо сказано.
Джим Г.
6
@ Уэйн, тебе все еще нужно понять, почему это лучшие практики. Если вы слепо говорите: «Это лучшая практика, мы должны это сделать!» не зная почему, ты не лучше себя.
Я бы сказал, что Уэйн оставил достаточно места в своем ответе на опровержение Андерсена.
С Джонсон
@ Thorbjørn Ravn Andersen, @learnjourney - Из всех комментариев и ответов комментарий Thorbjørn, вероятно, является наиболее важным и важным советом. Вы должны понимать проблемы, которые данная передовая практика пыталась предотвратить или решить, иначе вы никогда не узнаете, применимы ли эти проблемы. Короче говоря, вы должны понимать, почему это лучшая практика. Вот как вы предлагаете альтернативы: освещая проблемы, которые решает лучшая практика. Как сказал Меровинг из Матрицы: «Без« Почему »у тебя ничего нет».
Томас
1

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

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

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

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

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

Роб П.
источник
17
-1: У меня есть начальник, насколько я могу судить, вся моя работа - сделать моего босса счастливым. Это не второе предположение о решениях, принятых вне моей зарплаты. Ты никогда не будешь работать на меня. Я не нанимаю «Да, мужчины». Я хочу, чтобы мои прямые доклады содержали конструктивную критику, когда я собираюсь принять неоптимальное решение. Если бы я не ценил их мнение, я бы их не нанял.
Джим Г.
7
Я не согласен с этим мнением. Во-первых, если вы хотите получить повышение по службе, вы должны показать, что вы способны и готовы взять на себя обязанности старшего сотрудника, поэтому в этом отношении держать голову нехорошо для вашей долгосрочной карьеры. Во-вторых, я не верю в подход к работе «выше моей зарплаты». Все должны сделать компанию успешной (если это не так, у вас больше нет работы), поэтому, если вы видите лучший способ сделать что-то, превышающее уровень оплаты или нет, вы должны указать на это. Иногда новый наем может сделать хорошие предложения, потому что у них есть новая перспектива.
Cercerilla
6
Согласитесь с @Jim G. Быть «Смитерсом» - это худшее, что вы можете сделать; думать, что твой менеджер всегда прав - ужасная вещь, потому что часто они не правы. Также согласитесь с @CodeninjaTim - у нового найма часто бывают лучшие предложения, потому что у них нет такого мнения, как у долгосрочных ребят, поэтому они с меньшей вероятностью будут просто следовать «статус-кво»
Уэйн Молина
4
@ Джим Г .: Похоже, что ОП уже выразил свою обеспокоенность «Это уже третий раз за 2-3 недели». - Я не могу себе представить, что вы захотите нанять кого-то, кто после того, как высказал свое мнение и объяснил, что А лучше, чем Б (даже если он не согласен), он отказывается внести изменения. В этот момент он действительно не «работает на тебя».
Роб П.
3
@Wayne M - я не сторонник того, чтобы мы верили, что наши менеджеры всегда правы. Я предложил поднять его проблемы соответствующим образом. Но после того, как ему сказали сделать что-то 3 раза в течение нескольких недель, OP не справляется с этим правильно. Обязательно озвучьте свои проблемы, но поймите, что вы РАБОТАЕТЕ (если вы не заняты - тогда игнорируйте это). Вы согласились сделать работу для кого-то другого в обмен на некоторый уровень компенсации. Тот факт, что у вас есть начальник, подразумевает, что вы делаете то, что вам говорят, в разумных пределах. Правильно или нет, это то, что вы подписались как работник
Роб П.
1

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

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

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

Мистер джефферсон
источник
1

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

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

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

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

Калеб Хуитт - Джуитт
источник
Я просил разъяснений, но ответ, который я всегда получал, это «это лучшая практика» или что-то в этом роде, прежде чем он вернулся, чтобы заняться своими делами. На мой взгляд, одно дело сказать, что это хорошая или лучшая практика, но я хотел бы знать, «почему», лучше, что он не смог мне объяснить, но настаивать лучше, так как он старший. Я должен доверять ему. Тем не менее, это плохо с моей стороны, чтобы не измениться, несмотря на то, что меня спросили об этом 3 раза.
Учебная поездка
@learnjourney: Я согласен, что есть проблема, если вы спрашиваете почему, а не получаете ответы. Я бы по-прежнему рекомендовал, чтобы вы знали о том, как это может выглядеть с другой стороны, но если этот старший разработчик не может вам помочь, найдите другого и поставьте перед ними проблему, только с базовыми ", сказал он <причина>, Вы можете объяснить, как это применимо здесь? », и никаких обвинений. Если это не сработает, то я бы посмотрел на некоторые другие ответы, в которых говорится, чтобы внести изменения в любом случае, но держать вашу версию и причины под рукой. Обязательно учитесь на этом в любом случае.
Калеб Хуитт - cjhuitt
1

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

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

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

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

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

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

Sylverdrag
источник
1

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

Александр
источник
1

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

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

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

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

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


источник
Да, это единственная оптимистичная вещь, которую я вижу в моей ситуации.
developer123
1

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

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

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

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

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

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

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

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

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

maple_shaft
источник
Спасибо за ответ и привлечение управленческой стороны мышления и их точек зрения. Upvote для вас.
developer123
0

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

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

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

user2528
источник
1
Re: «Может быть, кто-то не согласится со синглетами со мной в комментарии» - я не согласен с вами; о) Но давайте согласимся не согласиться
JW01
0

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

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

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

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

Адам Гент
источник
-1: так смешно. // Суть вашего "противоречивого" мнения заключается в том, что ФП пойман в мелочах или мелочах. Вы этого не знаете! Возьмите вопрос за чистую монету.
Джим Г.
Большая часть программирования - минутный Джим Г. И по опыту (я старший разработчик) есть много других БС, связанных с тем, чтобы быть правым . Почти всегда есть большая картина. И люди наверху реагируют на большую картину (см. Его обновление), а не на «но мой дизайн более отделен». Поскольку ФП не приводил пример, мне пришлось проявить некоторую свободу.
Адам Гент
0

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

Мэтт Вилко
источник
5
-1: зачем тратить 2+ года на старшую работу n00b?
Джим Г.
@Jim - перемещение работы через 6 месяцев не очень хорошо выглядит в вашем резюме. Если вы переезжаете куда-то еще, а старший - еще хуже, эффект на ваше резюме будет экспоненциально плохим! Также вы можете научиться понимать, что не все, что они сказали, было неверным, или, по крайней мере, была причина для этого.
Мэтт Вилко
1
@Jim - Хотя я и согласен на практике, у Мэтта есть смысл; люди глупы, и постоянный переход на другую работу, пытаясь найти подходящую среду, может повредить вам (я могу сказать по своему опыту). Это зависит от того, какой именно совет, является ли он просто неоптимальным (например, мы не можем сделать TDD или использовать контейнер IoC) или совершенно неверным (например, я не знаю, что такое интерфейс или почему вы когда-либо использовали бы его в программирование). Первый может «высовываться», а второй - куда ты убежишь, крича, потому что старший - идиот (надеюсь, я правильно понял эти термины… они меня всегда смущают)
Уэйн Молина
0

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

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

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

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

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

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

BIBD
источник