Сегодня в моей команде освободилось место джуна. Забавная получилась история.

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

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

К третьему месяцу работы становится понятно, что девочка растёт медленно, мотивация на уровне 4/10. Плохо конечно, но поправимо.
Даём обратную связь, много общаемся на тему «чем хотела бы заниматься».
Начинаю подбирать более интересные для неё задачи в надежде на прогресс.

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

Мораль: не стоит затягивать с расставанием, всем от этого только хуже.

Многие обходят стороной вопрос эмоционального комфорта работы.

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

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

Что приводит к профессиональному росту? Освоенный курс доп. образования? Прочитанная книга?

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

Но вот что отличает хорошего специалиста от плохого, так это способность делать выводы из таких ситуаций.

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

Почему я отказался от полставочников?

Не знаю, может это моя проблема как менеджера, но складывается ощущение, что погружение полставочников в рабочие процесс происходит "на пол-шишечки". Из-за этого выполнение задач затягивается, сроки сдвигаются, а отношение к задаче менее ответственное.

Менеджерские усилия на полставочника такие же, как на полноценного сотрудника, а эффект в 2-4 раза меньше.

Говорят, чтобы стать профессионалом в своем деле, нужно заниматься в сумме 10 000 часов.

Десять тысяч часов примерно равно 7 годам рабочего времени, а для кого-то и всем 10 годам. Это марафон, в котором нет места лени, дискомфортному коллективу, плохим процессам в компании и выгоранию.

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

Как выглядит рабочий день человека, работающего с данными?

Бизнес-цель -> таска -> код -> результат.

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

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

Вот итоге получается, что на этом конвейере появляются те, кто 100% времени тратит на один тип задач, а это верный путь к выгоранию и стагнации.

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

Оставлю здесь это фото как напоминание: работать нужно головой, а не 8 часов.

После 4 месяцев в тепле вернулся в РФ.
Впечатления двоякие.

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

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

Боюсь представить, сколько сил нужно при релокации на ПМЖ.

Когда в компании говорят про ML-проекты, многие ДСы, назначенные большими талантами, бросаются сразу делать модели. Как будто обед начинается с десерта - вкусно, соблазнительно, но очень вредно.

Так же с ML-проектами. Если в компании нет опыта внедрения таких проектов, то первые проекты могут провалиться из-за проблем с дизайном, разных ожиданий у заказчиков/исполнителей, дискоммуникации и разных других.

Мораль - не бежать вперед паравоза, поедать слона по кусочкам и все подобные крылатые фразы.

Прошло два месяца с последнего поста и только сейчас набралось мыслей для нового.

Столкнулся с проблемой отсутствия дизайна текущего проекта. Читал, что отсутствие дизайна - это на самом деле присутствие плохого дизайна. Особенно это видно в командах из 5-6 ДСов, когда каждый уходит делать свою часть работы, а в конце спринта эти кусочки не стыкуются.

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

Надеюсь скоро найти книги/курсы по систем дизайну и глубже проникнуться ценными идеями.

Про важность обратной связи

Говорят, обратная связь помогает человеку развиваться. Но иногда я вижу, что обратная связь лишь напоминает человеку о его “зонах роста”, в которых он так и не вырос. Получается противоположный эффект: обратная связь подсвечивает отсутствие прогресса и еще больше демотивирует.
Что с этим делать?
Стоит выяснить, действительно ли та зона роста, в отношении которой дается обратная связь, является для человека зоной роста. Или это просто хотелка из разряда “похудеть к лету”?

Однажды Эрнест Хемингуэй поспорил, что сможет написать самый короткий рассказ, способный растрогать любого. Он выиграл спор, написав это.

А если серьезно, то недавно в сеть утекла кодовая база Яндекса на ~45Гб. Просматривал архив с кодом и нашел много интересного, например эту фразу, на которой обучалась Алиса.

Про важность окружения.

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

Недавно провел почти полтора часа за беседой с таким человеком и ощутил бодрящий прилив сил.
Такой вот рабочий допинг.

Знакомый, опытный разработчик 1С, поинтересовался, как сейчас обстоят дела на рынке труда питонистов и легко ли джунам живется. Хочет сменить сферу, но пока не выбрал направление.
Разговор зашел про различия между грейдами. Мы пытались понять, где та грань, отделяющая джуна от мидла и выше. Это мог быть вечный диалог.
Он говорил про опыт и хард скилы, я - про зону ответственности и стратегическое видение.
Но в одном мы сошлись - команда создает эффект регрессии к среднему.
Ты выше среднего по набору скилов? Будешь старшим разрабом, а может даже лидом. Учиться тебе не у кого, будешь учить младших.
Знаешь синтаксис и немного алгоритмов? Будешь младшим, быстро нахватаешься и сможешь называться мидлом.

В итоге то, на какой грейд тебя позовут, зависит на 90% не от тебя, а от среднего уровня команды.

Любителям sudo посвящается

Статья на хабре попала в «лучшие за сутки», что приятно.

Оставлю ссылку здесь и пойду готовить следующую статью.

Все новое - хорошо забытое старое

✅ ☑️ #чек_лист

Делюсь собственным чек-листом готовности идеи ML проекта к внедрению👇

1. Определение задачи: как машинное обучение может улучшить бизнес-процессы или определенные операции.
2. Оценка ценности: определение потенциальных экономических преимуществ, которые может принести внедрение проекта.
3. Доступность данных: оценка доступности и качества данных, необходимых для обучения моделей.
4. Культура компании: насколько компания готова к изменениям и внедрению новых технологий.
5. Планирование: разработка роадмапа внедрения проекта с определением ролей и зон ответственности.
6. Наличие ресурсов и компетенций: есть ли у вас необходимые ресурсы, вычислительные мощности, данные и квалифицированные специалисты, чтобы выполнить проект.
7. Оценка рисков: возможные риски, связанные с внедрением проекта, и меры по их минимизации.
8. Поддержка и улучшение качества: создать план поддержки и повышения качества, чтобы обеспечить успешное внедрение и дальнейшее развитие проекта.

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

#тру_стори

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

Наверняка все мы так делали - брали код из открытого источника и применяли у себя. Вроде не страшно, да и для дела полезно.
Но вот что меня всегда угнетало в такой ситуации, так это то, с какой помпой преподносится решение.
Зачем продавать этот проект как верх архитектурной мысли, если это простой копи-паст? Как можно чужое решение называть своим, если своего там минимум? В чем ценность такого проекта?

И самый интересный вопрос: почему это меня так тригерит? 🤔

Го в комментарии - это оттачивание навыков, одобряем, или обезьянничество и не одобряем?