Евгений Сайчик, опытный бэкенд-разработчик в одном из крупных банков России — о технологиях, управлении и главных ошибках программистов.
Мой путь в IT начался ещё в школе, на уроках информатики. Свою первую программу я написал в 2002 году — тогда ещё писали нативные приложения для операционных систем, а не платформонезависимые решения, как сейчас. Когда я недавно посчитал, сколько лет прошло с того момента, понял, что я уже «старый» в этой профессии. Но то непередаваемое чувство, когда ты пишешь код, всё получается и работает ровно так, как надо — оно никуда не исчезло. Именно оно привело меня к тому, чтобы в 2012 году заняться разработкой профессионально.
Сегодня, спустя более десяти лет работы в индустрии и пройдя путь до лида команды разработки в крупном банке, я накопил достаточно наблюдений о том, как устроены процессы, какие инструменты действительно работают и на каких ошибках чаще всего спотыкаются как новички, так и опытные инженеры.
Малые команды против Enterprise: цена быстрых релизов
В разработке есть существенная разница между подходами небольших компаний и крупных корпораций, и носит она преимущественно организационный характер. В маленькой компании с ограниченным бюджетом вы вряд ли будете работать по классическому Scrum. Там работа идёт в гораздо более быстром, порой хаотичном режиме. В моей практике были ситуации, когда в день выкатывали по несколько релизов, причём речь шла не о багфиксах, а о добавлении полноценной бизнесовой функциональности.
Прикольно это? Да, прикольно. Хотел бы я так работать? Скорее нет. Ровно потому, что когда идёт подобный релизный цикл, достаточно сложно становится следить за командой, достаточно сложно становится следить за продуктом именно с какой-то глобальной точки зрения.
Когда одна часть продукта находится в одном состоянии, а другая — совершенно в ином, учитывать все эти нюансы становится невероятно тяжело. Крупные компании предпочитают предсказуемость.
Что касается востребованности технологий в бэкенде, сейчас рынок чётко разделился на два направления:
- Российский госсектор и корпорации. Здесь взят курс на технологический суверенитет и импортозамещение. Актуальны платформы вроде Platform V (СберТех), Axiom JDK (отечественная Java с сертификацией ФСТЭК) и локализованные решения для контейнеризации (Kubernetes). Спрос на специалистов в этой экосистеме стабильно высок.
- Глобальный рынок. Здесь по-прежнему правит бал ванильная Java и Spring. Однако «не Спрингом единым» — фреймворки вроде Vert.x, Quarkus и Micronaut уверенно занимают свою нишу и точно будут актуальны в ближайшие пять лет.
Технологии — это инструмент, а не религия
Мой основной стек на протяжении многих лет — это Java. Однако я глубоко убеждён, что хороший разработчик не должен фанатично привязываться к одной технологии.
Язык как таковой — это всё-таки не то, что дано тебе сверху. Это инструмент решения проблем. Полезно не зацикливаться на одной технологии, а хотя бы на каком-то уровне знать концептуально иные. Это разминает мозги и поддерживает их в гибком состоянии.
Если вы привыкли к классическому объектно-ориентированному программированию на Java, попробуйте изучить что-то чисто функциональное, например, Haskell. Это ломает привычное мышление, но даёт понимание, что к задаче можно подойти с совершенно неожиданной стороны.
При этом важно понимать границы применимости каждого инструмента. Если для анализа данных вам нужно распарсить файл и получить сводную статистику, гораздо эффективнее использовать Python и условный Pandas, чем писать громоздкое решение на Java. С другой стороны, никто не пишет веб-сервисы на C++, хотя технически это возможно. Выбор языка должен диктоваться здравым смыслом и задачами бизнеса, а не только тем, что «у нас в компании все пишут на этом».
Коммуникация как главный навык тимлида
Когда ты управляешь разработчиками, на первый план выходят soft skills. Мой главный принцип в работе с людьми — это коммуникация, но не просто обмен словами.
Основной принцип — это умение слушать. И не только слушать, а ещё и желательно понимать, что до тебя пытаются донести. Иногда человек говорит одно, на самом деле имеет в виду другое, ты слушаешь вообще третье, а понимаешь четвёртое.
Самые сложные управленческие ситуации редко возникают из-за технических сбоев. Чаще всего это проблемы общения. У меня был случай, когда лид поставил опытному разработчику задачу в жёсткой, императивной форме: «Делай так, а не иначе», не объяснив причин. Разработчик ничего не ответил, сделал ровно так, как было сказано, но после этого его вовлечённость и перформанс резко просели.
На выяснение причин этого тихого конфликта ушло несколько дней. Ситуация была абсолютно глупой: технически решение на тот момент было верным, но неумение раскрыть свою мысль и обосновать выбор породило обиду. Работа — не место для подобных конфликтов, и время, потраченное на их решение, лучше было бы пустить на интересные бизнес-задачи. Важно уметь договариваться: лидам — объяснять контекст, а разработчикам — не бояться отстаивать своё мнение и задавать вопросы.
Главные грабли начинающих разработчиков
Наблюдая за молодыми специалистами, я могу выделить две фундаментальные ошибки, которые они совершают из раза в раз.
- Неполное погружение в контекст задачи. Новичок видит таск в Jira и идёт писать код строго по тексту. Ему либо всё понятно, либо не понятно ничего. В идеале, если в постановке задачи есть нестыковки (например, аналитик написал про интеграцию по REST, а у вас в проекте везде используется gRPC), разработчик должен пойти и задать вопросы. Чаще всего такие вопросы подсвечивают ошибки в аналитике или изменения в стандартах. Но джуниоры часто делают всё «в лоб», не вникая в бизнес-смысл.
- Иллюзия быстрой оценки трудозатрат. Это классика. Кажется, что задача очевидная и займёт пару часов. А потом одно небольшое изменение порождает каскад правок в бизнес-логике, базе данных и тестах. В итоге дедлайн был в понедельник, а разработчик сидит над таском в пятницу вечером.
Когда начинающий разработчик говорит, что сделает задачу за один день — я умножу эту оценку на x5. Оценку мидла — где-то на x2,5. Сеньора — на x2.
И мой главный совет всем, кто начинает свой путь в IT: не бойтесь ошибаться, лажают абсолютно все. Важно учиться на этих ошибках, разбирать, почему проект не взлетел или сроки сорвались, и делать это до того, как закончится бюджет. Вокруг всегда есть люди опытнее вас. Не закрывайтесь в себе, не будьте крайними интровертами. Спрашивайте коллег, смежников, аналитиков — в конце концов, укусить вас по электронной почте никто не сможет. Максимум — пришлют злой смайл.
Часто спрашивают, можно ли считать ошибкой страх перед новой задачей или технологией. Я считаю, что бояться чего-то нового — это абсолютно нормально для человека. Но конкретно в рабочих процессах такая ситуация недопустима, и здесь нужно копать в причины.
Если человек боится, что его накажут за ошибку — это серьёзный вопрос к менеджменту и процессам в компании. А если он просто боится, что у него не получится — ну, как говорится, не боги горшки обжигают. Программировать мы все тоже не умели, когда родились.
Именно поэтому на собеседованиях я ценю два качества: уже упомянутое умение коммуницировать и логическое мышление. Нагуглить «100 вопросов на позицию Senior Java Developer» и заучить их сейчас ничего не стоит. Поэтому я стараюсь формулировать вопросы неочевидным образом. Если кандидат просто зазубрил ответы, он «посыплется». Мне важно, чтобы человек понимал суть — например, как работают контракты между методами, — а не просто выдавал шаблонный текст.
Искусственный интеллект: топор вместо лобзика
Естественно, сегодня нельзя говорить об IT и не затронуть тему нейросетей. Крупные технологические компании уже открыто говорят, что ИИ забирает на себя часть задач начального и среднего уровня: Марк Цукерберг, например, прогнозировал, что уже в 2025 году ИИ в Meta сможет выполнять работу инженера среднего звена (middle). С экономической точки зрения такой курс логичен. Но возникает закономерный вопрос: если мы не берём джунов, откуда потом возьмутся мидлы и сеньоры?
Мой прогноз: в ближайшие 5–7 лет массовой замены квалифицированных разработчиков не произойдёт. А вот замена на уровне стартовых позиций — это, к сожалению, неизбежность.
Нейросети, ИИ-агенты и инструменты вроде Cursor или Windsurf отлично справляются с прототипированием.
Но когда возникает задача выйти за рамки прототипа, допилить какую-то маленькую функциональность или учесть хитрую бизнес-логику, модели пока пасуют. На данный момент они действуют так: вырубают топором, хотя надо лобзиком выпиливать.
Как в этих условиях оставаться конкурентоспособным? Мой совет прозвучит по-корпоративному, но он как никогда точен:
Для того, чтобы стоять на месте, надо идти. А для того, чтобы двигаться вперёд, надо бежать.
Сейчас идёт настоящий бум технологий. Развиваются AI-агенты, появляются сложные workflow, куда можно прикрутить кучу LLM, способных делать за вас даже холодные звонки. Необходимо быть в тренде хотя бы в рамках своего стека. Пишете на Java? Вы обязаны знать, что недавно вышла 24-я версия, какие в ней фишки и особенности. Это нужно хотя бы для того, чтобы понимать, чем этот релиз «грозит» вам в светлом будущем, когда ваш проект решит на неё переехать.
Иллюзия развития и споры об удалёнке
Серебряной пули здесь нет — всё на усмотрение работодателя и команды. Но если говорить лично обо мне, в плане коммуникации я сторонник офиса. На удалёнке человек может просто игнорировать твои сообщения в мессенджере или не открывать почту пару дней. В офисе ты подошёл к коллеге лично — и отмахнуться от тебя уже гораздо сложнее.
Но если мы говорим о профессиональном росте, то ни офис, ни удалёнка сами по себе вас не разовьют. Давайте будем честными: работа — это в первую очередь инструмент зарабатывания денег. Развитие зависит только от вас. Я видел резюме людей с десятью годами опыта в одной компании, где человек, грубо говоря, все эти 10 лет просто перекладывал данные в базу и обратно. Хоть в офисе он сидел, хоть дома — он как стоял на месте, так и стоит.
Мой самый полезный карьерный фейл — это осознание того, что программисты не должны постоянно изобретать велосипед. Когда ты приходишь на проект, тебе всегда кажется: «О, тут можно улучшить то, сё, пятое, десятое!». И ты начинаешь писать собственный фреймворк или библиотеку. Чаще всего это пустая трата времени. Эта задача уже кем-то решена. Да, готовое решение может иметь свои трейд-оффы, но оно не стоит того, чтобы бросаться переписывать условный Spring просто потому, что тебе не понравился долгий startup time.
А вдохновляет меня в профессии ровно то же, с чего всё начиналось в школьном кабинете информатики — решение проблем.
Это непередаваемое чувство, когда программа наконец-то работает так, как надо. Да, сейчас, как в анекдоте: если код заработал с первого раза, ты начинаешь искать подвох и неучтённые корнер-кейсы. Но когда вы с командой достигаете цели, превосходите ожидания, и ваш проект становится заметен на уровне компании или даже страны — это невероятно круто.
Блиц
- Фронтенд или бэкенд: бэкенд.
- Писать код самому или менторить: 50 на 50.
- Любимая технология 2025 года: AI-агенты.
- Книги, повлиявшие на карьеру: «Turbo Pascal для школьников» (Попов) и «Совершенный код» (Макконнелл).
- Главный навык разработчика: общение, однозначно.
- Стартап или стабильность: стабильная работа. Возраст уже не тот.
Не бойтесь лажать, общайтесь с коллегами и дерзайте. Нерешаемых задач не существует — есть только нюансы.
