С 2022 года я разрабатываю методику предсказания IT‑карьеры для новичков.

Равно год назад она стала общедоступной в виде бесплатного курса‑профориентации для всех желающих. За прошедшие 12 месяцев свои IT‑перспективы успели оценить 795 человек. Увы, подавляющее большинство из них (87%) получили отрицательный ответ.

В этой статье — типичные ошибки ищущих себя в новой профессии.

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

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

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

Четыре года назад я упёрся в стену. Я работал QA инженером, изучал инструменты, автоматизацию, базы данных — но карьерного роста не было. Мне хотелось развиваться, двигаться в сторону тест-менеджмента, но одних технических навыков оказалось недостаточно. Тогда я впервые осознал, что не только харды определяют успех.

Soft skills стали тем, что помогло мне выйти на новый уровень. Я научился планировать, делегировать, вести переговоры, работать с командой. Всем привет! Меня зовут Сергей Лебедев, я QA Lead в Яндекс Лавке и в этой статье я расскажу, какие soft skills действительно важны, как их развивать и почему без них сложно расти в IT.

Ни для кого не секрет, что в нашей стране практически любой руководитель в сфере IT начинал свою профессиональную карьеру рядовым сотрудником. Причины, побуждающие специалиста начать двигаться в сторону руководящих позиций, могут быть разными, и в зависимости от причин скорость этого пути также может существенно различаться. Однако сам процесс становления «молодого» руководителя почти всегда сопряжён с одними и теми же проблемами. Основываясь на личном опыте и опыте наших коллег и подчинённых (которые тоже руководители), мы хотим коротко разобрать проблемы, особенно беспокоящие и мешающие вчерашним разработчикам, выбравшим сегодня путь своего развития в качестве руководителя группы или отдела. Более высокопоставленным руководителям эта статья также может быть полезна при менторстве «младшего командного состава».

Всем привет. Меня зовут Михаил и на данный момент времени я работаю тимлидом в крупной IT‑Компании.

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

Я капитально прихерел при работе с одним руководителем, благо его успешно из компании попёрли. Но вот осадочек остался. Вот вам список его золотых цитат и действий, которые он регулярно исполнял. Это пример того, как не надо работать в компании и ставить себя в команде. Ну поехали.

­­­Какие предметы вам нравились в школе? Я очень любила математику.  Меня завораживали цифры, формулы и логические рассуждения. А самое главное, даже если решать задачу несколькими разными способами – единственно верный ответ всегда будет один. И проверив его, можно быть уверенным, что задача решена правильно.

Сейчас, проектируя программные системы, я тоже решаю задачи, но они принципиально отличаются от математических, где всегда есть единственно верное решение. Если в школе небольшого условия задачи было достаточно, при проектировании это не так. Как говорил итальянский программист Альберто Брандолини: «В прод идут не знания экспертов в предметной области, а предположения разработчиков». Поэтому важно не просто полагаться на своё понимание, а проверять предположения на практике.

Для этого необходимо организовать совместное исследование сложной предметной области бизнеса: собрать команду, построить модель процессов и сверить свои гипотезы с реальными знаниями экспертов. По моему опыту, снизить неопределенность в понимании предметной области и проверить предположения на соответствие действительности помогает — Event Storming. Эта техника выявляет и минимизирует влияние ошибочных предположений на качество конечного продукта.

Нам нужны новые системы безопасности, учитывающие их странности

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

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

Теперь в обществе активно внедряется новый тип участника процессов — искусственный интеллект (ИИ). Системы, вроде больших языковых моделей (LLMs), решают когнитивные задачи, которые ранее были доступны только людям. Но и они не безупречны. Порой их «советы» — как есть камни или добавлять клей в пиццу — вызывают недоумение. Однако важен не сам факт наличия сбоев, а природа этих сбоев — она совсем иная, чем у человека.

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

Человеческие ошибки vs. ошибки ИИ

Жизненный опыт помогает нам предсказывать, где и почему может оступиться человек. Обычно сбои происходят на границах знаний: большинство из нас легко допустит ошибку в сложной математике. Мы понимаем, что промахи часто идут "пачкой": неуверенность в одном вопросе тянет за собой другие. Мы также знаем, что на надежность влияет усталость или отвлеченность. И чаще всего человек осознаёт, когда чего-то не знает: тот, кто не силён в матанализе, вероятно, прямо скажет «не знаю».

