Автор статьи — Джеймс Лонг, один из создателей Firefox Developer Tools
Несколько человек на React Conf спросили у меня совета, как программировать лучше. По какой-то причине люди видят во мне продвинутого программиста, к советам которого стоит прислушаться. Я подумал, стоит записать «ментальную модель» того, как я подходил к программированию на протяжении всех лет.
Некоторая информация: мне 32 года и 10 лет твёрдого опыта. Наверное, только в последние пару лет я приобрёл уверенность в том, что делаю. Но даже теперь я продолжаю сомневаться в себе. Дело в том, что это чувство никогда не уходит, так что старайтесь не обращать на него внимания, продолжайте хаки и накапливайте опыт.
Сразу скажу, что здесь всего несколько советов для улучшения своих способностей. В итоге вам нужно самим выяснить, что лучше всего подходит именно вам. Это просто те вещи, которые я посчитал полезными.
- Ищите людей, которые вас вдохновляют, но не боготворите их
За годы было много людей, на которых я смотрел с уважением и следил за новыми технологиями. Я многое узнал просто доверяя их мнению и изучая вещи, над которыми они работают. Как правило, эти люди были очень плодотворными, яркими и вдохновляющими. Ищите их и позволяйте вдохновлять и учить вас.
Однако не нужно их боготворить. Из ленты твиттера легко выглядеть страшным, но если посмотреть, как они работают в реальной жизни, то увидите, что они не такие выдающиеся. Везде хаки и т.д. Все мы просто экспериментируем. Наконец, не доверяйте слепо им; если не согласны, привлеките внимание и получите опыт от общения. Некоторые из моих самых плодотворных бесед произошли именно таким образом.
Мой конфиг Emacs в бардаке. Я не знаю, почему у меня сломано автодополнение OCaml (уже более месяца). Я не автоматизирую вещи и приходится иногда копаться в истории шелла, чтобы найти нужные команды. Сначала я пишу самый уродливый код. Я насаживал всё подряд на глобальный объект пока не осознал, что делаю. Даже самый опытный программист постоянно использует хаки; самое главное — доводить дела до конца.
- Не принижайте свою работу
Новички часто думают, что их работа не имеет значения, потому что они новенькие. Или может вы опытный программист, но работаете в новой области, где не чувствуете себя комфортно. По моему мнению, некоторые из лучших идей предлагаются именно новичками. Они видят возможность улучшить существующие вещи, к которым уже привыкли опытные люди со сформировавшимся мнением.
Ваша работа всегда имеет ценность, неважно что. В худшем случае, даже если ваша идея не сработает, сообщество получит лучшее понимание, почему именно этот подход не имеет смысла. (Заметка для сообщества: с нашей стороны, следует учитывать это и быть приветливыми к новичкам).
- Не нужно заставлять себя работать всё время
Когда новые технологии выходят каждый день, создаётся впечатление, что вы отстанете от мира, если пропустите вечер без работы. Это не так. На самом деле вы будете лучше работать, если надолго отключаться. Взгляд станет свежим, а мне самому подсознательно приходят новые идеи, когда я не работаю.
Бóльшая часть ежедневных новинок — просто старые идеи в новой упаковке. Действительно революционные вещи появляются раз в несколько лет. Хорошая лекция на эту тему — Hammock Driven Development.
- Не отвлекайтесь на мишуру
Один из лучших способов объективно ускорить своё развитие — просто игнорировать «мишуру», которая реально не улучшит ваши способности очень сильно. Другими словами, грамотно распределяйте своё время. В сутках определённое количество часов, и если вы потратите их на более глубокие вещи, то со временем заметите большую разницу.
Так что такое «мишура»? Зависит от вас, но могу привести некоторые примеры, что я считаю мишурой: синтаксис языков, API библиотек, конфигурация инструментов сборки. Изучение нового синтаксиса сборки ES7 JS не сделает из вас лучшего программиста по сравнению с изучением работы компиляторов, например. Применение новой библиотеки, в которой реализована та же идея, но с новым API, не так уж интересно. Всё это важно, конечно, но я рекомендую уделять больше времени на изучение более глубоких концепций, которые принесут эффект на годы вперёд.
Я люблю задавать такой вопрос: уделяете ли вы бóльшую часть времени, чтобы сделать код «красивым»? Если так, рекомендую не обращать на это столько внимания. Ваш код всё равно будет сильно изменяться со временем. Лучше чётко сфокусироваться на корневых проблемах, которые стоят перед вами, и хорошенько подумать об уровнях абстракции. Когда разберётесь со всем этим, можно потратить немножко времени на полировку кода. (Это также относится к принципу DRY. Не беспокойтесь сильно о нём. Не стесняйтесь повторять информацию на уровнях абстракции.)
- Изучите прошлые исследования
Если вас волнует какая-то идея, то не терпится поскорее сесть и немедленно начать. Нельзя делать этого, не проведя хотя бы беглое изучение того, как другие решали эту проблему раньше. После нескольких дней изучения задачи я всегда полностью изменял предполагаемый способ её решения.
Очень ценное качество — научиться читать научные статьи. Я ничего не знаю о денотанационной/оперативной и другой семантике, так что многие статьи не могу читать. Но во многих используется код вместо математики, и их читать не очень сложно. Просто гигантское количество знаний накоплено в статьях за последние 30 лет. Если вы научитесь хорошо извлекать его, то станете настоящим лидером мнений практически мгновенно.
Prettier — отличный пример. Я знал, что именно хочу получить, но вообще не понимал, как. После недолгих поисков я нашёл эту статью и через несколько дней точно знал, что нужно делать. Через неделю уже был базовый рабочий прототип. Если бы я проигнорировал предыдущие исследования, всё заняло бы гораздо больше времени.
Если вам нужны научные статьи, то репозиторий GitHub Papers We Love — хорошее место для начала.
- Беритесь за большие проекты. Почувствуйте дискомфорт
Нет ничего лучше, чем опыт. Не у каждого есть возможность экспериментировать, но если у вас есть время, то пробуйте и беритесь за большие проекты. Даже не нужно их заканчивать. Просто попытка одолеть нечто вроде написания компилятора даст вам массу новых знаний в первые же недели.
Честно, я ненавижу ощущение, когда понятия не имеешь, как решить сложную проблему. Это неприятное чувство. Понимаешь, что придётся изучить массу материала и многое понять, чтобы хоть немного приблизиться к решению. Но я всегда в итоге становлюсь намного лучшим программистом.
Начните с изучения нового языка. Это самый эффективный способ заставить себя выйти из круга текущих привычек и посмотреть на вещи в новом свете. Для меня лучшим, что я сделал в юности, было изучение Scheme. Этот исключительно простой язык заставляет писать вас писать всё в функциональном стиле и действительно изучить основы того, как работает код. Несколько лет, которые я потратил на Scheme, до сих пор приносят мне пользу; мой взгляд на код фундаментально изменился. (Я даже назвал свою компанию Shift Reset LLC по названию операторов shift/reset в Scheme).
Вот список нескольких вещей, которые я бы рекомендовал сделать. Все они оказали огромное влияние на мою карьеру программиста. Большинство из них до сих пор продолжают приносить пользу косвенным образом и помогают мне ментально демонтировать новые идеи. Вам не нужно делать это, чтобы стать хорошим программистом, есть много других способов для этого, но это помогло лично мне.
- Изучите C − Просто основы, если вы их ещё не знаете. Я думаю, важно понимать, почему все на него жалуются.
- Напишите компилятор − Наверное, лучший способ почувствовать дискомфорт и обучиться новым знаниям. Взгляните на суперкрошечный компилятор.
- Изучите макрокоманды − Посмотрите Scheme, Lisp или Clojure (Script). Макрокоманды по-настоящему изменят ваш взгляд на код.
- SICP − SICP («Структура и интерпретация компьютерных программ») — это старая книга, которая по-моему до сих пор актуальна (некоторые с этим не согласны). Она требует совсем небольшого знания программирования от читателя и ведёт вас по всему пути к созданию вычислителя с явным управлением и компилятора. Ещё одна книга, которая мне действительно понравилась и которая погружается намного глубже в компиляторы, — это Lisp In Small Pieces (в русском переводе — «Интерпретация Лиспа и Scheme»).
- Поймите продолжения − Продолжения — это низкоуровневый механизм порядка выполнения программы. Scheme — единственный язык программирования, в котором реализованы продолжения, и в то время как вы никогда не использовали их в деле, они изменят ваше представление о порядке выполнения. Я написал пост, пытаясь объяснить продолжения.
- Если что, просто попробуйте новый язык − Неважно чем вы занимаетесь, действительно стóит изучать новые языки. Я бы рекомендовал любой из следующих: Clojure, Rust, Elm, OCaml/Reason, Go или Scheme. У всех них есть уникальные функции, и они заставят вас усвоить новый способ .
Автор: m1rko
