В самом начале своей карьеры я много времени проводил в офисе.

Я был не только непродуктивным. Я также был недоволен качеством своей продукции. И постепенно это сказалось и на здоровье.

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

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

Вот 3 моих вывода из путешествия.

# 1: Делайте дерьмовые вещи:

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

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

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

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

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

Это считалось вполне естественным.

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

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

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

Я не могу понять это правильно.

В любом случае, позвольте мне написать эти 50 шагов и позволить Бобу все испортить. Тогда я могу его винить.

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

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

Тем не менее, если это навредило чьей-то работе, просто извинитесь, исправьте и двигайтесь дальше.

Дерьмовые штучки - прекрасные препятствия в команде.

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

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

# 2: Подождите ():

Что делает машина при вызове wait () (или его эквивалента sleep ())?

Если вы сказали «Ничего», вы ошиблись.

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

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

Великий программист ждет, и его wait () умнее того, что я описал выше.

Даже когда в его голове появляется сигнал, он просто решает не реагировать на него. Основываясь на тщательно определенном флаге, он решает сохранить его для дальнейшей обработки.

Во время ожидания он обдумывает требования со всех сторон. Он читает каждую строчку по 5 раз. Он также читает между строк и разъясняет всем заинтересованным сторонам.

Он задает вопросы снова и снова.

Он спрашивает и ставит под сомнение требования к заинтересованным сторонам бизнеса - это право собственности.

Он спрашивает архитекторов и старших разработчиков о своих дизайнерских решениях - без стеснения спрашивает: «Как я могу сделать лучше».

Он спрашивает фронтенд-разработчиков о UI / UX. Он спрашивает администраторов баз данных и DevOps об эффективных развертываниях. Он спрашивает серверных разработчиков о дизайне API. Это командная работа.

Он даже спрашивает младших программистов о крайних случаях - никакого статус-кво.

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

Наверняка он доставляет 100% рабочий код за день-два, максимум. Вы ведь помните, что мы говорим о великом программисте?

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

Только стойкий разработчик может ждать плодотворно.

# 3: Обеспечить соблюдение расписания (встречи):

Многим это может показаться бунтарским. И это, безусловно, относится к отрасли, попавшей в гигантскую паутину под названием Agile Scrum.

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

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

Их рассуждения таковы:

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

Скрам усугубляет эту проблему, создавая несовместимые календари:

Понедельник: 13:00 (давайте немного опоздаем из выходного настроения!)

Вторник: 11:00 (давайте до обеда объединимся, а там продолжим!)

Среда: 9 утра (наша обычная схватка, обычная только в среду!)

Четверг: 14:00 (совещание по обзору функций, заказ на поставку рано).

Пятница: 15:00 (давайте посмотрим, что происходит, прежде чем отправиться домой!)

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

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

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

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

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

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

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

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

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

С этим я полностью согласен.

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

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

Все кодеры сделали это:

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

Если бы вообще не было встречи, он бы закончил за 15 минут, в 90% случаев! И с этим воодушевлением он заканчивал еще 3 функции в тот же день, включая тестирование.

Если вы не уверены, попробуйте сделать это в своей команде:

Сверните окно встречи. Сложите их вместе, как этих кошек в корзине.

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

Моим идеальным графиком было бы проводить все собрания в один день (пятница) / два последовательных дня (четверг + пятница) и разрешать программирование в течение остальной части недели.

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

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

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

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

Заключение:

Стремясь доказать свою компетентность, многие хорошие программисты в конечном итоге разрушают свою карьеру.

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

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

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

  • Перестаньте цепляться за свою карьеру программиста. Перестаньте воспринимать это как должное как работу для выхода на пенсию в 60 лет.
  • Сохраняйте непредвзятость. Не торопитесь. Оценивайте и при необходимости отклоняйтесь.
  • Любой ценой не теряйте своих близких и друзей.

Мир быстро меняется, и никто не будет винить вас, если вы тоже это сделаете. Просто делайте это для себя, а не для кого-то еще.

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