Восстановление доверия старшего программиста [закрыто]

Мой босс узнал, что я не такой умный, как он думал.

Пример из моего опыта:

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

Мне было поручено разработать внутреннее веб-приложение для компании, в которой мы работаем. Я написал back-end для front-end (дизайн базы данных уже был на месте, и была выбрана технология сервера). Он периодически проверял мои успехи, наблюдая за веб-приложением в действии, и был доволен тем, что оно появилось. Когда я закончил веб-приложение, он был доволен тем, как хорошо получился конечный продукт.

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

Итак, учитывая этот пример, мой вопрос:

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

РЕДАКТИРОВАТЬ : Спасибо всем за отличные ответы и поддержку обратной связи!

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

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

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

tl; dr Вы хорошо сделали. Поговорите со своим старшим и посмотрите, что он ожидает от вас.

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

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

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

Чтобы ответить на ваш вопрос о том, что я хотел бы видеть в качестве старшего:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тот факт, что он старший программист, не делает его непогрешимым.

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

Если вы не упомянули о чем-то еще, я был бы раздражен в HIM.

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

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

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

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

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

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

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

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

Я всегда учусь. Хотя я бы очень хотел, чтобы мой работодатель брал мой счет на образование каждый год, редко они тратят что-то близкое к тому, что, на мой взгляд, мне действительно нужно, но я знаю, что я должен оставаться трудоспособным, поэтому я трачу где-то в районе £ 2000 GBP (примерно 3000 долларов США) на мое собственное образование каждый год.

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

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

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