af

«Зарплата — $4–6 тысяч». На первый взгляд всё понятно: если вы подходите компании, где-то внутри этого диапазона должна лежать ваша будущая зарплата. Но между красивой вилкой в вакансии и деньгами, которые окажутся у вас на счёте, иногда лежит довольно большая дистанция.

Есть ловушка, в которую легко попасть после нескольких лет карьеры в IT: вроде бы проходишь курсы, собираешь сертификаты, постоянно учишься и добавляшь в резюме новые технологии, но на собеседовании показать всё равно нечего. Попробуем разобраться, что с этим делать.

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

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

Сначала в календаре появляется ежедневный статус, потом еженедельный синк, потом встреча «по итогам», встреча «перед встречей», отчёт, презентация и пара уровней согласования сверху. У каждого из пунктов когда-то была причина, но вопроса жива ли она, с тех пор никто не задавал.

Коан: «Незаменимость — единственный технический долг, которым принято гордиться».

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

Пару лет назад «добавить AI в продукт» почти автоматически означало, что в команде нужен ML-инженер. Сегодня под AI понимают совсем другие задачи: поиск по документации, чат-ассистента, автоматизация обработки писем, генерация отчетов или создание внутреннего помощника. 

Обычно консультанты по межкультурным коммуникациям учат беларуских айтишников правилам игры в международном IT — объясняют, как общаться с американскими заказчиками, не пугаться индийского английского и правильно отвечать на бесконечные «How are you?» Но что происходит, когда роли меняются?

Знакомый записался на ML-курс за две тысячи евро, а в LinkedIn постоянно рассказывают, что без AI через пару лет никто не будет нужен. Вы тоже смотрите программу обучения, где первым пунктом идет линейная алгебра, затем статистика, потом оптимизация. И если в этот момент возникает желание закрыть вкладку — вы не одиноки.

Вы только что обновили README, добавили схемы в Confluence и закрыли самые частые вопросы. Но через пару дней кто-то из коллег всё равно пишет: «А как правильно?» Обычно после такого предлагают лучше  документировать — и начинают добавлять страницы. Есть другое решение.

Представьте ситуацию. Третий год подряд говорят на performance review, что вы переросли текущий грейд. Но как только дело доходит до промо-комитета, заявка возвращается с размытой формулировкой: «Неясен импакт за пределами вашей команды».

Семь лет коммерческой разработки, десятки успешно закрытых задач, сложные фичи, оптимизация производительности. И тут на собеседовании просят: «Спроектируйте систему для сервиса бронирования». Через несколько минут становится не по себе. Кажется, вы чего-то не знаете, хотя опыт объективно большой.

Зарплаты не растут, проекты выбирают новые технологии, а вместо разговора об опыте на собеседовании спрашивают: «Почему вы до сих пор не перешли на что-то современное?» Самая плохая реакция здесь — убедить себя, что рынок скоро передумает. 

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

Стоит просмотреть пару роликов об AI — и лента быстро решит, что вам пора становиться AI-инженером. Дальше знакомое: нейросети, трансформеры, математика и обещание новой карьеры. Если вы уже backend-разработчик, QA, аналитик или PM, задача обычно скромнее: разобраться, что учить для своей нынешней работы и не потратить несколько месяцев на чужую профессию.

Открыть компанию в Польше стало значительно проще, чем десять лет назад. Но сразу после регистрации предпринимать сталкивается с другой реальностью: счета-фактуры, налоги, складской учет, банковские операции, обязательная работа с гос. системами вроде KSeF, хранение документов и масса рутинных процессов, которые получится игнорировать.

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

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

Новый вариант регистрации показывает по дашборду +3% к конверсии. Продакт уже пишет в чат: «Катим?». Аналитик отвечает уклончиво: «результаты многообещающие». Все смотрят на вас. 

Команде редко бывает нужен «ещё один чат с AI». Чаще требуется помощник, который знает правила релизов, отвечает по документации, помогает обработать типовой запрос или запускает понятную цепочку действий. Вопрос в том, стоит ли ради этого поднимать отдельный сервис — и если да, то где.

Каждую неделю в IT появляется новый «обязательный» навык. Вчера все учились писать промпты, сегодня поднимают MCP-серверы, а завтра в ленте кто-то расскажет про ещё один агентный фреймворк. Пропустишь пару новостей и уже кажется, что через полгода останешься за бортом.

Проблема может быть совсем не в алгоритмах. Рассказываем, почему сильные инженеры из сервисных компаний нередко теряются на продуктовых интервью и как понять, что докручивать — стек и алгоритмы или product sense.

Вы тоже считаете, что квантовые компьютеры — просто дорогие игрушки, которые заработают (в лучшем случае) через тридцать лет? Если так, давайте разбираться. Спойлер: если нет — пора изучать. 

В карьере опытного разработчика, DevOps-а или QA-лида однажды наступает момент, когда рамки обычных задач становятся тесными. Уже не интересно просто писать надежный код, оптимизировать пайплайны или закрывать таски в Jira. Хочется видеть систему целиком, управлять технологическим хаосом и самому влиять на глобальные решения. Поздравляем! Это сигнал, что вы готовы к переходу в Solution Architecture.

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

Мир Open Source поначалу может показаться закрытым клубом для избранных. Есть даже заблуждение, что в репо проектов вроде Kubernetes, React или Linux пишут только гуру с многолетним стажем, а новичкам там нечего делать. Как итог, многие инженеры годами копят учебные проекты-однодневки на GitHub, надеясь, что рекрутеры когда-то их оценят.

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

В среде разработчиков все еще силен красивый, но опасный миф: «Хороший код говорит сам за себя, а лучшее резюме — идеально зеленая сетка коммитов на GitHub». В идеальном (академическом) мире этого, возможно, хватило бы. Но в реальности, где за сильные позиции в стартапах борются тысячи талантов, молча писать код — это сознательный отказ от половины карьерных возможностей.

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