Как бороться с непрофессиональным поведением стажеров?

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

Я бы порекомендовал вам быть с ним/ней твердыми и сказать что-то вроде:

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

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

После просмотра этого видео я вижу, что работники желают 3 вещей:

1. Автономия
2. Мастерство
3. Цель

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

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

Некоторые примеры:

1. Вот этот проект, работайте вместе и сделайте его до ____, дайте мне знать, если вы застряли.

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

TL;DR : я возражаю против названия метода, потому что оно (на мой взгляд!) выражает презрение к боссу и/или «правилам» (здесь: рекомендации по стилю). На рабочем месте я ожидаю, что люди будут соблюдать правило «люби это, измени это или оставь это». В этом случае стажер, который, кажется, считает, что руководство не нужно, должен либо просто принять его в любом случае; или продолжайте дискуссию об этом; или прекратить делать то, что он делает. Не помещайте в эквивалент некоторого размазывания в туалете. У меня не было бы никаких возражений против действительно забавного, креативного названия метода. Если вы (ОП) находите название метода просто забавным, а не «плохим», как я, то проигнорируйте этот ответ, пожалуйста.

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

Я хотел бы знать, как справиться с такой ситуацией правильно.

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

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

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

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

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

Попробуйте найти первопричину. Если вы обнаружите, что либо...

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

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

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

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

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

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

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

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

Если они продолжат вести себя по-детски, то, думаю, вы пришли к следующему выводу:

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

О, куча отвертки, а?

Возьмите какой-нибудь рабочий код и сделайте что-нибудь, чтобы намеренно его сломать. Затем пропустите его через обфускатор, который изменит все имена классов, переменных и методов на такие вещи, как «a___1318798_» и «xy23_7a963»; или, что еще хуже, имена переменных с большим количеством букв O, букв I, цифр 0 и цифр 1 в них. Поручите им документировать, что делает код, и исправьте это.

Это избавит от шуток.

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

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

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

Надеюсь, вы следите за их производительностью и можете заметить, как часто это происходит.

Я бы поговорил с каждым из них по душам, наедине, в откровенном и серьезном, но не суровом тоне, примерно так:

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

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

Если он говорит, что хочет учиться, скажите что-то вроде этого:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Похоже, здесь есть две основные проблемы: 1) они непочтительны и 2) название функции все еще отстой, хотя теперь оно длиннее.

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

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

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

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

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

1. Это прививает личную ответственность за результат проекта
2. Обеспечивает немедленную профессиональную обратную связь
3. Дайте разработчику ощущение срочности завершения проекта

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

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

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

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

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

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

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

Попросите их исправить код или (если вы хотите проявить авторитет) просто откатите их изменения в системе контроля версий.

Это не должно быть «один размер подходит всем».
Все размеры подходят некоторым:

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

Должен ли я реагировать на

• отшутиться («Да, это смешно, но уберите это, пожалуйста»)

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

• просто вежливо прошу удалить

Это отличная идея, когда: Вы хотите быть прямолинейным, чтобы не было недопонимания

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

Это отличная идея, если: Вы хотите выразить раздражение и придерживаетесь авторитарного подхода.

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

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

Но что лучше?
Ваш основной вопрос: «Как я должен реагировать на это?»

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

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

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

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

Гибкое обучение: не ограничивайтесь одним подходом.

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

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

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

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

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

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

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

• Заслужите уважение стажеров, перехитрив «лидера», «альфу».

• Используйте педантичное название функции в качестве урока для всех, оптимальная длина имени функции: зона Златовласки.

• Укажите на ошибку в функции «convertToMillilitersBecauseIAmUsingSuchCleanCode» и предложите переименовать ее во что-то подходящее (/унизительное)

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

Я хотел бы отметить имена непрофессиональных стажеров в качестве меры предосторожности.

Как профессионал с почти 30-летним стажем, я бы сказал, что ответы с высоким рейтингом в основном верны.

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

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

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

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

Должен ли я реагировать на

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

Как насчет " понимания, почему они это сделали? "

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

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

Альтернативный подход

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

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

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

Вы видели это.

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

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

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

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

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

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

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

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

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

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

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

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

В идеале это будет примерно по строке на функцию, например.

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

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

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

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

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

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

Вы не их менеджер, даже не важно, берете ли вы у них интервью или нет. Ты такой же инженер, как и я,

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

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

Если бы я был стажером, и я работаю под вашим началом, а вы просто старший инженер, даже я ненавижу, если вы управляете моим персоналом. Это НЕ ваша работа.

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