Как заставить людей останавливать байклинг (фокусируясь на мелочах)?

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

Why is that named that? (2 минуты, чтобы объяснить, почему он назван так, 10+ минут, обсуждая новое имя)

Why is that an abstract base class rather than an interface? (2 минуты, чтобы объяснить, 10 + минут обсуждают относительные достоинства этого решения)

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

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

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

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

137 голосов | спросил Telastyn 21 42013vEurope/Moscow11bEurope/MoscowThu, 21 Nov 2013 06:21:58 +0400 2013, 06:21:58

8 ответов


158

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

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

Представляя на уровне кода, вы вызываете мышление уровня кода.

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

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

Теперь задайте некоторые проблемы класса для работы. Как мы можем улучшить X? Выбирайте что-то нетривиальное, которое «идет с потоком» дизайна системы и работает через то, что вы измените. Теперь они должны получить обоснование системы. Выберите другое усовершенствование, которое может сломать систему, если сделано неправильно, и показать, как это можно сделать правильно. Для них это должен быть момент Ah Ha . Некоторые могут даже победить вас!

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

ответил andy256 21 42013vEurope/Moscow11bEurope/MoscowThu, 21 Nov 2013 07:02:59 +0400 2013, 07:02:59
66

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

ответил mattnz 21 42013vEurope/Moscow11bEurope/MoscowThu, 21 Nov 2013 07:42:59 +0400 2013, 07:42:59
21

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

Убедитесь, что ваши цели открытые и прозрачные.

Начните обсуждение с просмотром высокого уровня, продвигаемого andy256 (+1), но также убедитесь, что вы включаете свои цели, например.

"... когда мы рассмотрим эту проблему, давайте не будем фокусироваться на x, y и z. Пусть также мы не будем рассматривать детали реализации, такие как a, b, c или тривиальные детали, такие как j, k, I. Я знаю, что в коде должно быть много деталей, а также детали, которые можно было бы решить, улучшить или сделать более стандартными, но давайте посмотрим, что он действительно достигает на более высокий уровень "

ответил Michael Durrant 21 42013vEurope/Moscow11bEurope/MoscowThu, 21 Nov 2013 07:40:16 +0400 2013, 07:40:16
17
  

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

Во-первых, не думайте о своих проблемах как о «мелочах» или «bikeshedding». Это словесные слова, и они оскорбительны. Их проблемы актуальны. В настоящий момент они не важны.

Ключ к любой хорошей встрече - это для всех:

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

Согласитесь с этим, явно и объясните цели.

Например, вы можете сказать: «Эта встреча для меня, чтобы ознакомить вас с пакетом Foo и тем, как он используется в нашем модуле отчетов. Моя цель состоит в том, чтобы вы достаточно поняли о Foo, что вы можете работать над отчетами Bar проект на следующей неделе. Я хотел бы, чтобы мы были сделаны в течение следующих 90 минут ».

Затем, когда тема появляется, она может выглядеть так:

  

Новый человек: «Почему FooWidget реализован как шаблон фасада?»

     

Вы: «Ну, я думаю, это потому, что (короткое объяснение дизайнерского решения)» или «Я не знаю».

Если ответа достаточно, это здорово. Если нет, и он продолжается:

  

NP: «Разве вы не думаете, что лучше сделать это как одноэлемент?»

     

Вы: «Я действительно не думал об этом, но я хотел бы продолжать рассказывать, как работает FooWidget».

     

NP: «Но если это делается как одиночный, тогда мы можем -

     

Вы: «Мне жаль прерывать, но мне нужно сосредоточить внимание на том, как работает FooWidget. Эта встреча запланирована только на 11:00, и нам предстоит многое пройти. Дискуссия по дизайну придется ждать в другой раз ».

После того, как вы пройдете через это один или два раза, вы можете сократить его до «Это выходит за рамки этой встречи».

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

ответил Andy Lester 22 52013vEurope/Moscow11bEurope/MoscowFri, 22 Nov 2013 02:22:38 +0400 2013, 02:22:38
4

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

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

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

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

ответил Andyz Smith 21 42013vEurope/Moscow11bEurope/MoscowThu, 21 Nov 2013 19:46:15 +0400 2013, 19:46:15
3

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

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

Основываясь на этих двух идеях, я предлагаю разбить базу кода на единицы, а учащиеся - на группы с двумя людьми. Для каждой единицы кода каждая группа будет иметь, скажем, 25 минут (в зависимости от LOC , конечно ), чтобы иметь возможность сделать 5-10-минутное прохождение кода другим. Три минуты вопросов и повторите со следующей единицей. Объяснить это ключевое слово; они должны обеспечить, чтобы все поняли все это.

Вы были бы только там, чтобы обеспечить время, не вне темы, и управление устройством было понято достаточно. Они будут актерами их обучения и будут более сосредоточены на объяснении другим, чем на bikeshedding.

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

Извините, если вы уже пробовали это ...

ответил feydaykyn 22 52013vEurope/Moscow11bEurope/MoscowFri, 22 Nov 2013 02:33:03 +0400 2013, 02:33:03
1

Вы пробовали делать предварительные уроки, которые люди смотрели индивидуально?

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

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

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

ответил Joe 21 42013vEurope/Moscow11bEurope/MoscowThu, 21 Nov 2013 06:31:56 +0400 2013, 06:31:56
1

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

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

ответил Bobble 22 52013vEurope/Moscow11bEurope/MoscowFri, 22 Nov 2013 04:11:50 +0400 2013, 04:11:50

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132