Быть инженером-программистом — это больше, чем просто писать код. Кое-что, чему я научился и о чем продолжаю вспоминать в течение своей карьеры. Я давно думал, что в индустрии программного обеспечения мой рейтинг инженера основан исключительно на моей технической проницательности, способности создавать качественный код и опыте решения сложных проблем с программным обеспечением. Хотя это может быть правдой, зачастую именно нетехнические навыки отличают хороших инженеров от великих. Вот некоторые из уроков, которые я усвоил, и шаги, которые я предпринял для повышения уровня:
Быть инженером-программистом — это больше, чем просто писать код.
1. Будь дураком
Часто я молчу на совещаниях по дизайну. Кажется, мне трудно говорить. Со временем я понял, что один из самых больших моих недостатков — боязнь ошибиться, показаться дураком перед сверстниками. Этот менталитет, вероятно, является продуктом моего культурного воспитания, воспитания, которое проповедует сначала думать, а потом говорить.
«Лучше промолчать и прослыть дураком, чем заговорить и рассеять все сомнения».
- Абрахам Линкольн
В разговорах я до сих пор верю в это понятие. Однако во время мозговых штурмов, таких как встречи по дизайну, мои мысли могут быть менее размытыми, когда я говорю это с пользой. Лучшие проекты получаются из итеративного построения несовершенных идей. Поэтому я должен «быть дураком», предлагая несовершенные идеи, а затем определять недостатки этих идей. Моя команда сможет опираться на него, устраняя различные недостатки. В худшем случае мои идеи игнорируются. Даже тогда я уйду, узнав, почему это не сработает.
Мои мысли могут быть менее бурными, когда я говорю это с пользой.
Кроме того, я часто избегаю задавать вопросы, потому что это выставляет меня неосведомленным. Тем не менее, задавать вопросы — самый эффективный способ заполнить пробелы в моих знаниях. Задавая вопросы, я могу точно определить, чего я не понимаю, и получить ответы, которые мне нужны, чтобы преодолеть этот пробел.
Задавать вопросы — самый эффективный способ заполнить пробелы в моих знаниях.
Я стал лучшим инженером, когда начал говорить и задавать вопросы, рискуя показаться дураком. Я больше участвовал в дискуссиях о дизайне, и у меня было более глубокое понимание нашего продукта. Мне было легче совершать ошибки, потому что у меня была поддерживающая командная среда, которая поощряла вопросы и разные точки зрения.
2. Разговаривайте на тему «Да, и…»
«Да, и…» — правило импровизационной комедии. По сути, комик должен принять точку зрения другого комика («Да») и расширить тему («и…»). Это позволяет комикам продолжать течение сцены. Это также мощная техника в разговоре. Техника «Да, и…» требует, чтобы мы внимательно слушали то, что кто-то хочет сказать, и сопереживали говорящему, чтобы действительно понять его или ее точку зрения.
У меня личность типа А, и часто я сосредотачиваюсь на подготовке того, что хочу сказать дальше, вместо того, чтобы слушать, что говорят в данный момент. Я понял, что у меня были более эффективные разговоры, когда я заставлял себя больше говорить «Да, и». Разговор «Да, и» требует, чтобы я пытался полностью понять, прежде чем отвечать.
Следовать линии мышления немного сложнее. Как инженер, я научился подвергать сомнению все, с чем сталкиваюсь, и не зря! Однако я часто забываю сопереживать своим товарищам по команде. Прежде чем выдвигать встречный аргумент, важно признать приоритеты вашего товарища по команде. Это убеждает вашего товарища по команде в том, что его или ее идеи не были проигнорированы, и подтверждает, что вы согласны с тем, что решение направлено на решение. Это не значит, что я должен соглашаться со всем, что кто-то говорит. Это просто означает, что я прилагаю больше усилий, чтобы оценить их точку зрения, прежде чем возражать.
Прежде чем выдвигать встречный аргумент, важно признать приоритеты вашего товарища по команде.
Программная инженерия — это дисциплина компромиссов. Нет правильного или неправильного способа сделать что-то. Мы идем на ряд компромиссов, чтобы продвигать свои интересы. Принимая дизайнерские решения, лучше попытаться понять, что предлагает наш товарищ по команде. На какие компромиссы он или она идет? Каковы его или ее приоритеты?
На практике это может выглядеть так:
Боб: «Мы не должны использовать React, потому что он сильно отличается от того, к чему мы привыкли. Потребуется много времени, чтобы подняться».
Дженни: «Да, я понимаю, откуда вы пришли, и React все еще относительно нов. И мы также можем столкнуться с ошибками, которые сообщество еще не решило. Тем не менее, у него есть сильные поклонники, и нам будет легче найти таланты, которые нам помогут. Также кажется, что несколько крупных компаний используют React в производственной среде, что делает его более удобным для нас».
«Да, и…» позволяет мне эффективно слушать и сопереживать. Это заставляет меня понимать различные компромиссы каждого решения. Это дает мне возможность рассеять любое недопонимание и свести к минимуму риск того, что товарищ по команде будет сбит с толку. Кроме того, это держит мой разум открытым для поглощения нового материала.
3. Примите установку на рост
Это важная черта, которая делает нас актуальными и постоянно ценными. Технологии развиваются с головокружительной скоростью. Великий инженер не просто полагается на прошлый опыт, но сохраняет непредубежденность и тратит время на изучение новых способов решения проблем. Кроме того, мы должны вытолкнуть себя из зоны комфорта и стремиться каждый день немного совершенствоваться как в технических, так и в нетехнических аспектах. Нам так повезло, что мы являемся отраслью, в которой богатство знаний для улучшения нашей торговли находится буквально у нас под рукой.
Есть много способов продолжать расти. Вот некоторые из вещей, которые я делаю:
- Читайте о новых фреймворках и методологиях
- Участие в проектах с открытым исходным кодом
- Задавайте вопросы в сообществах программистов
- Пишите в блогах о том, что я узнаю
- Наставник других инженеров
- Посещайте встречи тамастов
- Работа над сторонними проектами с использованием разных языков и фреймворков
Чем больше я рос, тем больше навыков и инструментов я мог применять для решения бизнес-задач и тем более ценным я становился для своей команды.
Примечание: Google использует правило 20%, согласно которому инженерам рекомендуется тратить 20% своего рабочего времени на инновации и разработку проектов по своему выбору. Популярные продукты, такие как Gmail, Google News и AdSense, являются результатом этого правила 20%.
4. Будьте отзывчивым товарищем по команде
Быть отзывчивым товарищем по команде является частью должностной инструкции. Признаюсь, мне тоже было трудно вспомнить этот факт. Мы советники и хранители нашего домена. Частью нашей работы является поддержка других отделов, ответы на вопросы и принятие решений о продукте на основе наших технических знаний. Быть лучшим инженером-программистом означает быть внимательным к вопросам и опасениям, которые возникают у разных заинтересованных сторон в отношении нашего продукта.
Частью нашей работы является поддержка других отделов, ответы на вопросы и принятие решений о продукте на основе наших технических знаний.
Я попал в распространенную ловушку, когда изолировал себя на долгие периоды времени, пока сосредотачивался на написании кода, но тем самым пренебрегал значительной частью своей работы. Ключ в том, чтобы сбалансировать изолированное время кодирования и совместное время. В дополнение к непрерывному времени написания кода я стараюсь быть доступным для других членов команды. Чтобы обозначить, что я в зоне, я надеваю наушники, даже если музыка не играет. Я снимаю наушники в тот период времени, когда я приветствую прерывание. Я пытаюсь установить соглашение об уровне обслуживания для ответа на запросы. На электронные письма обычно отвечают в течение часа. На прямые сообщения обычно отвечают в течение получаса, если только это не срочно.
Мы товарищи по команде, прежде чем мы инженеры, и мы должны стремиться помочь нашим товарищам по команде добиться успеха.
5. Ведите список приоритетов
Один из лучших инструментов, который я использую для повышения своей продуктивности, — это список приоритетов. Список приоритетов гарантирует, что я работаю над самой важной задачей, и помогает мне сосредоточиться на выполнении этой единственной задачи. Как определить, над какой задачей работать важнее всего? Я измеряю приоритеты своих задач с помощью показателя The Effective Engineer», который называется рычаг.
Кредитное плечо = произведенное воздействие / затраченное время
— Эдмонд Лау
Кредитное плечо — это результат произведенного воздействия, разделенный на вложенное время. Эффективный инженер стремится работать над задачами, требующими больших усилий. Я могу максимизировать эффективность своей задачи, увеличив производимое воздействие или сократив затраченное время. Поскольку встречи обычно оказывают незначительное воздействие, я могу сократить время, которое я нахожусь на встречах, чтобы повысить эффективность воздействия. Я стараюсь разрабатывать итеративно, потому что чем больше времени я трачу на создание функции, тем ниже ее эффективность.
При планировании проекта я пытаюсь понять проблему, которую призван решить функционал. Какую ценность приносит эта функция по сравнению с тем, сколько времени нам придется инвестировать в нее сейчас? Будет ли эта функция иметь больше преимуществ, если мы реализуем ее позже, когда это займет меньше времени?
Часто требования бизнеса меняются. Задача, которая раньше имела высокий рычаг, теперь имеет низкий рычаг. Таким образом, я должен регулярно оценивать и обновлять свои приоритеты.
Соблюдая список приоритетов, я обнаружил, что могу принести больше пользы для бизнеса.
6. Найдите способы оценить мою работу
Определение показателя успеха и поиск способов его измерения важны во многих отношениях. Во-первых, это позволяет мне поддерживать или опровергать влияние наших задач. Без ощутимого измерения произведенного воздействия и времени, затраченного на задачу, трудно оценить эффективность задачи. Во-вторых, это четкий показатель моей ценности для команды и бизнеса. Моя ценность как участника может быть поддержана, что приведет к будущей возможности для продвижения. Наконец, он показывает области, где мне не хватает. Например, я обнаружил, что выполнил X задач по исправлению критических ошибок, но в значительной степени пренебрег своими другими навыками в разработке ценных функций. Я могу взять на себя больше функций с высокой эффективностью, чтобы сбалансировать свою рабочую нагрузку и убедиться, что все мои навыки используются. Измерение моей работы служит личным табелем успеваемости.
7. Убедитесь, что это работает
В начале своей карьеры я имел возможность работать с замечательной командой QA. Команда протестировала все варианты использования моего кода и часто сообщала мне о найденных проблемах. Только когда я ушел с этой должности, я действительно понял важность ответственности за свою работу. Не имея преданных членов команды QA, я научился пуленепробиваемой своей работе. Я написал тесты, их много. Модульные тесты. Интеграционные тесты. Регрессионные тесты. Очень важно убедиться, что мои функции работают, продолжают работать, а если они сломаются, я буду первым, кто получит уведомление.
Очень важно убедиться, что мои функции работают, продолжают работать, а если они сломаются, я буду первым, кто получит уведомление.
Найдите способы мониторинга функций. Стремитесь получать сообщения об ошибках до того, как они станут проблемой. Создайте систему уведомлений, когда в производственной среде возникает ошибка. Создайте службу опроса для опроса работоспособности вашей службы. Отслеживайте трафик вашей функции и выявляйте узкие места. Чем раньше проблемы будут обнаружены, тем больше шансов, что их удастся решить до того, как они окажут реальное влияние на итоговую прибыль.
8. Станьте эффективными с помощью своих инструментов
Найдите способы оптимизировать то, как мы работаем, и это принесет дивиденды в виде нашей продукции. Если мы хотим быть лучшими плотниками, мы должны хорошо обращаться с молотком. Улучшение работы с имеющимися у нас инструментами сделает нас более эффективными.
Например, я переключился на VI, потому что обнаружил, что могу делать большинство вещей, которые я бы сделал в процессе написания файла, не отрывая руки от исходного ряда. Я создал псевдонимы Shell, чтобы свести к минимуму количество символов, которые мне приходилось вводить для выполнения обычных команд. Я непредвзято относился к использованию различных инструментов для визуализации моего кода. Постоянно находя способы повысить эффективность своих инструментов, я могу быстрее создавать новые функции.
CI для постоянного улучшения
Что делает программную инженерию такой увлекательной дисциплиной, так это количество времени и усилий, необходимых для того, чтобы оставаться актуальным. Не так много профессий предлагают нам преимущество, заставляющее нас совершенствоваться каждый день. Вот несколько способов, которые я нашел, чтобы улучшить свою работу и стать лучшим товарищем по команде. Я надеюсь, что в какой-то степени это может помочь и вам!
