Некоторые люди на React Conf спрашивали у меня о том, как улучшить свои навыки программиста. По некоторым причинам люди видят во мне продвинутого программиста, которого следует прислушиваться. Я подумал, что стоит написать статью о моей “мыслительной модели” того, как я подхожу к программированию в течение лет. Расскажу немного о себе: мне 32 года и у меня за спиной более 10 лет стажа. Но только в последние несколько лет я действительно начал чувствовать уверенность в том, что я делаю. Но даже сейчас иногда я сомневаюсь в своих способностях. Основная идея в том, что это чувство никогда не пропадёт, так что постарайтесь его игнорировать, продолжая разрабатывать и набираясь опыта. Хочу предупредить, что это лишь несколько подсказок как улучшить свои навыки программиста. В конечном итоге вам самостоятельно потребуется выяснить, что будет работать именно для вас. Это лишь некоторые вещи, которые работают для меня.

Найди людей, которые тебя вдохновляют, но не идеализируй их

С годами было много людей, которых я искал и наблюдал за новыми технологиями. Я узнал многое просто доверяя тому, что они говорят и углублялся в темы над которыми они работали. Эти люди, как правило, были продуктивными и вдохновляющими. Найдите таких людей и позвольте им вдохновлять и учить вас. Однако не идеализируйте их. В твиттере несложно выглядеть страшным, но, если вы посмотрите на то, как они работают в реальной жизни, вы увидите, что они не так сильно и отличаются от вас. Повсюду хаки и т.п. Мы все экспериментируем. Не доверяйте безоговорочно этим людям - если вы не согласны, обратитесь к ним и учитесь у них. Мои наиболее продуктивные обсуждения произошли именно так. Мой конфигурационный файл Emacs беспорядочен. Я не знаю, почему автодополнение OCaml не работает (оно не работает уже около месяца). Я не автоматизировал рутину и ищу в истории терминала команды, которые мне периодически требуются. В начале я пишу ужасный код. Я пишу код в одном глобальном объекте до тех пор пока понимаю, что делаю. Наиболее прокачанные программисты пишут хаки постоянно; важно, что вы выполняете свои задачи.

Не обесценивайте свою работу

Начинающие программисты, как правило, чувствуют, что их работа незначительна, так как они новички. Или, возможно, вы опытный программист, но работаете в новой для себя области, что заставляет чувствовать себя не комфортно. Как мне кажется, лучшие идеи исходят от новых людей, которые видят улучшения в существующих технологиях, у которых не “замылены глаза”. Ваша работа ст_о_ящая вне зависимости ни от чего. В худшем случае, если ваша идея не сработает, сообщество узнает, почему этот подход не имеет смысла (заметка для сообщества: всё это зависит от нас самих и мы должны быть открыты новичкам).

Избегайте чувства давления от того, что необходимо постоянно работать

Каждый день появляются новые технологии и возникает ощущение, что мир уйдёт вперёд без тебя, как только ты ляжешь спать. Это не так. На самом деле, вы будете лучше работать, если вы будете чаще отключаться. Ваш взгляд на задачу будет чище, и я замечал за собой, что подсознательно прихожу к новым идеям в моменты, когда не занимаюсь работой. Большая часть того, что придумывается каждый день - это лишь переосмысление старых идей. Действительно новые идеи появляются лишь раз в несколько лет. Хороший доклад на эту тему Hammock Driven Development.

Избегайте шелухи

Больше всего пользы в повышении скорости улучшения ваших профессиональных навыков - избегание “шелухи”, которая, на самом деле, повышает ваши умения совсем незначительно. Говоря по-другому - “используйте своё время мудро”. В сутках столько часов и если вы будете тратить их на более фундаментальные темы, то вы увидите значительную разницу с течением времени. Но что такое - “шелуха”? Это зависит от вас, но я могу дать несколько примеров, что я считаю “шелухой”: синтаксис языка, API библиотек и кофигурирование систем сборок. Изучение того, как работает компилятор, принесёт значительно больше пользы нежели изучение нового API ES7. Добавление в проект новой библиотеки, аналогичной существующей, но с новым API - не так важно. Всё это, безусловно, полезно, но я рекомендую тратить больше времени на изучение более глубинных концепций, которые будут вознаграждать вас в течение многих лет. Я бы хотел вас спросить: много ли времени вы тратите на то, чтобы ваш код выглядел “красиво”? Если ответ “да”, то я бы рекомендовал вам фокусироваться на этом меньше. Ваш код будет часто меняться. Гораздо важнее сконцентрировать на главной проблеме, которую вы решаете и думать усерднее над абстракциями. После того, как вы закончили со задачей потратьте немного времени на полировку вашего кода. (Это так же относится к принципу DRY. Не переживайте сильно по этому поводу. Будьте свободны в дублировании.)

