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

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

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

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

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

266 голосов | спросил 22 revs, 10 users 53%
learnjourney
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

30 ответов


233

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

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

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

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
35

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
24

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
18

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

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

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
11

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

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
11

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
11

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
9

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
9

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

  

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

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

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

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

  

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

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

  

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

     

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

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

Вот несколько советов.

  1. Не раздражайтесь в своей ситуации - пробный огонь, а не забавный, учит вас критическим навыкам исследования на более позднем этапе вашей карьеры.
  2. Начните подталкивать свое руководство к более активному участию. Сделайте это тщательно и с уважением . Продолжайте настаивать и упорствовать, пока он не придет (это действительно работает для многих ситуаций в жизни).
  3. Если ваш лидер не будет участвовать, посмотрите, есть ли другие, которые могли бы вам помочь. Если вы не работаете в магазине для пота, который касается только часов доения, ваша компания не будет возражать против другого разработчика, который больше испытывает вас, демонстрируя вам некоторые канаты и просматривая ваш код.
  4. Начните следить за новой работой. Я бы не сказал, что вы находитесь в ситуации «должен уйти», но это не повредило бы вашей карьере быть в месте, которое более серьезно относится к вашей разработке программы.
ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
7

Если у вас есть лучший способ решить определенную проблему, просто СДЕЛАЙТЕ ЭТО .

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

Дело в точке

  

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
7
  

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

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

В то же время прочитайте ответ Джоэла Этертона.

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
7

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
6

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
4

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
3

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
2

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
2

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
1

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

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
1

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

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
1

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

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

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
1

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
1
  

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

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
1

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

1 /Это работает? Он работает или нет? Является ли какой-либо объективной причиной, почему его путь был ниже?

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

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

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

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
1

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

ответил Ray Toal 11 Jpm1000000pmSun, 11 Jan 2015 23:19:41 +030015 2015, 23:19:41
1
  

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

     

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

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

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

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

ответил 19 PM00000060000001231 2011, 18:27:12
1

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

РЕАЛЬНЫЕ причины, по которым они не переместились, потому что, несмотря на все ваши проблемы, которые вы им представляете, вы по-прежнему являетесь лучшим человеком для работы. Они явно ценят вашу работу слишком много, чтобы рискнуть передать ее кому-либо еще.

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

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

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

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

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

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

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

ответил 19 PM00000060000001231 2011, 18:27:12
0

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

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

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

ответил 19 PM00000060000001231 2011, 18:27:12
0

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

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

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

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

ответил 19 PM00000060000001231 2011, 18:27:12
0

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

ответил 19 PM00000060000001231 2011, 18:27:12
0

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

  

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

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

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

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

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

ответил 19 PM00000060000001231 2011, 18:27:12

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132