Денис Артамонов

хочется не просто пилить рутинные таски, и если уже повезет с таском то улучшать скилл, а хочется максимально эффективно развивать себя как разработчика, чтобы стать не только полноценным девом, а и хорошим специалистом

дополню ответ aRegius

полноценный, хороший - это всё Относительно .. в программировании/разработке эти термины очень спорны .. есть крутые спецы, решают сложные задачи, которые пишут код не по PSR (пример из PHP), но есть спецы, которые пишут хороший код, но, на этом всё и заканчивается, ибо решать задачи особо не могут ..

Вы использовали слово "рутинные", значит у Вас уже есть понимание того, что такое "рутина"/"стагнация".

Стагнация - это хорошее понятие для разработчика.

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

Если разработчик это понимает, то нужно, просто искать новое место работы, новые задачи, которыми он еще не занимался, т.е. чтобы развиваться дальше ..

Расскажу на примере себя )

Когда я чувствовал, что наступает стагнация, я просто создавал/активировал своё резюме на headhunter, потенциальные работодатели присылали мне тестовые задания, я разбирался/решал их, тем самым оценивая свой уровень и уровень работодателя, далее, если задача работодателя была мне интересна, проходил собеседование, выяснял интересующие меня моменты, и в случае возникновения большего интереса, уходил работать к нему.

Таким образом, я занимался тем, что интересно мне, развивался, как специалист, как разработчик, боролся со стагнацией.

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

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

Итог: нужно заниматься своей реальной оценкой и не бояться что-то менять.

Конкретно по коду, лично мне - помогает git
По коммитам и ревестам вполне можно освежить память по проделанной работе, ну и конечно же просмотреть работу других программистов

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

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

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

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