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

  • уроки, которые вы усвоили в процессе
  • ваша точка зрения
  • ваш подход

Эти три вещи делают опытных инженеров такими желанными. Все мы слышали поговорку: «Если у вас есть только молоток, все будет похоже на гвоздь». Та же логика применима к работе инженера.

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

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

Установите шаблоны

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

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

Прежде чем мы объясним это дальше, давайте рассмотрим пример из реальной жизни:

«У меня проблемы с запуском кода на моем ноутбуке / рабочей станции, потому что X не установлен или не нужная версия».

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

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

«Здравый смысл» - установить или обновить все, что вызывает ошибку, верно?

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

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

Вы можете создать образ runner или docker, который будет автоматически устанавливать все ваши зависимости / инструменты / скрипты и т. Д. Каждый раз, когда вы запускаете контейнер, вы получаете единообразный опыт. Если ваш коллега добавит новую зависимость, она будет установлена ​​автоматически. Если вы нанимаете нового инженера, он может загрузить контейнер и сразу же начать добавлять ценность. Мы даже не упомянули тот факт, что код может работать по-разному в зависимости от вашей ОС. С контейнером все используют одну и ту же ОС. Если этот контейнер является приложением, это также означает, что все разрабатывают один и тот же образ, который в конечном итоге будет работать в производственной среде!

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

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

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

Стоит отметить, что сборка раннера займет несколько часов по сравнению с 5-минутным исправлением, но:

  • Подумайте о том, сколько времени вы сэкономили, никогда больше не сталкиваясь с этой проблемой
  • Вспомните все время, когда вы спасали своих коллег
  • Подумайте, как легко стало просто добавлять новые инструменты для вас и всей команды.
  • Учтите, что контейнер также можно использовать как часть вашего конвейера CI / CD для запуска тестов или выполнения всего, что вы хотите.
  • Наконец, помните, что переключение контекста стоит дорого. Это 5 минут исправления каждый раз, а затем еще 30 минут, чтобы вернуться к правильному мышлению до того, как вас прервали.

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

Не бойтесь использовать правильный инструмент для правильной работы.

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

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

  • шлем
  • рулевой
  • дрон
  • терраформа
  • скрипты Python
  • Голанг
  • пользовательские образы докеров
  • так далее…

Разные инструменты подходят для разных целей, и их можно использовать. Теперь я хочу прояснить, что мы делаем и НЕ делаем.

Мы:

  • Использование лучшего инструмента для решения поставленной задачи
  • Постоянное использование одного и того же инструмента для одной и той же работы
  • Использование дополнительных инструментов (которые позволяют полностью автоматизировать работу)
  • Использование инструментов с декларативными языками, где конфигурация может быть определена в коде (который версируется и проверяется коллегами)
  • Использование идемпотентных инструментов / скриптов

Мы не:

Весь этот раздел предназначен только для того, чтобы выделить «Последовательное использование одного и того же инструмента для одной и той же работы». Допускаются дополнительные инструменты, но не конкурирующие инструменты (например, формирование облака или терраформирование).

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

Если мы решим использовать Terraform для развертывания нашей инфраструктуры, это будет единственный инструмент, который мы используем для инфраструктуры, без формирования облака, без ручного развертывания, ничего !!! Как только мы решим развернуть пакеты Kubernetes с помощью helm, вы не обнаружите, что мы развертываем что-либо с чистым YAML.

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

Дополнение:

Пользовательские инструменты и скрипты - создание собственных инструментов на 100% нормально. Однако, прежде чем принимать это решение, вы должны сначала проверить, сделал ли это кто-то или какая-то компания. О настраиваемых инструментах и ​​скриптах всегда говорят в очень романтичных терминах. «О, я могу заставить его делать все, что хочу, как хочу, когда хочу». Хотя это утверждение очень верно, создание чего-либо с нуля также очень сложное и сопряжено с накладными расходами, которых у вас нет при использовании инструмента, поддерживаемого сообществом или компанией. Эта проблема только усиливается для каждого настраиваемого инструмента, который вы создаете / поддерживаете.

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

Все автоматизировать

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

Пример из реальной жизни: «Каждый раз, когда я открываю учетную запись AWS, я должен искать идентификаторы AMI, которые мне нужны для подготовки моей инфраструктуры».

Эта задача довольно проста и понятна, но выполняется вручную:

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

Инженер, с которым я работал, столкнулся с этой проблемой и сказал: «Я больше не хочу этим заниматься». Они создали ресурс данных в Terraform, который будет автоматически искать AMI. Более того, нам не нужно искать AMI, и вместо этого мы смогли сосредоточиться на более серьезных проблемах.

Продолжает расти

Если вы какое-то время были в технической сфере, вы знаете, что она постоянно меняется. Пределы постоянно нарушаются. Языки приходят и уходят или изобретаются заново. Несколько лет назад Kubernetes и Docker не были чем-то особенным, но теперь они повсюду. С их принятием также появилось множество инструментов и приложений. Как и технологии, вы также должны продолжать развиваться. Это означает несколько вещей:

  • Никогда не прекращайте читать статьи, посещать конференции или учиться
  • Не спорьте, думая: «Я старший инженер» или «Я прав». На самом деле выслушайте аргумент, и, если ваш подход оказался не лучшим, извлеките из него урок. Даже если вы в конце концов «правы», у вас все равно будет возможность помочь кому-то вырасти.
  • Периодически просматривайте старые проекты и ищите, где можно было бы сделать лучше.
  • Установите POC новых инструментов и языков и протестируйте их. Даже если окажется, что ваши текущие языки / инструменты лучше, вы все равно сможете сформулировать, почему они лучше, вместо того, чтобы говорить: «Это то, что мы всегда использовали».
  • Не бойтесь меняться, потому что «Мы всегда так поступали». По-прежнему учитывайте рентабельность инвестиций, но если изменение имеет смысл, сделайте это.

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

Заключение

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

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

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