Погрузитесь в исследования прошлого

Если вы вдохновлены какой-то идеей, очень соблазнительной будет мысль немедленно начать писать код. Но не стоит этого делать до того, как вы не проведёте беглое исследование того, как это задачу решали до вас. Исследование темы несколько дней всегда кардинально изменяет подход к решению задачи. Важно научиться читать академические статьи. Я не знаю ничего о денотационной/операционной/пр. семантике, что не позволяет мне понять многие статьи. Но есть много других, которые используют код вместо математики и которые читать значительно проще. Очень много знаний можно почерпнуть из статей, которые были написаны за последние 30 лет. Если вы разберётесь в этом, вы станете успешны в обучении. Хороший пример - Prettier. Я знал, что хочу сделать, но не представлял как это реализовать. После небольшого исследования я нашел эту статью и через несколько дней точно знал, что мне необходимо делать. Через неделю у меня было работающее решение. Если бы я проигнорировал предшествующий анализ, то это потребовало бы значительно больше времени. Если вы ищете статьи, то репозиторий Papers We Love на GitHub - отличное место для начала.

Беритесь за большие проекты. Выходите из зоны комфорта

Нет ничего лучше опыта. Не у всех есть возможность экспериментировать, но, если у вас есть время, попробуйте взять на себя большой проект. Вы не обязаны завершить его. Такая задача как создание своего компилятора даст вам тонны знаний уже в первые недели. Я ненавижу то чувство, когда не понимаю как решать сложную задачу. Это вызывает дискомфорт. Я знаю, что необходимо провести исследования перед тем как я приближусь к решению. Но после этого я всегда становлюсь лучше как программист. Начните с изучения нового языка. Это наиболее эффективный способ изменить ваши привычки и посмотреть на знакомые вещи с другой стороны. Для меня, когда я только начинал программировать, таким языком стал Scheme. Это невероятно простой язык, который вынуждает писать код в функциональной парадигме и позволяет понять основы того, как работает код. Несколько лет я провёл со Scheme и до сих пор иногда его использую; то, как я смотрю на код, фундаментально изменилось. (Я назвал свою компанию Shift Reset LLC в честь операторов shift/reset из Scheme). Вот список нескольких вещей, которые я рекомендую сделать. Всё это имело большой вклад в моё развитие как программиста. Многое из этого до сих пор приносят пользу различными способами и помогают мне деконструировать новые идеи в уме. Вы не обязаны выполнять всё это для того, чтобы стать хорошим программистом и есть много других способов повысить свои способности, но это то, что помогло именно мне:

  • Изучить C - только самые основы, если вы до сих пор их не знаете. Я думаю важно понимать, почему все жалуются на него
  • Написать компилятор - Наверное, лучший способ выйти из зоны комфорта и изучить что-то новое. Посмотрите на пример небольшого компилятора.
  • Изучите макросы - Посмотрите на Scheme, Lisp, Clojure(Script). Макросы реально изменят то, как вы смотрите на код.
  • SICP - это старая книга, которая актуальна и сегодня (некоторые могут со мной не согласиться). Эта книга содержит немного знаний по программированию, но позволяет реализовать meta-circular evaluator и компилятор. Другая книга, которую я могу порекомендовать погружает глубже в компиляторы - Lisp In Small Pieces.
  • Понимание продолжений (continuations) - Продолжения - низкоуровневый механизм для управления потоком выполнения программы. Scheme - единственный язык в котором реализованы продолжения. И даже если вы никогда не будете использовать их в production, они навсегда изменят способ которым вы думаете о потоке выполнения. В моём блоге есть пост, в котором я пытаюсь объяснить их работу.
  • Попробовать новый язык - Вне зависимости от того, чем вы занимаетесь, вы должны смотреть на другие языки. Я бы рекомендовал следующие: Clojure, Rust, Elm, OCaml/Reason, Go или Scheme. Каждый из них имеет уникальные возможности и могут помочь думать по-новому.

Оригинал статьи: [How I Became a Better Programmer](http://jlongster.com/How- I-Became-Better-Programmer).