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

Десять лет назад я написал свои первые строки продакшн-кода для сайтов небольшого бизнеса в Тбилиси. С тех пор я строил платформы, которыми пользуются сотни тысяч человек, в структурах Министерства здравоохранения, участвовал в разработке крупнейших онлайн-маркетплейсов Грузии, работал в международных распределённых командах — а сегодня переписываю банковскую платформу рассрочки в должности Senior Software Developer в Credo Bank.

Где-то по пути технологии сменились полностью. .NET Framework стал .NET Core. Серверный рендеринг уступил место SPA, а потом частично вернулся. Команды, которые раньше сидели в одной комнате, оказались разбросаны по континентам. И всё же, оглядываясь назад, я понимаю: самое важное, чему я научился, почти не связано с конкретными фреймворками.

Вот уроки, которые остались.

1. Технологии меняются. Фундамент — нет.

Когда я начинал, я постоянно переживал, что учу «не тот» стек. С тех пор я успел поработать с ASP.NET MVC, .NET Core, Web API, Blazor, Vue.js и полудюжиной баз данных — и каждый из этих инструментов за мою карьеру был переработан или заменён более новой версией.

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

2. База данных — это место, где проект живёт или умирает.

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

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

3. Скучные технологии — это преимущество, а не слабость.

В начале карьеры мне хотелось использовать в каждом проекте самые новые инструменты. Потом я наблюдал, как системы на «скучных» технологиях — SQL Server, обычный ASP.NET, прямолинейная архитектура — спокойно работают годами, пока более модные проекты рушатся под собственной сложностью.

Банки и государственные учреждения выбирают зрелые технологии не просто так. Когда от платформы зависят 300 000 человек, «захватывающе» — это не комплимент. Теперь, оценивая инструмент, я задаю первым вопросом не «современный ли он?», а «сможет ли это поддерживать тот, кому оно достанется через пять лет?».

4. Фулстек — это не «знать всё». Это видеть картину целиком.

Я поднимал проект на Vue.js с нуля и провёл годы в глубине бэкенда. Фулстек не сделал меня ни лучшим фронтендером, ни лучшим бэкендером в комнате. Он дал кое-что ценнее: способность видеть, где на самом деле находится проблема.

Половина багов, которые перекидывают между «фронтом» и «бэком», существует именно потому, что никто не смотрит на систему целиком. Инженеры, способные проследить запрос от клика по кнопке до строки в базе — и обратно — это те, кто разблокирует всех остальных.

5. Читать код — навык более важный, чем писать.

За десять лет я, наверное, потратил три часа на чтение кода на каждый час его написания. Легаси банковских систем. Государственные платформы, написанные командами, которых давно нет. Кодовые базы, где документация была слухом.

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

6. Коммуникация — это инженерный навык.

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

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

7. Пользователям всё равно на вашу архитектуру.

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

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

8. Каждая предметная область учит тому, чему не научит ни один туториал.

Банкинг научил меня, что на самом деле значит «безопасно», когда через твой код проходят реальные деньги. Государственные проекты научили строить с расчётом на масштаб и на пользователей, которые никогда не читают инструкций. Маркетплейсы научили тому, что производительность — это фича, которую пользователь чувствует мгновенно. А переписывание легаси-платформы в банке учит меня, что некоторые системы настолько переплетены с бизнесом, что самое сложное в работе — понять задачу, а не написать решение.

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

9. Удалёнка вознаграждает дисциплину, а не часы.

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

Мне помогло отношение к самодисциплине как к части профессии: понятные рабочие часы, честные отчёты о статусе и смелость сказать «я застрял» на первый день, а не на четвёртый. Доверие в удалённой команде строится из мелких, скучных, регулярных моментов.

10. Через десять лет цель — уже не выглядеть умным.

Главный сдвиг за десять лет произошёл у меня в голове. Джуном я хотел доказать, что я умный: сложные решения, неочевидные приёмы, защита своего кода на ревью. Теперь я измеряю себя иначе: решение простое? Сможет ли коллега поддерживать его без меня? Стали ли люди вокруг работать эффективнее?

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

Как выглядит следующее десятилетие

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

Эти навыки не автоматизируются. Они только дорожают.

Это перевод моей статьи, впервые опубликованной на Medium.

Какой из этих уроков совпадает с вашим опытом — а с каким вы бы поспорили? Интересно, как это выглядит из других уголков индустрии. ?