Вдохновлять коллегу внедрять лучшие методы кодирования?

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

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

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

Однако фактический (C #) код, который я видел, является возвратом к дням VB6. Процедурная структура, венгерская нотация, глобальные переменные (злоупотребление static), отсутствие интерфейсов, никаких тестов, неиспользование универсальных элементов, бросание System.Exception... вы понимаете.

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

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

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

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

Разъяснения:

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

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

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

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

• Упоминание «... глобальные переменные ... никаких тестов ... выбрасывание System.Exception» предназначалось для демонстрации того, что проблемы не являются только поверхностными или эстетическими . Практики, которые могут работать для относительно небольших приложений CRUD, не обязательно работают для крупных корпоративных приложений, и фактически ни один из кодов до сих пор фактически не прошел интеграционные тесты.

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

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

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

Вам все еще нужно выяснить, что будет мотивировать этого конкретного человека. То, что работает на одном старом чудике (как я), может не сработать на твоем старом чудике.

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

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

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

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

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

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

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

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

Это действительно работа вашего менеджера

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

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

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

Для справки посмотрите, как написаны стандарты MISRA-C / C ++ и CERT C / C ++ / Java.

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

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

У меня есть предложение о том, как вы можете сэкономить утомительное время для вас и деньги для компании. Вы заинтересованы?

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

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

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

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

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

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

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

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

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

1. Опишите поведение, которое вы видите. Это должно быть конкретное поведение. Пример: «Я вижу, что вы используете много статических переменных в вашем коде»
2. Опишите, как это влияет на вас / вашу команду. Пример: «Я считаю, что такой код трудно поддерживать»
3. Предложи разумное решение. (возможные решения упомянуты в других ответах, и позже я постараюсь в этом разобраться.)
4. Дайте ему возможность обсудить решение. Спросите его, что он думает о решении. Возьмите его ответ за чистую монету. Вы дали ему свое мнение, и он может принять это или нет. *

Быстрый ресурс по обратной связи может быть найден, например, по адресу http://managementhelp.org/communicationsskills/feedback.htm. (хотя в Интернете существует множество подобных материалов)

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

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

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

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

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

Вопрос в 64 000 долларов заключается в том, выполняет ли он свои проекты вовремя и отвечает ли функциональным требованиям. Если так, он делает это правильно. В разработке программного обеспечения нет объективного правильного или неправильного пути. В конечном счете, о решении проблем. И если проблемы решаются к удовлетворению клиента / клиента, то по определению , разработка программного обеспечения выполняется правильно.

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

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

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

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

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

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

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

Если вы не можете продать босса или он Босс, то просто разберитесь с его ошибками, но приведите пример в ВАШЕМ коде.

Ты не можешь

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

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