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

24

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

Aaronaught
источник
9
Я был в этой ситуации и никогда не видел, чтобы это действительно разрешилось успешно. Многие люди, как вы описали, перестали думать о программировании много лет назад; на данный момент они заинтересованы только в решениях для своего бизнеса. Я не собираюсь присоединяться к публичным выступлениям на этом сайте, которые осуждают таких людей; действительно, я думаю, что они соль земли. Если они работают в вашем коде, вы должны стремиться, по крайней мере, придерживаться ваших соглашений. У меня не было проблем с продажей, чтобы люди следовали существующим соглашениям, если они вносят свой вклад в проект.
Джереми
1
Что сказал твой босс, когда ты выразил ему эту обеспокоенность?
2
@ Aaronaught, поскольку его код работает, это не техническая, а политическая проблема, и, вероятно, она должна быть навязана сверху, если вы хотите что-то изменить. Другими словами от вашего босса. Иметь хорошие аргументы готовы!
2
@Thor: То есть, вы думаете, что абсолютно невозможно, чтобы его стиль был просто продуктом низких ожиданий, отсутствия экспертной оценки и занятой жизни, которая не поддается самостоятельному обучению в течение личного времени? Не забота - это не жесткая личностная черта, это продукт окружающей среды, и его можно изменить. Не зная даже легче изменения, но он все еще должен подходить с некоторым уровнем дипломатии.
Aaronaught
1
@Aaronaught, либо вы с треском провалились, чтобы стать источником вдохновения (что нельзя исключать), либо он не хочет, чтобы вас вдохновляли. Рассматриваете ли вы кодирование своих модульных тестов в Лиспе или Хаскеле, если бы кто-то из младших коллег сказал вам, что это намного умнее, чем то, что вы делаете сейчас?

Ответы:

10

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

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

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

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

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

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

jimreed
источник
Это похоже на хорошие общие стратегии. Мне должно быть ясно, что это просто VB6-старый, а не COBOL-старый. Может быть, на 5-7 лет отстает, а не на 20-30 лет. Так что не чудак / динозавр.
Aaronaught
1
Я бы не спрашивал "Почему ты так делаешь?" Это может иметь неблагоприятные последствия - немедленно поставить его в оборону. Возможно, сотрудник просто не знает, и вы не хотите, чтобы он чувствовал себя невежественным. Вместо этого спросите "Вы рассматривали этот метод?"
IAbstract
@IAbstract Если он любит преподавать, он не станет защищаться, он получит возможность преподавать. Тон и отношение будут иметь большое значение. Если это звучит так, как будто вы легко можете добавить «Идиот» в конце вопроса, значит, вы делаете это неправильно? :-) По моему опыту, большинство людей готовы отвечать на искренние вопросы.
Jimreed
@IAbstract: Я уверен, что если бы я спросил что-то вроде: «Вы рассматривали здесь внедрение зависимости?» ответ будет "а?" Конечно, есть шанс, что я буду приятно удивлен, но я думаю, что Джим прав, лучше начать разговор, чтобы спросить: «Почему вы решили использовать объект с глобальной областью действия Fooздесь?» Я не предвижу, что это будет интерпретировано как нападение; это я пытаюсь понять существующий дизайн.
Aaronaught
@Aaronaught: достаточно справедливо;) Хотя реакция на DI может быть «да?», Она может вызвать интересную беседу, типа «ну, я слышал об этом, но ...» ... меня больше всего беспокоит тон (как указывает jimreed) Конечно, как говорит jimreed, вы должны выбирать свои битвы - иногда это означает перенос большой палки, иногда - совместную игру в песочнице.
IAbstract
4

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

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

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

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

DKnight
источник
4

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

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

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

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

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


источник
Это делает (неверное) предположение, что я работаю на издателя программного обеспечения с вертикальной структурой. Менее 10% разработчиков работают в издателях программного обеспечения, и это не обязательно обязанность руководителя или среднего менеджера по микроуправлению разработчиками.
Ааронаут
2
@ Aaronaught Хорошо, тогда это истинный источник твоей проблемы. Если вы не в команде со стандартом кодирования и хотя бы одним опытным программистом, который будет руководить и направлять других, это плохая организация. Каждый будет кодировать случайным образом, думая, что он «артист», придумывая посредственные, нестабильные, неосуществимые результаты и не изучая, как улучшить.
2

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

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

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

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

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

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

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

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

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

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

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

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

Кен Бриттен
источник
1
-1 В вопросе уже говорится, что ФП не намерен подходить к этому конфронтационно. Пожалуйста, внимательно прочитайте вопрос ОП и ответьте на этот конкретный вопрос , а не обсуждайте тему в целом.
HedgeMage
1

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

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

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

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

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

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

Мартейн
источник
0

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

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

HLGEM
источник
-1

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

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

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

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

