«Лень — моя суперсила»: 5 качеств идеального Software Engineer

— Я — Software Engineer до мозга кости, — представляется Виталий, — В профессии уже почти 23 года. Большую часть времени работал инженером, а последние лет пять являюсь Delivery Manager и Product Owner. Сейчас вместе с коллегами мы создаем продукт в рамках инициативы EngX. Продолжаю программировать, пишу код.

Кто такой Software Engineer

— Кто такой Software Engineer сегодня? Это тот, кто занимается инженерной деятельностью в нашей отрасли, а именно созданием и поддержкой функционирования программного обеспечения. Бизнес-аналитики, разработчики, тестировщики, DevOps — все, кого вы можете увидеть на командном митинге, все Software Engineers с разной специализацией, — рассказывает Виталий, — У современного инженера должно быть развито одновременно инженерное мышление (Engineering Thinking) и agile мышление (Agile Thinking). Мы работаем с быстроменяющимися технологиями, сложными бизнес-процессами и разнообразными способами взаимодействия, поэтому agile мышление нужно нам для того, чтобы быть эффективными в работе, а инженерное — чтобы быть результативным.

Есть два термина, которые, как я считаю, многие неправильно переводят и воспринимают. Это Agile и Full Stack Developer.

Agile

— На самом деле, Agile переводится как «проворный», а не «гибкий» (Flexible). Agile — это про адаптацию к постоянно изменяющимся внешним и внутренним условиям. Я могу себе представить ментальную ошибку переводчика, который перевел Agile Methodology как Гибкая Методология. Слово «гибкий» ассоциируется с изменением формы и податливостью, то есть с адаптацией через изменение своего внутреннего состояния под внешние условия. В то время как слово «проворный» ассоциируется со скоростью и направлением движения, с адаптацией через реакцию на внешние условия, через изменение скорости и направления своего движения. И слово «проворный» гораздо больше соответствует понятию Agile и тому, что от него ждет бизнес. Нам, инженерам, не нужно изворачиваться и прогибаться лишь с той целью, чтобы продолжать двигаться вперед, как было запланировано или специфицировано месяц или годы назад. Наша задача быть собранными и готовыми в любой момент изменить направление и скорость движения, чтобы соответствовать новым требованиям рынка, где работает наше программное обеспечение. А это значит у нас не должно быть лишнего «жира и хвостов», что мешает нам быть проворными. Я имею в виду технический долг, плохое качество кода, отсутствие юнит тестов и т. п.

Full-Stack Developer

— А вот Full-Stack Developer’ом у нас принято считать разработчика, который может и Back-End, и Front-End. Заказчики же Full-Stack понимают, как полный цикл разработки: от сбора требований до релиза. То есть разработчик должен знать и уметь:

1. Собирать и прояснять требования и принимать активное участие в этом процессе, взаимодействовать с бизнес-аналитиком;
2. Взаимодействовать с UX дизайнером, чтобы понимать UX и реализовать его в соответствии с задумкой;
3. Разбираться в архитектуре приложения и следовать код стандартам, что было заложено архитектором;
4. Писать и ревьюить код, чтобы он соответствовать архитектуре и стандартам качества, принятым на проекте, работать в парах с другими разработчиками, чтобы снизить количество ошибок, а соответственно и общее время разработки приложения;
5. Тестировать свой код и то, как он интегрируется в приложение, создавать юнит и авто тесты, активно взаимодействовать с командой тестирования;
6. Создавать билд-скрипты и взаимодействовать с DevOps при развертывании приложения.

— Работа Software Engineer сделана тогда, когда приложение попадет в продакшен, работает там без ошибок и приносит пользу конечному потребителю. Full-Stack Developer — это Software Engineer, который делает все от начала и до конца — от требований до поставки. Он участвует на всех этапах процесса создания программного обеспечения, — подытоживает Виталий.

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

Какими качествами должен обладать Software Engineer

— Мы в инициативе EngX (Engineering Excellence) долго думали, какими качествами должен обладать идеальный Software Engineer и пришли к следующим выводам.

Инженеры должны:

1. Быть любознательными.
   Это значит смотреть на мир вокруг себя, не замыкаться, не оставаться в каком-то ограниченном потоке, интересоваться, участвовать в различных активностях помимо проекта, ходить на разные хакатоны, митапы по новым технологиям. Хакатоны в данном случае лучше, на них можно попрактиковаться в написании кода.
