Як я став кращим програмістом?

Переклад. Оригінал тут

Декілька людей на React Conf запитали мене про те, як стати кращим програмістом. З якихось причин люди бачать в мені висококласного спеціаліста, до думки якого варто прислухатися. І я подумав, що є сенс описати мою “модель мислення”, мій підхід до програмування, якого я дотримувався роками.

Трохи про мене: мені 32, і я маю більше 10 років професійного досвіду. І лише впродовж останніх декількох років я справді став почуватися впевнено в тому, що я роблю. Хоча навіть зараз я продовжую багато в чому сумніватися. Справа в тому, що це відчуття невпевненості не зникне з часом, тож постарайтеся ігнорувати його, просто продовжуйте кодити і набиратися досвіду.

Будьмо чесні, я вам дам лише декілька порад щодо того, як покращити свої навички. Але, зрештою, вам самим потрібно буде зрозуміти, що є ефективним особисто для вас. А я наведу підказки, які були корисними саме для мене.

Знайдіть людей, які вас надихають, але не робіть із них ідолів

Протягом років було багато людей, яких я поважав і за чиїми досягненнями спостерігав. Я багато що вивчив, просто довірившись їхній думці і розбираючись з речима, над якими вони працювали. Зазвичай, такі люди дуже продуктивні, визначні, вони надихають. Знайдіть таких людей і дозвольте їм вчити вас і надихати.

Але переконайтеся, що не зробите з них ідолів. Доволі легко здаватися страхітливим у своїй стрічці у Twitter. Але в реальному житті перед нами, скоріш за все, буде звичайна людина. Людина, що також пише код і експериментує, як і ми. Не довіряйте сліпо людям. Якщо ви з чимось не погоджуєтесь, то обговоріть це з людиною і винесіть щось корисне із спілкування. Деякі з моїх найпродуктивніших розмов відбулися саме таким чином.

В моєму Emacs конфігу - безлад. Я не знаю, чому в мене не працює автокомпліт для OCaml. Я не автоматизую роботу і мені доводиться нишпорити в історії консолі, щоб знайти потрібну мені команду. Я пишу жахливий код спочатку. Зберігаю дані в глобальних перемінних до того часу, поки не зрозумію, що мені потрібно. Найбільш досвідчені програмісти користуються хаками постійно. Головне, що ви закінчуєте роботу.

Не применшуйте значимість своєї роботи

Новачки у програмуванні схильні думати, що їхня робота не дуже важлива - вони ж новачки. Або, можливо, ти - досвідчений програміст, який починає працювати із новим напрямком, - це також може змусити почуватися дискомфортно. Я думаю, що новачки здатні пропонувати чудові ідеї, адже вони бачать можливі покращення існуючої технології. Ті ж, хто уже сформував своє бачення, можуть на це просто не звернути уваги.

Ваша робота важлива, незважаючи ні на що. В гіршому випадку, якщо ідея не спрацювала, ком’юніті уже буде знати, чому в такому підході немає сенсу. (Зауваження до ком’юніті: те, наскільки доброзичливо ми будемо поводитись із новачками, залежить від нас)

Не почувайтеся змушеними працювати весь час

З усіма цими технологіями, які виходять щодня, може здатися, що ви упустите щось дуже важливе, якщо візьмете вихідний. Це неправда. Насправді ви будете працювати краще, якщо навчитеся переключатися. Ваш погляд на речі буде свіжішим. Я зауважив, що деякі мої нові ідеї народжуються в підсвідомості, саме коли я не працюю.

Більша частина технологій, що виходять кожного дня, - це уже відомі ідеї, переказані новими словами. По-справжньому революційні ідеї виникають раз на декілька років. На цю тему є хороша доповідь Hammock Driven Development.

Ігноруйте беззмістовні речі

Один із найшвидших шляхів покращити свої вміння - це ігнорувати беззмістовні речі, які не сильно вплинуть на ваші навички. Іншими словами - мудро використовуйте свій час. Не так уже й багато часу в одному дні, і якщо ви будете витрачати цей час на більш усвідомлені речі, то ви скоро відчуєте різницю.

Що таке “беззмістовні речі”? Це залежить від вас, але я наведу приклади речей, в яких, на мою думку, немає змісту. Це синтаксис мови, API бібліотеки, конфігурація build tools. Наприклад, вивчення синтаксису нового ES7 JS не покращить ваші навички програмування настільки, наскільки може покращити вивчення роботи компілятора. Застосовувати в роботі бібліотеку, яка вирішує ту ж задачу, але з іншими АPI, не дуже і цікаво. Це все, звичайно, важливо, але я рекомендую проводити більше часу, глибше вивчаючи основи, які будуть корисні протягом багатьох років.

