Сеньор-разработчик делится 10 ключевыми уроками за 10 лет: фундаментальные знания, базы данных, общение, чтение кода. Узнайте, что действительно важно для карьеры в IT.
Десять лет назад я написал свои первые строчки продакшн-кода для сайтов малого бизнеса в Тбилиси. С тех пор я создавал платформы для сотен тысяч пользователей в Министерстве здравоохранения, участвовал в крупнейших онлайн-маркетплейсах Грузии, работал с международными распределёнными командами — а сегодня перестраиваю платформу рассрочки банка как Senior Software Developer в Credo Bank. Технологии полностью изменились. .NET Framework стал .NET Core. Серверный рендеринг уступил место SPA, а затем частично вернулся. Команды из одной комнаты разъехались по континентам. Но оглядываясь назад, я понимаю: самые важные уроки почти не связаны с конкретными фреймворками. Вот что осталось со мной.
Когда я начинал, я постоянно переживал, что учу «не тот» стек. За эти годы я работал с ASP.NET MVC, .NET Core, Web API, Blazor, Vue.js и полудюжиной СУБД — и каждый из них был переработан или заменён более новыми версиями. Что никогда не менялось: понимание того, как на самом деле работает HTTP, как базы данных индексируют и выполняют запросы, как моделировать задачу до написания кода, как называть вещи так, чтобы их понял незнакомец. Инженеры, вкладывающиеся в фундамент, покоряют каждую волну. Инженеры, вкладывающиеся только во фреймворки, начинают с нуля каждые три года.
Почти каждая серьёзная проблема производительности, которую меня просили исправить — в банковских системах, правительственных платформах, корпоративном ПО — оказывалась проблемой данных. Пропущенный индекс. Запрос, выбирающий в десять раз больше, чем нужно. Схема, спроектированная под то, как данные выглядели в первый день, а не на тысячный. Фронтенд-фреймворки получают доклады на конференциях. Базы данных — ночные звонки по инцидентам. Изучите SQL глубоко, даже если никогда не планируете быть «специалистом по базам данных». Особенно в этом случае.
В начале карьеры мне хотелось, чтобы каждый проект использовал новейшие инструменты. Затем я видел, как системы на «скучных» технологиях — SQL Server, обычный ASP.NET, прямолинейная архитектура — спокойно работают годами, в то время как более модные проекты разваливались под тяжестью собственной сложности. Банки и госучреждения выбирают зрелые технологии не просто так. Когда от платформы зависят 300 000 человек, «интересно» — не комплимент. Теперь, оценивая инструмент, я спрашиваю не «современный ли он?», а «сможет ли его поддерживать тот, кто унаследует его через пять лет?».
Я создавал проект на Vue.js с нуля и годами работал глубоко в бэкенде. Full-stack не сделал меня лучшим фронтенд- или бэкенд-разработчиком в комнате. Но он дал мне кое-что более ценное: способность видеть, где на самом деле живёт проблема. Половина багов, которые перекидывают между «фронтенд-командой» и «бэкенд-командой», существуют именно потому, что никто не смотрит на систему целиком. Инженеры, которые могут проследить запрос от нажатия кнопки до строки в базе данных — и обратно — разблокируют всех остальных.
За десятилетие я, вероятно, потратил три часа на чтение кода на каждый час написания. Унаследованные банковские системы. Правительственные платформы, написанные командами, которых давно нет. Кодбазы, где документация была лишь слухом. Этому не учат в университете, но умение открыть незнакомый проект и построить ментальную карту — что с чем общается, где опасные зоны, о чём думали авторы — один из самых востребованных навыков в индустрии. Новый код — это легко. Понять существующий — вот работа.
Я работал в гибридных, полностью удалённых и международных командах, где утро коллеги было моим вечером. Инженеры, которые преуспевали, не обязательно были сильнейшими кодерами — они писали чёткие сообщения, задавали вопросы рано и делали свою работу видимой без напоминаний. В распределённых командах хорошо написанное сообщение в Slack или точная задача в Jira — это инженерная работа. Код, контекст которого никто не понимает, — это обуза, какой бы элегантной ни была реализация. Если бы я мог дать один совет джуниорам, он был бы таким: навыки письма будут расти так же, как навыки кодинга.
Я работал над платформами для соискателей на государственном портале, покупателей автомобилей и банковских сотрудников. Ни один из них не заботился о том, элегантно ли слоист бэкенд или используем ли мы новейший паттерн. Их волновало, загружается ли страница, верны ли данные и доступна ли система, когда она нужна. Хорошая архитектура важна — но только как средство для этой цели. Когда архитектура становится самоцелью, вы строите для собственного удовлетворения, а не для людей, которым служит софт.
Банки научили меня, что значит «безопасно», когда через ваш код движутся реальные деньги. Государственные проекты — как строить для масштаба и для пользователей, которые никогда не читают инструкции. Маркетплейсы — что производительность — это фича, которую пользователь чувствует мгновенно. А перестройка унаследованной банковской платформы учит меня, что некоторые системы настолько переплетены с бизнесом, что самая сложная часть работы — понять задачу, а не написать решение. Технические навыки переносятся между работами. Но знание домена превращает разработчика в инженера, которому доверяют важные системы. Не просто учите стек — изучайте бизнес.
Я работаю с распределёнными командами ещё до того, как это стало мейнстримом. Неудобная правда: удалёнка не делает инженера лучше или хуже — она усиливает то, кем вы уже являетесь. Организованные люди становятся крайне эффективными. Неорганизованные тихо тонут. Мне помогло отношение к самодисциплине как к части профессии: чёткие рабочие часы, честные статус-апдейты и смирение сказать «я застрял» в первый день, а не на четвёртый. Доверие в удалённой команде строится через маленькие, скучные, последовательные моменты.
Самый большой сдвиг за десять лет произошёл в моей голове. Будучи джуном, я хотел доказать, что я умён — сложные решения, обфускация, защита своего кода на ревью. Теперь я оцениваю себя иначе: простое ли решение? Сможет ли коллега поддерживать его без меня? Сделал ли я окружающих более эффективными? Лучшие инженеры, которых я встречал, обладают этой чертой. Они перестали оптимизировать под то, чтобы выглядеть впечатляюще, и начали оптимизировать под полезность. По иронии, именно тогда люди начинают считать вас впечатляющим.
Индустрия, в которую я пришёл, больше не существует. Та, в которой я работаю сегодня, не будет существовать в 2036 году. ИИ уже меняет то, как мы пишем код, и, честно говоря, я нахожу это более захватывающим, чем угрожающим — потому что если это десятилетие меня чему-то и научило, так тому, что наша настоящая работа никогда не была в наборе кода. Она была в понимании проблем, проектировании решений и работе с людьми. Эти навыки не автоматизируются. Они становятся только ценнее.
Какой из этих уроков совпадает с вашим опытом? А с каким вы бы поспорили? Мне интересно, как это выглядит из других уголков индустрии.
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →