2017-07-11 16:05:54 +0000 2017-07-11 16:05:54 +0000
205
205
Advertisement

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

Advertisement

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

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

Я помогаю им в разработке на ежедневной основе (быстрые встречи для решения вопросов, которые они не могут решить самостоятельно) и делаю обзор кода. Одной из основных проблем, с которой они сталкиваются, является то, что они не следуют конвенциям о названиях и создают плохие и короткие названия методов (например, convert). Конечно, я объяснил им, что правильное наименование очень важно, что они не должны бояться использовать более длинные, описательные имена методов (например, convertGallonsToMilliliters). К сожалению, некоторые из них (и я знаю кто, потому что они используют версионный контроль), видимо, решили повеселиться (или высмеять меня) и начали создавать дурацкие имена методов типа convertToMillilitersBecauseIAmUsingSuchCleanCode - не единичное явление, а несколько.

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

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

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

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

  • *

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

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

Advertisement
Advertisement

Ответы (21)

277
277
277
2017-07-11 16:13:04 +0000

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

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

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

109
109
109
2017-07-11 17:06:08 +0000

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

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

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

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

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

Примеры:

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

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

46
Advertisement
46
46
2017-07-11 21:49:11 +0000
Advertisement

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

  • *

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

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

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

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

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

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

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

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

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

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

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

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

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

33
33
33
2017-07-11 16:50:40 +0000

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

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

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

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

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

25
Advertisement
25
25
2017-07-11 19:30:45 +0000
Advertisement

Ох, кучка отморозков, да?

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

Это излечит от шуток.

22
22
22
2017-07-11 17:48:49 +0000

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

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

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

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

17
Advertisement
17
17
2017-07-11 21:42:39 +0000
Advertisement

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

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

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

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

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

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

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

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

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

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

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

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

12
12
12
2017-07-11 18:52:55 +0000

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

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

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

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

9
Advertisement
9
9
2017-07-11 17:58:26 +0000
Advertisement

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

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

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

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

5
5
5
2017-07-11 20:35:15 +0000

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

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

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

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

3
3
3
2017-07-12 14:49:30 +0000

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

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

3
3
3
2017-07-11 17:57:48 +0000

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

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

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

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

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

3
3
3
2017-07-12 06:17:32 +0000

Это не обязательно должно быть “Один размер подходит всем”. Все размеры подходят Some:

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

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

  • смеясь над этим (“Да, это забавно, но, пожалуйста, удалите это”)

Это отличная идея, когда: У вас отличный контакт с этими коллегами, которые подружились с

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

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

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

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

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

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

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

В основном, то, к чему этот вопрос сводится, это как сказать: “Мне нужно кое-куда добраться. Должен ли я использовать велосипед, погостик, велосипед или автобус?”

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

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

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

Гибкое учение: Не соглашайтесь только на один подход.

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

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

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

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

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

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

2
2
2
2017-07-11 16:23:11 +0000

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

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

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

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

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

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

2
2
2
2017-07-13 12:57:23 +0000

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

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

Как насчет “ Понимаешь, почему они сделали это? **

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

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

В альтернативном подходе

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

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

2
2
2
2017-07-13 15:06:47 +0000

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

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

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

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

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

1
1
1
2017-07-14 20:41:26 +0000

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

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

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

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

0
0
0
2017-07-13 00:40:21 +0000

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

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

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

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

В идеале, это было бы около строки для каждой функции, например,

convertGalToml: Преобразовывает Галлоны в Миллилилитров. Кэш верблюдов не использовался в аббревиатуре миллилитров, чтобы избежать путаницы с мегалитерами.

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

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

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

0
0
0
2017-07-12 02:31:19 +0000

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

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

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

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

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

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

-3
-3
-3
2017-07-15 15:01:55 +0000
-4
-4
-4
2017-07-15 01:10:02 +0000

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

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

Advertisement

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

21
9
15
13
7
Advertisement
Advertisement