Как я стал лучше программировать

«Изучите прошлые исследования»
Не совсем согласен. Чаще стоит сначала самостоятельно оценить проблему " незамыленным" взглядом, а только потом ознакомиться с другими подходами.

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

Но даже теперь я продолжаю сомневаться в себе. Дело в том, что это чувство никогда не уходит, так что старайтесь не обращать на него внимания

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

Никогда не понимал советов изучать новые языки. Если они в основном только синтаксисом отличаются, то это относится к мишуре, как сам автор и написал. Конечно, какая то польза будет, но будет и вред — начнешь путаться в синтаксисе. Видимо, автор тут плохо выразил свою мысль.
Я бы на его месте советовал изучать парадигмы программирования. А новый язык стоит изучать, если он построен на неизученной парадигме.
Хоть это и более долгий путь, но было бы также полезным поизучать другие отрасли программирования. Например, в геймдеве чаще предпочитается использование композиции вместо наследования, что позволяет избегать сложных иерархий классов и зависимостей.

Спасибо за перевод! Очень вдохновляющая статья.

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

Работая в одной команде и одном стеке технологий годами, можно застрять в развитии.

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

Ну и на своей работе, стараться выбирать себе задачи посложнее и требующие изучения новых областей. Так ваш профессиональный уровень быстро вырастет.

От себя могу добавить несколько пунктов:
1) Не растекайтесь мыслью по древу. Сконцентрируйтесь на 1 области. Не языке, а именно области. Сейчас всё очень компактно и локанично. Нету того, что все всё пишут на С и без него никуда.
2) Примите, как правило, что существуют реальные задачи, которые можно решить за 1-2-4 часа. Не превращайте изучение технологий в прожигание часов и дней. Если вы не можете что-то понять или выучить за 1-2-4 часа, то решайте конкретно эту проблему. А не "ночку посижу, поучу и пойму".
3) Отдыхайте. Человеческий мозг плохо работает после 3-4 часов неприрывной нагрузки.
4) Добейте уже до конца слепую печать. Если еще не добили.
5) Правило 21 дня. Привычка прививается за 21 день. Это касается всего. Иностранного языка, качества кода, питания, сна и вообще всего. Если у вас есть проблема в работе, то её можно исправить за 21 день. Если не исправилось, то значит проблема в другом.
6) Поборите рассеянность и перестаньте отвлекаться.
7) Не берите работу на дом.
Идеализированно получилось, но если убрать бытовые причины и ссоры с коллегами и коллективом, то работает.

Советы из статьи реально странные:"Я стал лучше программировать из-за того, что всё время стал учить С, писать GCC и читать СЕКП". Понятно, что чтобы лучше программировать нужно больше программировать. Но про перегорание не сказано. А оно лечится не просто. И посреди проекта взять и слинять на месяц никто не даст.

А как Вы относитесь к мысли о том, что всё уже украдено написано до нас. И я думаю, что со мной многие согласятся в том, что разработка сейчас и разработка лет 10 назад — это две большие разницы. Сейчас всё сводится к банальному увязыванию между собой горстки библиотек и плагинов/экстеншенов к ним.