Автор статьи — Джеймс Лонг, один из создателей Firefox Developer ToolsНесколько человек на React Conf спросили у меня совета, как программировать лучше. По какой-то причине люди видят во мне продвинутого программиста, к советам которого стоит прислушаться. Я подумал, стоит записать «ментальную модель» того, как я подходил к программированию на протяжении всех лет.
Некоторая информация: мне 32 года и 10 лет твёрдого опыта. Наверное, только в последние пару лет я приобрёл уверенность в том, что делаю. Но даже теперь я продолжаю сомневаться в себе. Дело в том, что это чувство никогда не уходит, так что старайтесь не обращать на него внимания, продолжайте хаки и накапливайте опыт.
Сразу скажу, что здесь всего несколько советов для улучшения своих способностей. В итоге вам нужно самим выяснить, что лучше всего подходит именно вам. Это просто те вещи, которые я посчитал полезными.
- Ищите людей, которые вас вдохновляют, но не боготворите их
За годы было много людей, на которых я смотрел с уважением и следил за новыми технологиями. Я многое узнал просто доверяя их мнению и изучая вещи, над которыми они работают. Как правило, эти люди были очень плодотворными, яркими и вдохновляющими. Ищите их и позволяйте вдохновлять и учить вас.
Однако не нужно их боготворить. Из ленты твиттера легко выглядеть страшным, но если посмотреть, как они работают в реальной жизни, то увидите, что они не такие выдающиеся. Везде хаки и т.д. Все мы просто экспериментируем. Наконец, не доверяйте слепо им; если не согласны, привлеките внимание и получите опыт от общения. Некоторые из моих самых плодотворных бесед произошли именно таким образом.
Мой конфиг Emacs в бардаке. Я не знаю, почему у меня сломано автодополнение OCaml (уже более месяца). Я не автоматизирую вещи и приходится иногда копаться в истории шелла, чтобы найти нужные команды. Сначала я пишу самый уродливый код. Я насаживал всё подряд на глобальный объект пока не осознал, что делаю. Даже самый опытный программист постоянно использует хаки; самое главное — доводить дела до конца.
- Не принижайте свою работу
Новички часто думают, что их работа не имеет значения, потому что они новенькие. Или может вы опытный программист, но работаете в новой области, где не чувствуете себя комфортно. По моему мнению, некоторые из лучших идей предлагаются именно новичками. Они видят возможность улучшить существующие вещи, к которым уже привыкли опытные люди со сформировавшимся мнением.
Ваша работа всегда имеет ценность, неважно что. В худшем случае, даже если ваша идея не сработает, сообщество получит лучшее понимание, почему именно этот подход не имеет смысла. (Заметка для сообщества: с нашей стороны, следует учитывать это и быть приветливыми к новичкам).
- Не нужно заставлять себя работать всё время
Когда новые технологии выходят каждый день, создаётся впечатление, что вы отстанете от мира, если пропустите вечер без работы. Это не так. На самом деле вы будете лучше работать, если надолго отключаться. Взгляд станет свежим, а мне самому подсознательно приходят новые идеи, когда я не работаю.
Бoльшая часть ежедневных новинок — просто старые идеи в новой упаковке. Действительно революционные вещи появляются раз в несколько лет. Хорошая лекция на эту тему — Hammock Driven Development.
- Не отвлекайтесь на мишуру
Один из лучших способов объективно ускорить своё развитие — просто игнорировать «мишуру», которая реально не улучшит ваши способности очень сильно. Другими словами, грамотно распределяйте своё время. В сутках определённое количество часов, и если вы потратите их на более глубокие вещи, то со временем заметите большую разницу.
Так что такое «мишура»? Зависит от вас, но могу привести некоторые примеры, что я считаю мишурой: синтаксис языков, API библиотек, конфигурация инструментов сборки. Изучение нового синтаксиса сборки ES7 JS не сделает из вас лучшего программиста по сравнению с изучением работы компиляторов, например. Применение новой библиотеки, в которой реализована та же идея, но с новым API, не так уж интересно. Всё это важно, конечно, но я рекомендую уделять больше времени на изучение более глубоких концепций, которые принесут эффект на годы вперёд.
Я люблю задавать такой вопрос: уделяете ли вы бoльшую часть времени, чтобы сделать код «красивым»? Если так, рекомендую не обращать на это столько внимания. Ваш код всё равно будет сильно изменяться со временем. Лучше чётко сфокусироваться на корневых проблемах, которые стоят перед вами, и хорошенько подумать об уровнях абстракции. Когда разберётесь со всем этим, можно потратить немножко времени на полировку кода. (Это также относится к принципу 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 — единственный язык программирования, в котором реализованы продолжения, и в то время как вы никогда не использовали их в деле, они изменят ваше представление о порядке выполнения. Я написал пост, пытаясь объяснить продолжения.
- Если что, просто попробуйте новый язык ? Неважно чем вы занимаетесь, действительно стoит изучать новые языки. Я бы рекомендовал любой из следующих: Clojure, Rust, Elm, OCaml/Reason, Go или Scheme. У всех них есть уникальные функции, и они заставят вас усвоить новый способ мышления.
Комментарии (32)
ilya_pu
23.03.2017 09:07+3Изучать прошлые исследования в надежде найти там готовое решение — хороший способ для решения простых, рутинных задач, которые наверняка кто-то уже решил (из разряда «не стоит изобретать собственный велосипед»). Правда, для очень лёгких задач может оказаться быстрее состряпать велосипед, чем найти готовое решение. Для задач нетривиальных поиск готовых решений полезен тем, что в итоге можно получить разные варианты решения схожих задач (разные мнения), и уже исходя из этого — выстроить нечто собственное, «стоя на плечах гигантов». Оценка проблемы «незамыленным» взглядом — да, это всегда полезно, но… является ли взгляд человека, не приступившего ещё к изучению способов решения поставленной задачи (проблемы) незамыленным? Во-первых, у него уже по-любому будет определённый опыт решения более или менее похожих задач (вы просто не сможете решить задачу, если она совершенно не похожа на те, которыми вы занимались раньше — например, если вы всю сознательную жизнь растили пшеницу, а вам предлагают заняться строительством буровой установки, то вы или ничего не сможете построить, или должны будете изучить строительные технологии и науки вроде сопромата, теории грунтов и прочих специфических тем, то есть фактически получить некоторое строительное образование). Так что в решении задачи вы в любом случае будете опираться на собственный опыт (в том числе накопленный в ходе собственно попыток решения). Во-вторых, «незамыленный взгляд» действительно помогает найти решения — но исключительно в силу того, что человек с таким взглядом не следует шаблонам, а оценивает решение в целом и каждый отдельный шаг, постоянно задавая себе вопросы («а почему это так?», «а как можно сделать ...?» и т.п.). Если поставить задачу перед человеком, который продолжает задаваться этими вопросами несмотря на свой опыт, вес в обществе, авторитет и прочее, то он найдёт решение более эффективное, чем новичок (сила вопросов будет подкреплена силой знаний). Но — да, таких людей найти сложно, поскольку все мы любим ходить одними и теми же дорожками, найденными в те годы, когда трава была зеленее, а деревья — выше…
AlexZaharow
23.03.2017 09:12+1Но даже теперь я продолжаю сомневаться в себе. Дело в том, что это чувство никогда не уходит, так что старайтесь не обращать на него внимания
Я думаю, что это ошибочный совет. Нужно не перестать обращать внимание на это чувство, а использовать его, чтобы разобраться в чём дело. Ведь не спроста же оно возникло? Я недавно размышлял на тему возникновения этого чувства и пришёл к следующему выводу. Когда вы учитесь программировать по книгам или в институте, то при формулировке задачи пытаетесь найти набор ключевых слов, которые подскажут вам решение или применение тех или иных технологий. Но в задачах, которые вам попадаются в реальной жизни может не быть знакомых вам ключевых слов, либо они будут использованы в неверном контексте, что ещё больше сбивает с толку. Так что по-хорошему, чтобы вернуть себе чувство уверенности, нужно научится правильно интерпретировать задачу в свой опыт. А опыт у вас есть уже с рождения.
waverunner
23.03.2017 10:57+1Добавлю: но не перестарайтесь с возвратом уверенности. Большая уверенность тоже плохо. Как говорится: лучше перебдеть, чем недобдеть.
AlexZaharow
24.03.2017 06:18Я уже давно замечаю, что хороший код и метафизика взаимосвязаны. :)
waverunner
24.03.2017 14:47Идеальный код недостижим так же, как невозможно ответить на вопрос о первичности материи и духа)
AlexZaharow
27.03.2017 14:39Так его в принципе и невозможно написать, т.к. всё зависит от контекста. Так что хорошая постановка задачи всё-таки важнее. Выходит, что дух первичнее? )
strannik_k
23.03.2017 10:07Никогда не понимал советов изучать новые языки. Если они в основном только синтаксисом отличаются, то это относится к мишуре, как сам автор и написал. Конечно, какая то польза будет, но будет и вред — начнешь путаться в синтаксисе. Видимо, автор тут плохо выразил свою мысль.
Я бы на его месте советовал изучать парадигмы программирования. А новый язык стоит изучать, если он построен на неизученной парадигме.
Хоть это и более долгий путь, но было бы также полезным поизучать другие отрасли программирования. Например, в геймдеве чаще предпочитается использование композиции вместо наследования, что позволяет избегать сложных иерархий классов и зависимостей.
QtRoS
23.03.2017 10:23+6C# и Java да, можно сказать только синтаксисом, но справедливо ли так говорить про Go и Haskell, например?
Cromathaar
23.03.2017 15:36-2Об этом strannik_k и сказал — изменение парадигмы. C# и Java — ОО парадигма, Haskell — функциональная, Go — вообще говоря, процедурный.
Alexeyco
24.03.2017 12:32-1Go — тоже ООП. Просто в тамошнем ООП проблемы с инкапсуляцией… да и наследование там, мягко сказать. Зато полиморфизм вполне ж себе. (сарказм)
waverunner
23.03.2017 10:58Да, отличаются синтаксисом, но зачем городить здоровенный огород на одном языке, если эту же задачу можно решить на другом языке парой-тройкой операторов. Можно ведь вообще только на Си прогать или на асме)
TheOleg
23.03.2017 18:00Платформа, например. Обычно, всё-таки, нельзя придти в проект на php/java/.net и сказать «а вот тут, мы будем использовать отдельную программу на питоне».
waverunner
24.03.2017 14:50Разумное замечание, но внутри платформы тоже бывают языки с кардинально разной спецификой, скажем, c# (любимый) и APL касательно оперирования массивами
Revertis
23.03.2017 11:16-4Rust отличается от «обычных ЯП» очень сильно. И не только синтаксисом, а парадигмой и мышлением. Требуется вывихнуть себе мозг для того, чтобы начать на нем программировать, но потом начинаешь получать кайф от того, что намного лучше понимаешь, как работает программы, где лежат данные, у кого на них есть ссылки и так далее.
ookami_kb
23.03.2017 11:49+1Композиция вместо наследования много где предпочитается, это один из советов банды четырех.
Cromathaar
23.03.2017 15:42Композиция и наследование — это инструменты. Любым инструментом можно правильно пользоваться, а можно злоупотреблять, но говорить, что молоток надо предпочитать пассатижам — в корне неверно.
ookami_kb
23.03.2017 16:04Не совсем верная аналогия. Молоток и пассатижи все-таки предназначены для выполнения разных работ. Да, можно пассатижами забивать гвозди, но лучше использовать для этого молоток.
Для обеспечения полиморфизма и повторного использования кода можно использовать и композицию, и наследование. Чаще всего композиция предпочтительнее, дизайн становится гибче. Да, в некоторых случаях наследование окажется удобнее, но таких случаев меньше.
Создатели реакта, например, сознательно убрали возможность наследовать компоненты, оставив только композицию.
FadeToBlack
23.03.2017 12:13+1Невозможно взять и не тратить время на мишуру. Нужно сначала изучить многое, иначе не будет понятно, что такое мишура. Нельзя взять и не заморачиваться на кодестайле. Нужно сначала научиться ставить каждый символ на свое место. Нельзя сразу взять и стать уверенным в себе. Нужно сначала понять, чего ты стоишь. Нельзя взять и начать писать программы просто, нужно сначала пройти путь от простого к сложному и обратно. Нельзя стать программистом, срезав путь. Чтобы срезать пути, нужно изучить их, пройдя прямой дорогой.
NexOtaku
23.03.2017 12:56+1От себя могу порекомендовать брать эпизодически фриланс-проекты, даже если у вас есть постоянная работа.
Работая в одной команде и одном стеке технологий годами, можно застрять в развитии.
Если брать проекты, которыми уже занимались другие команды разработчиков, можно почерпнуть для себя много полезного — и по архитектурным решениям задач, и по инструментам.
Ну и на своей работе, стараться выбирать себе задачи посложнее и требующие изучения новых областей. Так ваш профессиональный уровень быстро вырастет.
reiser
23.03.2017 15:18Интересный совет, это из личного опыта?
C чего начать? Как находить и забирать небольшие, но интересные проекты «на вечер»?
При условии отсутствия какого-либо опыта с фрилансом конечно же.
Suvitruf
23.03.2017 17:21Не обязательно именно фриланс, можно к какой-то команде присоединиться парт тайм. Но всё зависит от области. Если это web, то на любой фриланс бирже можно найти небольшие задачки. Если это, к примеру, gamedev, то там сложно небольшие задания найти.
NexOtaku
25.03.2017 07:57Да, из личного опыта.
Как начать — зарегистрироваться на бирже фриланса. Брать можно небольшие проекты, либо сайты «на поддержку». В основном заказчиков интересует, сколько часов в неделю можете работать. Кого-то может устроить неспешная работа по выходным и час-два в будни.
Suvitruf
23.03.2017 17:23+1От себя могу порекомендовать брать эпизодически фриланс-проекты, даже если у вас есть постоянная работа.
Я поэтому обычно советую менять место работы раз в пару лет. Это в любому случае хорошо бы делать, чтоб получить повышение з/п, так как редко можно особо большую прибавку выбить на текущем месте.
Работая в одной команде и одном стеке технологий годами, можно застрять в развитии.
lookid
23.03.2017 22:22От себя могу добавить несколько пунктов:
1) Не растекайтесь мыслью по древу. Сконцентрируйтесь на 1 области. Не языке, а именно области. Сейчас всё очень компактно и локанично. Нету того, что все всё пишут на С и без него никуда.
2) Примите, как правило, что существуют реальные задачи, которые можно решить за 1-2-4 часа. Не превращайте изучение технологий в прожигание часов и дней. Если вы не можете что-то понять или выучить за 1-2-4 часа, то решайте конкретно эту проблему. А не "ночку посижу, поучу и пойму".
3) Отдыхайте. Человеческий мозг плохо работает после 3-4 часов неприрывной нагрузки.
4) Добейте уже до конца слепую печать. Если еще не добили.
5) Правило 21 дня. Привычка прививается за 21 день. Это касается всего. Иностранного языка, качества кода, питания, сна и вообще всего. Если у вас есть проблема в работе, то её можно исправить за 21 день. Если не исправилось, то значит проблема в другом.
6) Поборите рассеянность и перестаньте отвлекаться.
7) Не берите работу на дом.
Идеализированно получилось, но если убрать бытовые причины и ссоры с коллегами и коллективом, то работает.
Советы из статьи реально странные:"Я стал лучше программировать из-за того, что всё время стал учить С, писать GCC и читать СЕКП". Понятно, что чтобы лучше программировать нужно больше программировать. Но про перегорание не сказано. А оно лечится не просто. И посреди проекта взять и слинять на месяц никто не даст.
mibii
26.03.2017 22:17А как Вы относитесь к мысли о том, что всё уже
украденонаписано до нас. И я думаю, что со мной многие согласятся в том, что разработка сейчас и разработка лет 10 назад — это две большие разницы. Сейчас всё сводится к банальному увязыванию между собой горстки библиотек и плагинов/экстеншенов к ним.
Sdima1357
«Изучите прошлые исследования»
Не совсем согласен. Чаще стоит сначала самостоятельно оценить проблему " незамыленным" взглядом, а только потом ознакомиться с другими подходами.
TheKnight
Выше на два пункта.
Pakos
Часто путают «незамыленный» взгляд и полное отсутствие понятия о предметной области, хорошо видно на примере сайнс-фриков, которые породили всякую «новую физику», потому как не осилили существующую.