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

Это что-то вроде T-shape и широкий взгляд, а скорее даже про скилл с буквой E из методологии Адизеса (спасибо, Соня), но на самом деле речь про базовый навык понимания требований бизнеса, способность генерировать идеи за пределами технического бекграунда исходя из потребностей юзера (писал еще про это тут). 

Объяснить это могу лишь тем что не знаю ни одного крутого тим/тех лида, который ещё работает в найме и при этом не думает про проект в разрезе бизнеса. И меня всегда бесит что есть коллеги, которые не хотят в этом направлении думать - над одним проектом же работаем вроде!

У других ролей такая же история - вспомните всех, кого вы считаете крутым в своей позиции и очень вероятно это будут люди, которые по-хорошему "лезут" в дела других, чтобы понимать задачи, потребности и боли каждого отдела и каждого кусочка бизнеса, ведь самое крутое - оно всегда было на стыке чего-либо, да?

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

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

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

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

Для старта с нуля это даст огромный новый и, главное, безопасный опыт - уже в рамках своего проекта вы перейдете в ранг "ребята, которым не все равно чем заниматься".

Дальше - больше, и тут качать навык уже как раз помогают пет-прожекты. Пет-прожекты без идеи и только для пробы технологии или языка - трата времени. Лучше в рамках проекта придумать идею/опробовать гипотезу с новой технологией или если уж очень хочется нового - уволиться и таки начать делать другое.

Хороший пет-прожект для разработчика - что-то вроде нано-стартапа из одного человека, а не очередной todo list из туториала.  Любая новая для вас идея, любое все что угодно, цель - начать что-то делать в этом направлении, хотя бы минимально, и дойти до первого вопроса "а как мои юзеры будут делать Х?”, ответить на него и идти дальше. Повторяя это из раза в раз вы не только начнёте постоянно задавать сами себе продуктовые вопросы, что само по себе качественно возведет вас на другой уровень разработки, но заметите ещё забавный сайд-эффект: некоторые ответы и решения можно вынести в отдельный пет-прожект и стартап. Делающих хорошо одну функцию стартапов очень много и они успешны.

Последняя пара мыслей: 

• gpt и условный google copilot еще не скоро заменят разработчиков, но мне все больше становится очевидно что спрос на простых писателей кода будет меньше и они будут стоить дешевле

• no-code для пет-прожектов с идеей как раз таки работает идеально, в отличие от всего того о чем про него говорят

Перенёс из своего канала сюда - пост нашел отклик как у разработчиков, так и у фаундеров.