По словам бывшего инженера Google и стартапа Эдмонда Лау

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

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

Главный фактор, который должен всегда оставаться в глубине души

Влияние. Влияние. Влияние.

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

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

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

1. Создайте свою собственную историю

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

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

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

Проверка реальности: Вселенная ничего тебе не должна.

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

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

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

2. Инвестируйте в свою скорость итерации

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

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

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

«Я нашел людей, которые добились успеха, почти все они написали множество инструментов». - Бобби Джонсон, бывший технический директор в Facebook

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

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

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

Хорошее практическое правило от бывшего вице-президента по техническим вопросам в Twitter Раффи Крикориана:

«Если вам нужно вручную построить что-то более двух раз, напишите инструмент в третий раз».

3. Проверяйте свои идеи агрессивно и итеративно.

Быстро спросите себя:

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

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

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

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

Фиаско с бесконечной прокруткой Etsy - отличный тому пример. Etsy хотела добавить функцию бесконечной прокрутки на свои страницы продуктов и избавиться от ее текущей функции разбивки на страницы, чтобы пользователи имели более «плавный» опыт. Они предположили, что то, что они создавали, вызовет ту отдачу, на которую они надеялись, без подтверждения своей идеи вплоть до даты развертывания, через несколько месяцев после того, как в нее был вложен огромный объем работы. Это.

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

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

Это работает, потому что, экспериментируя с разными вещами, проводя A / B-тесты и глубоко оценивая каждую экспериментальную гипотезу, вы можете получить большую уверенность в том, что работает, а что нет. Когда вы запускаете тест, который работает, он дает вам больше уверенности в том, что любой путь, по которому вы идете, на самом деле является правильным и наиболее ценным.

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

Как сказал Лау, всегда спрашивайте себя:

«Как вы можете потратить 10% своих усилий на то, чтобы убедиться, что ваш проект будет работать?»

4. Свести к минимуму операционную нагрузку

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

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

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

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

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

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

Сделайте вещи простыми и уберите эти потенциальные уровни сложности.

5. Сформируйте отличную инженерную культуру

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

Ну и да, и нет.

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

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

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

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

В конце концов, счастливый инженер - продуктивный человек.

Расставание

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

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

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