Поощрять превосходство, не указывая на некомпетентность

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

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

Примеры: оставлять много предупреждений в коде, комментировать тысячи строк и никогда не очищать и не объяснять их, циклы с разрывом, поэтому он будет выполняться только один раз, проверка логического значения на истинность/ложь и ноль, проверка неработающие сборки, сборка простых голдбергов, неиспользование служебных классов и констант приложений, многократное написание одного и того же в одном и том же блоке кода, написание простого логически неверного кода. Это может сопровождаться или не сопровождаться общей некомпетентностью, такой как непонимание базовой терминологии языков, с которыми вы работаете (если я говорю, что вам нужно наследовать интерфейс, вы должны знать, что это значит), непонимание базовой логики ( например, проверка числа на значение больше 10, а затем внутри этого блока проверка числа на значение меньше 5), что-то в этом роде.

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

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

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

Ни одна из описанных вами проблем не кажется необычной для большой кодовой базы. Я не понимаю, о чем вы здесь спрашиваете, кроме «Как я могу улучшить свою команду?» Это довольно широкий вопрос, на который нет конкретного ответа. Решения могут варьироваться от ужесточения практики найма до формальных/неформальных программ обучения. Однако я думаю, что превосходство продвигается НЕ путем простого выявления и устранения некомпетентности, а путем предоставления примеров передового опыта.
Почему вам не нравятся обзоры кода?

Ответы (5)

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

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

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

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

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

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

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

Лучшее, что вы можете сделать, это попытаться им помочь. Покажите им путь, делая такие вещи, как проверка кода, которая вам не нравится, с положительным эффектом. Просто помните, "некоторые мужчины, до которых вы просто не можете достучаться..."

Черт возьми, нет, я очень гибкий и могу применять методы, которые я изучаю. Вот почему я спросил. На самом деле я программирую уже 30 лет, и ничего из того, что я использовал тогда, не используется до сих пор. Я могу адаптироваться. Мне нравится этот ответ.
@Jasmine: вы можете найти следующее .. поучительное: thecodelesscode.com/case/142?topic=code+reviews
«Это не болтовня». Этот. Точно так же журналисты не говорят: «Нет, мы не вычитываем и не редактируем статьи в нашей организации, потому что исправление опечаток или подтяжка текста только ранят чувства». Ну, не должно. Быть исправленным или улучшенным — это часть твоей чертовой работы, каждому нужно научиться это делать :-)
На моем рабочем месте мы используем непубличные обзоры кода, и мы требуем их для любого кода, который отправляется в наш репозиторий. Вы можете подумать о чем-то подобном, так как это позволит избежать публичного смущения, а также улучшит качество кода.

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

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

Обед и учиться? Нет, спасибо - формальное обучение и тренинги должны быть в часы компании, а не мои (хотя я не против читать и бездельничать в свободное время). Кроме того, во многих юрисдикциях вы не можете заменить перерыв обучением.
@HorusKol: Кто сказал, что Lunch and Learn не входит в расписание компании?
Внедрение политики нулевых предупреждений поможет решить некоторые из этих проблем.
@ Эрик, время обеда никогда не бывает на часах компании. Обидно просить людей жертвовать своим личным временем на тренировки.
Нет ничего «оскорбительного» в том, чтобы время от времени пообедать и поучиться, если только вы не работаете на ужасном рабочем месте, где каждая секунда «в нерабочее время» приносит облегчение.
"обед" - это то, что вы едите. «перерыв на обед» — это когда вы ненадолго прекращаете работу. Конечно, их смешивают, потому что первое составляет большую часть цели второго. Теперь, конечно, большинство компаний, которые вводят «обедай и учись», не ожидают, что сотрудники покинут помещение на час сразу после окончания сеанса. Но тем немногим, кто реализует предложение Эрика о том, что «обед и учеба» может быть в часах компании, это хорошо, их сотрудники не должны выбирать между учебой и тем, что они делают в свой перерыв (сходить в банк, сделать что-то еще). ).

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

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

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

Простите за разглагольствование

Кто-нибудь еще может выдержать критику? Они действительно думают, что они идеальны? Компании разоряются из-за некомпетентности. Школа окончена. Пора людям взрослеть и делать свою работу.

Это мое ощущение по этому поводу время от времени. Что меня больше всего раздражает в некомпетентных людях, так это то, что у них вообще есть работа.
@Jasmine - в чем-то я согласен, но я думаю, что компаниям нужно перестать жаловаться на то, что они не могут найти высококвалифицированных людей и начать их обучение. Получение степени CS не является языковой сертификацией, и это также не подготовит вас в достаточной степени.
Да, я согласен, многие из некомпетентных людей за эти годы получили ученые степени или сертификаты. Прохождение тестов и решение реальных задач — разные вещи. И да, я согласен, что способ справиться с этим - это обучение.

Я хочу помочь людям стать лучше, а не заставить их уволиться.

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

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

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

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

Здесь есть две возможности. Вы (и ваш руководитель/коллеги) не очень хорошие учителя. Бывает. Не во всех проблемах с обучением виноваты ученики.

Но альтернативой является то, что проблемный сотрудник не может или не хочет учиться. Для инженера-программиста это огромная (и, к сожалению, распространенная) проблема. Мало того, что они мертвым грузом из-за плохой работы, они тянут вниз всех пограничных членов команды, которые смотрят на такую ​​неприемлемую работу и думают: «Если Боб может это сделать, то и я тоже смогу». Вы не должны чувствовать себя ужасно, когда этих людей увольняют. Вы должны злиться из-за того, что они останутся на работе, где активно вредят своей команде.

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

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

Напишите стиль кодирования и руководство по разработке и попросите всех подписаться.

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

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