GrandmasterB
источник
2
Именно по этой причине я указал, что он из другой части компании. У него не было проблем с выполнением их требований, но их требования не соответствуют нашим требованиям. В частности, их требования не стали намного более продвинутыми, чем CRUD. И да, это проблема с кодом; он может нормально работать в изоляции, но не пройдет тесты интеграции, производительности или надежности. Я не верю в строгие методологии, такие как XP или TDD или что-то еще, но это не вопрос эстетики или общепринятого мнения, это вопрос требований к обслуживанию.
Ааронаут
3
Я также опровергаю это не по вышеуказанным причинам, а потому, что вы делаете несколько необоснованных предположений. (а) я не менее опытный, (б) ни одна из вещей, о которых я говорю, по праву не называется «причудами», и (в) это наиболее вопиюще нелепое предположение - он не самый продуктивный разработчик в команда, и, конечно, не более продуктивна, чем я.
Aaronaught
Если на самом деле есть проблема с тем, что он производит, то, как я уже сказал , это проблема для вашего руководителя или того, кем вы являетесь. Но вы не показали, что есть проблема с тем, что он доставляет клиенту / клиенту, просто вам не нравится то, что он доставляет вам. Что я имею в виду, он не пишет программы для вас. Поэтому, прежде чем вы пошевелитесь, я бы убедился, что он не менее необходим, чем вы.
GrandmasterB
Что касается причуд, подождите некоторое время в индустрии, и вы поймете, что да, сегодняшние лучшие практики - это плохие практики завтрашнего дня в стиле VB6. Что касается понижения голосов, конечно, не стесняйтесь. Я просто отвечаю на вопрос, как опубликовано. Я не могу ответить на детали, которые вы не предоставили.
GrandmasterB
1
Я не знаю ваше резюме, и при этом я не знаю, что ваши коллеги резюме. Я знаю только то, что вы поставили в вопросе. Если это была важная информация, вы должны были включить ее. И, основываясь на ваших ответах на другие ответы, вы можете подумать, что совсем немного не учли, что потребовало от экспертов много предположений. Но если вы хотите получить ответ, предполагая, что вы не его руководитель, проблема вашего руководителя или вашего общего руководителя беспокоиться о том, как не вызвать ажиотажа. Просто отклоните код, который вызывает проблемы при тестировании, и сообщите об этом вашему коллеге.
GrandmasterB
-1

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

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

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

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

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

maple_shaft
источник
1
Это ответ на совершенно иной вопрос, чем тот, который я задавал. (а) я не начинающий разработчик, (б) мой босс уже делегирует мне большинство важных решений по дизайну и коду, (в) его код, как известно, не глючит, просто недостаточно структурирован для ООП C # / функциональная смешанная парадигма, и (г) суть моего вопроса заключалась в том, как подойти к предмету так, чтобы они не обижались.
Aaronaught
1
@Aaronaught, а) «Этот программист немного старше меня». Из этого утверждения я предположил, что вы его «младший». б) Похоже, что вы технический руководитель, вы должны были поставить эту информацию в свой вопрос, это значительно меняет вещи. в) Если он не следует передовым методам и его код не содержит ошибок, то в чем проблема? Зачем к нему подходить ни о чем? Не исправляй то, что не сломано. d) Опять же, не подходите к нему, если он не вызывает ошибок с некачественным кодом. Реальная проблема заключается в том, что у вас нет стандартов кодирования и разработки, которые все должны соблюдать.
maple_shaft
Я подумал, что это довольно ясно подразумевается моей ссылкой на (не) «вмешательство с оружием в руках и проведение проверок кода« рип-это-к-клочкам »и ​​строго соблюдаемых политик» - почему я бы даже сказал, что если бы я был младшим ? И кто сказал, что у нас нет стандартов? Он просто никогда не работал с нашей командой раньше, и я пытаюсь внедрить стандарты, не придавая этому значения .
Aaronaught
-1 Не ответил на заданный вопрос.
HedgeMage
-1

Ты не можешь

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

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

Уэйн Молина
источник
4
Я ценю ответ, однако мне трудно в это поверить, главным образом потому, что я был именно таким программистом, который «просто справился» несколько лет назад. Никто не показал мне - я должен был открыть все это сам - но я уверен, что достаточно убедительный лидер (если бы он существовал) смог бы осуществить то же изменение. То, что некоторые люди изучают все это независимо, не обязательно означает, что все остальные - безнадежное дело.
Aaronaught
2
Это правда, но по моему опыту, если люди заботятся об улучшении, им нужно мало мотивации, чтобы вдохновляться, потому что желание уже есть - им, возможно, нужен толчок или совет, но они понимают и хотят совершенствоваться, просто нуждаются в руководстве. Я был таким же; Я выучил плохие способы ведения дел и подумал: «Должен быть лучший путь» и начал исследования. Однако то, что я видел, это то, что люди, которые не улучшаются или не проявляют желания улучшаться, являются потерянными причинами, потому что они не хотят улучшаться. Тем не менее, удачи в доказательстве меня неправильно :)
Уэйн Молина
1
Я думаю, что такие заявления должны быть обоснованы. Мне, безусловно, было бы интересно услышать (и еще больше выразить готовность высказаться) о реальных событиях в отношении того, что вы пытались безуспешно (и почему это было неудачно).
Aaronaught
1
Иногда это так, например, « старая собака, новые уловки » - попробуйте объяснить кому-то, как методы увеличили эффективность поиска данных на 800%, а сотрудник просто пожимает плечами.
IAbstract
2
Дело в том, что вы можете сделать это, и люди будут следовать за вами, но вам нужно занять более высокое место в иерархии. Вы не можете сделать это как простой разработчик в большинстве команд. Многие коллеги могут получить только незаданный совет от кого-то выше в иерархии. Если вы находитесь на одном уровне, они почувствуют себя обиженными и атакованными. Помните, что уважение заслужено. Если вы относитесь к ним хорошо и говорите это приятно и приятно, это может сработать, если вы тоже на том же уровне.
Сокол