2. Обладать чувством меры.
   Любопытный человек может зациклиться в абстрактных вещах и углубиться в чрезмерное улучшение. Инженеру очень важно не абстрагироваться от продукта и внешнего мира. Нужно думать о конечных пользователях, о том, какой в итоге продукт получается и как скоро они его получат. Далеко не все задачи можно сделать абстрактно, да и не нужно. Профессия разработчика — это не просто писать код и загружать тестировщиков работой. Забота о результате, осознание своего вклада в мир — вот какими принципами должен руководствоваться инженер. Инженер взаимодействует с остальной командой, чтобы его изменения были интегрированы в общую систему и работали как надо, точно в срок.
   Точно в срок – это значит делать то, что необходимо и достаточно, чтобы удовлетворить требование, и чтобы остальные участники команды так же успели выполнить свою работу над этим же требованием. Но не забываем про качество кода, которое очень сильно влияет на будущую «точно в срок» разработку. И раннее выявление багов, чем раньше мы выявим проблему, тем меньше времени на ее решение будет потрачено, внимательно читаем спецификацию и указываем на ошибки в ней.
3. Уметь работать в команде.
   Джуниоры часто не могут попасть на работу в большие компании именно потому, что у них нет опыта работы в команде. В таких компаниях никто не работает в одиночку, все делается командой. И самое печальное, что большинство онлайн курсов и менторских программ не предоставляют такого опыта. В большинстве своем они направлены на индивидуальную работу, индивидуальное изучение материала и индивидуальную практику в написании кода. Знаний о том, как собрать требования, как сделать дизайн приложения, как его протестировать, как его установить на сервер или же каким-либо другим образом создать дистрибутив — не дают. А этого очень не хватает, и это нужно где-то брать. Конечно, специалистов можно обучать, но обучение усложняется тем, что неизбежно будет много ошибок, проект может затянуться, а это риски. Плюс нужно найти человека, который будет рассказывать и показывать, как правильно делать, а это ресурс. Хорошо, если такой человек есть. Тогда джуниоры и даже мидлы достаточно быстро вольются в работу и начнут справляться. Но чаще всего это не так.
   У меня в EPAM был опыт создания project-лаборатории, в рамках которой я собрал студентов-джуниоров в две команды, и мы делали два небольших проекта. Я выступал в роли Product Owner и ментора, обучал их как команду, которая производит полный цикл разработки. Я показал им, что работа над проектом не связана просто с написанием кода, а связана со многими вещами: проработкой требований, тестированием, разворачиванием. После трех месяцев работы над проектами ребята сказали, что получили хороший опыт и у них осталось понимание, как им работать в команде.
4. Быть ленивым.
   Вы наверняка слышали выражение «Лень – двигатель прогресса». Это именно так. Я называю ее своей суперсилой. Это, конечно, не значит, что я ничего не делаю. Лень должна быть такой, чтобы, прилагая минимум усилий, получать максимальный результат. Например, есть какой-то рутинное действие. Ок, я его сделаю один раз, но следующий раз я придумаю какой-то простой способ, чтобы это действие у меня отнимало меньше времени и сил. Если делать все каждый раз в лоб — когда тебе дали задачу, ты сразу пошел ее делать — это нехорошо. Нужно подумать, «полениться» делать сразу, найти простое красивое решение, которое принесет больше пользы и займет меньше времени и усилий при реализации. В общем, инженер должен больше думать — меньше делать.
5. И не тормозить.
   Эта характеристика немного конфликтует с предыдущим свойством. На западе есть такое выражение — fast try — fast fail. Это значит, что лучше быстрее попробовать что-то сделать, убедиться в том, что это не работает, и отказаться от затеи. Нам сложно это принять. Нас учили не ошибаться. Но на самом деле ошибки — это приемлемо, на ошибках люди учатся. Если бояться ошибаться, то мы долго будем думать, выверять и все равно не избежим падения.

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

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

Что почитать?

— И напоследок мой топ-5 книг хорошего инженера:

1. Роберт Мартин: Чистый код. Создание, анализ и рефакторинг («чистый код всегда выглядит так, как будто его написал тот, кому не все равно» Р. Мартин);
2. Стив Макконнелл: Совершенный код («сложный код является признаком того, что вы недостаточно хорошо понимаете свою программу, чтобы сделать ее простой» С. Макконнелл);
3. Роберт Мартин: Идеальный программист. Как стать профессионалом разработки ПО (мое личное мнение, нельзя стать идеальным, можно только быть, сначала нужно быть идеальным джуном, потом идеальным инженером и т. д.);
4. Элияху Голдратт: Цель. Процесс непрерывного совершенствования (чтобы понимать мотивацию менеджеров и помогать им находить узкие места в создании программного обеспечения);
5. Егор Бугаенко: Элегантные объекты (нестандартное прочтение принципов Объектно-Ориентированного Программирования, мне очень нравится).

Хотите поговорить об инженерной культуре? Приглашаем в Discord Anywhere Club.