Просто немного перефразирую абзац из статьи: Чем дольше разработчик работает, тем сильнее он привязывается к специфичной архитектуре своего текущего проекта. Он начинает выполнять задачи, нужные только внутри компании, и нигде больше на рынке. В результате разработчик теряет свою ценность даже в плане технических навыков, становясь менее гибким.
Про взаимозаменяемость я бы немного конкретизировал. Одно дело когда фронтендера просят внезапно побыть бэкэндером. И, лично для меня, совсем другое дело когда внутри команды есть некоторые процессы, которые позволяют обмениваться знанием по проекту, разным его областям, развивать компетенции. При этом делать это планово, в рамках определённых процессов, а не в состоянии аврала. Для проекта не очень хорошая ситуация, когда 1-2 человека ушли в отпуск (например, летом) и никто ничего вообще не понимает по каким-то областям.
На мой взгляд взаимозаменяемость может быть и как плюс. Эти вопросы конечно же лучше уточнить у тех кто проводит интервью. Если процесс хорошо выстроен - думаю обязательно поделятся информацией.
Пример с не опаздывают на самолет мне кажется немного скрывающий или упрощающий поднимаемую в статье проблему. Сама по себе эта задача уже является решенной и в ней все шаги (дорога в аэропорт, очередь на вход в аэропорт, паспортный контроль) известны и всего лишь нужно оценить понятные риски каждого шага, заложить буферы.
В разработке же мы довольно часто встречаемся с задачами, где порой не очень понятно под какие риски закладывать буферы и вообще какие риски сыграют роль в процессе реализации. При этом оценка первоначальная всё же ожидается, иначе, процитирую: а как тогда анонсировать фичи клиентам, заключать контракты... .
Хорошей практикой является, по возможности, давать оценивать задачи тому что ближе и лучше знаком с её контекстом, подводными камнями и у кого более полная картина о том что нужно вообще будет сделать.
В качестве некоторой формализации процесса code review можно вводить определенные теги к комментариям коду. Например: Recommendation, Defect, Code style, Vulnerability и т.д. И далее договориться в команде какие теги являются блокирующими к прохождению ревью, а какие нет. Соответственно, Recommendation может быть опциональным и если автор изменения согласен с замечанием и имеет возможность исправить — исправляет, а может и не исправлять.
Очень классно, что во всей этой истории у Вас и руководителя получилось рабочее и конструктивное решение серьезной проблемы, респект обоим участникам процесса.
Разговор в форме «one-2-one» и «2+1» это, как мне кажется, будут абсолютно два разных разговора. В немалом количестве ситуаций, во втором случае, у человека с которым идет разговор будут темы, которые не хочется поднимать с дополнительным человеком, который присутствует. Если разговор касается каких-то серьезных рабочих проблем, то мне кажется самый лучший формат «one-2-one».
А Вы не спрашивали их сколько времени они тратят на самообразование вне работы: чтение литературы и статей, просмотр видео с профильных конференций и т.д.?
Давайте я попробую сформулировать свой вопрос с более практической точки зрения. Разработчик в рамках задачи реализовал какую-то новую фичу в проекте, например в рамках требования от бизнеса. После этого ему нужно написать автотест (согласно повествованию в статье). Для того чтобы написать автотест, как мне кажется, должен существовать какой-то план тестирования этой фичи. Конечная же задача чтобы выполнялось требование от бизнеса. Далее на основе плана пишется код автотеста. Если это так, то кто составляет план и кто верифицирует что план верный? И есть ли какое-то ревью теста?
Legacy проект это в первую очередь, по моему опыту, это очень много баг фикса. Причём баг фикса преимущественно без рефакторинга, потому что как раз на него бизнес не очень хочет выделять время (тема отдельных долгих обсуждений). Отсюда вытекает, как Вы написали, много анализа кода — это действительно присутствует. Среди советов можно добавить: 1) фикс бага только с добавлением теста на данный сценарий (исключение тест добавить невозможно или очень дорого) 2) ведение базы знаний по решенным проблемам: что случилось? почему? как решили? что сделали чтобы снизить вероятность повторения?
А какие могут быть советы в рамках «Путь разработчика» для кардинальной горизонтальной смены предметной области, в которой работаешь, при этом учитывая что в текущей предметной области у тебя уровень Senior. Например, сейчас у тебя Mobile Development или Desktop Apps, а хочется уйти в Backend Highload, но при этом опыта в последнем у тебя нет конечно, а Junior'ом не хочется получится быть.
В сети или в курилке часто можно услышать утверждения о том, что TOEFL/IELTS проверяют не уровень владения языком, а умение соответствовать шаблонам.
Мне кажется эти утверждения исходят из непонимания того, что для оценки на сертификационном/экзаменационном уровне каких-то знаний нужен какой-то единых подход, единая мера весов. В результате часть времени подготовки к экзамену уходит на понимание структуры экзамена, чтобы в итоге сам процесс экзамена не стал сюрпризом.
Еще хочется добавить, чтобы получение сертификата — это отличная цель (особенно когда лень что-то делать). Есть точка A (текущий уровень владения иностранным языком) и есть точка B (следующий уровень), к которой нужно прийти/достичь — многих людей это сильно мотивирует.
Давно замечаю, что немалое количество людей (в первую очередь менеджеров) считает отпуск панацеей от выгорания: «нужно больше отдыхать», «сходи в отпуск». Очень верно подмечено про баланс рутины и мозгового штурма. Если ты постоянно занят простой рутиной, то через какое-то время становится очень сложно участвовать в мозговых штурмах и вообще решать серьёзные задачи. Мозг становится растренированным. И если человек амбициозен и хочет задач, когда нужно постоянно думать, довольно часто, на него начинает это давить психологически. Хороший менеджер должен чувствовать такие ситуации и решать их.
Спасибо большое за пост, очень структурировано и лаконично!
Если кто-то написал херовый код, то так ему и скажи: «Ты написал херовый код».
Вот здесь не соглашусь, т.к. ощущается небольшой перегиб. Разработчик вполне может оказаться обидчивыми (да, такое может быть) и запомнит это надолго. Руководитель после этого будет уже в меньшей степени после этого восприниматься как друг. Плюс сам разработчик будет иметь больше боязни при изменения в коде. Мне кажется если кто-то написал реально плохой код — нужно максимально корректно разобрать ошибки и без эмоций.
Всё зависит от автора, а точнее от его уровня компетенции. Если Junior или Middle-недавний-Junior начинает игнорировать (а главное может это делать совершенно спокойно) замечания Senior'ов или архитектора, то мне кажется что-то точно не так с процессами. Поэтому в общем случае давать право игнорировать замечания нельзя.
Просто немного перефразирую абзац из статьи:
Чем дольше разработчик работает, тем сильнее он привязывается к специфичной архитектуре своего текущего проекта. Он начинает выполнять задачи, нужные только внутри компании, и нигде больше на рынке. В результате разработчик теряет свою ценность даже в плане технических навыков, становясь менее гибким.
Про взаимозаменяемость я бы немного конкретизировал. Одно дело когда фронтендера просят внезапно побыть бэкэндером. И, лично для меня, совсем другое дело когда внутри команды есть некоторые процессы, которые позволяют обмениваться знанием по проекту, разным его областям, развивать компетенции. При этом делать это планово, в рамках определённых процессов, а не в состоянии аврала. Для проекта не очень хорошая ситуация, когда 1-2 человека ушли в отпуск (например, летом) и никто ничего вообще не понимает по каким-то областям.
На мой взгляд взаимозаменяемость может быть и как плюс. Эти вопросы конечно же лучше уточнить у тех кто проводит интервью. Если процесс хорошо выстроен - думаю обязательно поделятся информацией.
Пример с не опаздывают на самолет мне кажется немного скрывающий или упрощающий поднимаемую в статье проблему. Сама по себе эта задача уже является решенной и в ней все шаги (дорога в аэропорт, очередь на вход в аэропорт, паспортный контроль) известны и всего лишь нужно оценить понятные риски каждого шага, заложить буферы.
В разработке же мы довольно часто встречаемся с задачами, где порой не очень понятно под какие риски закладывать буферы и вообще какие риски сыграют роль в процессе реализации. При этом оценка первоначальная всё же ожидается, иначе, процитирую: а как тогда анонсировать фичи клиентам, заключать контракты... .
Хорошей практикой является, по возможности, давать оценивать задачи тому что ближе и лучше знаком с её контекстом, подводными камнями и у кого более полная картина о том что нужно вообще будет сделать.
Могу порекомендовать репозиторий C++ links, где автор публикует найденные полезные ресурсы по С++ по различным категориям.
Очень классно, что во всей этой истории у Вас и руководителя получилось рабочее и конструктивное решение серьезной проблемы, респект обоим участникам процесса.
А тест-планы тоже разработчики прорабатывают и составляют, на основе которых пишутся автотесты?
хочетсяполучится быть.Мне кажется эти утверждения исходят из непонимания того, что для оценки на сертификационном/экзаменационном уровне каких-то знаний нужен какой-то единых подход, единая мера весов. В результате часть времени подготовки к экзамену уходит на понимание структуры экзамена, чтобы в итоге сам процесс экзамена не стал сюрпризом.
Еще хочется добавить, чтобы получение сертификата — это отличная цель (особенно когда лень что-то делать). Есть точка A (текущий уровень владения иностранным языком) и есть точка B (следующий уровень), к которой нужно прийти/достичь — многих людей это сильно мотивирует.
А есть какое-то взвешенное объяснение этого? Чем это выгоднее и/или удобнее для руководителя?
Вот здесь не соглашусь, т.к. ощущается небольшой перегиб. Разработчик вполне может оказаться обидчивыми (да, такое может быть) и запомнит это надолго. Руководитель после этого будет уже в меньшей степени после этого восприниматься как друг. Плюс сам разработчик будет иметь больше боязни при изменения в коде. Мне кажется если кто-то написал реально плохой код — нужно максимально корректно разобрать ошибки и без эмоций.