В последнее время тема собеседований, особенно на Хабре, стала очень актуальна. В каждой статье кандидаты жалуются, что стало много собеседований и советуют друг другу ИИ‑инструменты, которые помогут сломать эту стену. С другой стороны, компаниям не нравится, что просто обычного разработчика средней квалификации уже сложно найти и надо потратить много времени на это.

Совсем недавно появилась статья: «Читерство в законе. Как пройти собеседование и устроиться на работу в дивном новом мире». Если коротко, то в ней говорится о том, что для того, чтобы устроится на работу необходимо специально тренироваться для прохождения собеседований. Все друг друга обманывают (как HR со стороны компании, так и сам кандидат).

И с этим сложно не согласится. Мне иногда приходится иметь дело с наймом. И что я вижу на собеседовании? Или что я проверяю на собеседовании? Правильно: умение проходить собеседования, а не навыки и опыт работы. А ведь не должно быть так!

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

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

Технические команды часто избегают лишней документации, но информация всё равно каким-то образом передаётся, сохраняется и развивается. В этой статье — попытка разобрать скрытые механизмы общения внутри инженерных команд: как выстраиваются негласные соглашения, каким образом рождаются "внутренние диалекты" и зачем вообще всё это, если есть JIRA, Confluence и куча других инструментов. Много примеров, блоков кода на разных языках и немного личного опыта.

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

Привет, Хабр!

Сегодня разберёмся, зачем Go-проекту слой Application / Use-Case: как он герметично изолирует бизнес-логику, позволяет переключаться между HTTP, gRPC, Cron-джобами и очередями, а заодно экономит тесты и нервные клетки.

В мире IT баги случаются везде — даже в управлении людьми. По данным разных исследований, от 60 до 80% сотрудников хотя бы раз сталкивались с токсичным руководителем. А 60% из них уходили именно по этой причине. Почему так происходит, как это выглядит изнутри и почему этот баг опаснее всех дедлайнов вместе взятых — разберёмся на конкретных цифрах.

Кто такой токсичный руководитель?

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

Кажется, мы все примерно понимаем, что такое токсичность. Но где грань между требовательностью и токсичностью? Чтобы не гадать, мы в школе руководителей «Я Начальник» провели опрос среди 149 сотрудников по всей стране чтобы узнать, что же такого делает токсичный начальник. Вот топовые паттерны поведения токс-босса:

61% — признаёт только своё мнение, остальные же просто «не шарят»

54% — ошибки? Это не его зона ответственности, всегда виноват кто-то другой

48% — мастер подмены реальности: «Я такого не говорил», «Вы не так поняли»

16% — наказывает за ошибки (честно говоря, мы думали, что об этом заявит большее количество респондентов)

Реальные шаги, не всегда прямые, но всегда насыщенные опытом — моя история о том, как я пришел в SM Lab и превратился в инженера, который теперь помогает другим начать свой путь в IT.

В своей предыдущей статье [перевод на Хабре] я говорил о множестве недостатков C++, которые, по сути, устранил Rust. Благодаря этому код теперь легко использовать правильно и сложно использовать неверно. Я не говорил о безопасности по памяти, просто привёл пример того, что пользователь функции не может случайно поменять местами аргументы количества и цены.

На написание статьи меня вдохновил доклад Мэтта Годболта о том, как можно сделать интерфейсы C++ более надёжными: Correct by Construction: APIs That Are Easy to Use and Hard to Misuse. Вам стоит его посмотреть!

В той статье я сказал, что Rust гораздо лучше помогает разработчику, возможно, благодаря тому, что у него были десятки лет, чтобы учиться. В конце концов, первая версия C++ была выпущена в начале 80-х, а Rust — в начале 2010-х. Если дать C++ несколько десятков лет для обучения, то, разумеется, появятся новые структуры, которые будут обладать высоким качеством и которые сложно использовать неправильно.

Но так ли это?

Мои последние тексты не случайно про софты. Это не просто модная тема для HR-брендов, а реально то, что решает: будет у тебя команда или “песочница по интересам”.

Я - фаундер проекта и живу им почти 24/7, управляю двумя командами - рекрутинг и продукт. У каждой - свой характер, задачи и темп. И за годы работы и линейником, и управленцем я понял главное: hard skills запускают, а soft skills удерживают. Особенно в шторм.

Теория по менеджменту хороша, но решает всё опыт и набитые “шишки”. Если вы только начинаете путь менеджера - вот концентрат того, что помогает не срываться, не терять команду и не утонуть самому.

Привет, Хабр!

В статье рассмотрим, как реализовать Template Method-паттерн в Go без наследования, зачем он вообще нужен.