Питання, яке я люблю задавати: чи проводите ви більшу частину свого часу, роблячи ваш код красивішим? Якщо так, то рекомендую не фокусуватися на цьому. Все одно ваш код зміниться з часом. Краще сфокусуйтеся на фундаментальних проблемах і добре подумайте над шарами і абстракціями вашого додатку. Після того, як ви успішно впораєтесь із ними, ви можете витратити трохи часу на вилизування коду. Це ж відноситься і до принципу DRY (Don’t repeat yourself). Не переживайте щодо нього надто сильно, можете спокійно дублювати.

Копайтесь в дослідженнях попередніх років

Якщо ви в захваті від якоїсь ідеї, дуже заманливо одразу сісти і працювати саме над нею. Однак не поспішайте з цим, краще здійсніть швидке дослідження того, як інші люди уже реалізовували цю ідею чи вирішили якусь проблему. Дослідивши якусь проблему впродовж кількох днів, ви точно знайдете новий спосіб її вирішення.

Навчитися читати наукову документацію - цінний навик. Не знаєш нічого про денотативну/операційну/тд семантику - існує купа матеріалу на цю тему, з яким ти б міг ознайомитись. Водночас, є багато документації, де використано код замість математики, і її не так уже й важко читати. В таких матеріалах накопичилась величезна кількість знань. Якщо ви навчитесь виокремлювати знання з цієї документації, то станете лідером думок.

Наочний приклад Prettier. Я розумів, що я хочу зробити, але не розумів, як. Після коротких пошуків я знайшов цей документ. Почитавши його кілька днів, я вже знав, як реалізувати мою ідею. За тиждень у мене вже був робочий додаток із базовим набором функцій. Якби я не прочитав цей документ, витратив би значно більше часу на імплементацію.

Якщо ви шукаєте наукову документацію - цей репозиторій буде хорошим стартом. Papers We Love

Візьміться за великий проект. Вийдіть із зони комфорту

Немає нічого кращого, ніж досвід. Не кожен має можливість експериментувати, але якщо у вас є час, то беріться за великий проект. Вам не обов’язково доводити його до кінця, але енергійна робота над чимось типу компілятора навчить вас багато чому вперше за декілька тижнів.

Я щиро ненавиджу ситуацію, коли я не можу вирішити якусь проблему, це неприємно. Я знаю, що мені доведеться багато шукати і вивчати в надії, що я зможу добратися до рішення. Але в результаті я завжди стаю кращим як програміст.

Почніть з вивчення нової мови програмування. Це найефективніший спосіб вивести вас із звичного стану і побачити речі в новому світлі. Найкращим, що я зробив, коли був юним програмістом, було вивчення Scheme. Це доволі проста мова, змушує писати все у функціональному стилі і допомагає зрозуміти, як працює код. Ті декілька років, які я провів, вивчаючи Scheme, досі приносять мені користь. Мій погляд на код кардинально змінився. (Я навіть назвав свою компанію Shift Reset LLC на честь shift/reset команд із Scheme)

Ось іще декілька речей, які я б рекомендував зробити. Це те, що мало великий вплив на мою кар’єру програміста. Більшість із цього досі приносить користь і допомагає мені розібратись у якійсь ідеї. Вам не обов’язково робити все із того, що я вказав, щоб стати хорошим програмістом. Є багато інших речей, які допоможуть покращити себе, але ті, які я вказав, допомогли саме мені.

Вивчіть С - тільки основи. Я думаю, що доволі цінним є розуміння, чому ж усі на нього жаліються.

Напишіть компілятор - мабуть, найкращий спосіб чомусь навчитися і вийти із зони комфорту. Зацініть the super tiny compiler.

Вивчіть макроси - гляньте на Scheme, Lisp або Clojure(Script). Макроси дійсно вплинуть на те, як ви бачите код.

SICP - SICP - це стара книга, яка, по-моєму, досі актуальна (дехто із цим не згоден). Вона не потребує багато знань в області програмування і описує процес побудови компілятора від простого до складного. І ще одна книга, яка мені дуже подобається, розповідає детально про компілятори Lisp In Small Pieces

Розберіться із continuations - Continuations - це механізм управління виконанням коду на низькому рівні. Scheme - це єдина мова, в якій реалізовано цей механізм. І хоча ви не будете використовувати їх у продакшені, вони допоможуть вам змінити розуміння, як працює управління потоками. Я написав пост, де постарався пояснити їх.

За можливості, гляньте на нову мову програмування - Вам варто вивчати нові мови програмування, незалежно від того, чим ви займаєтесь. Я б рекомендував будь-яку з цих: Clojure, Rust, Elm, OCaml/Reason, Go або Scheme. Кожна з них має унікальні особливості, які допоможуть вам розвинути в собі новий спосіб мислення.