До 2017 года уже несколько дней… Самое время судить о результатах моих прошлогодних новогодних обещаний, если бы я их принял. Вместо этого я хотел бы написать об одной вещи, которая изменила мой подход к работе в этом году. Он изменился не в результате решения, а в результате встречи с замечательным программистом и руководителем группы, который показал и напомнил мне, что когда-то люди учились вещам именно так. В 2016 году как программист я вернулся в библиотеку — и мне стало хорошо!

Книга — странная вещь в 2017 году. Не имея кнопки поиска, она вряд ли решит стоящую перед вами сейчас проблему. Это вряд ли принесет немедленную прибыль. Тяжело носить с собой, может быть неудобно читать в трамвае или поезде или во время какого-либо другого ожидания в наши дни. Требует места, времени и внимания — все товары в дефиците.

Многочисленные статьи и исследования убеждают нас в том, что мы учимся на практике и на практике, а не по книгам. Особенно в ИТ-индустрии мы сейчас одержимы этим — какой смысл думать, если за одно и то же время можно закодировать три разных прототипа? Изменения — это новая константа, нет смысла планировать заранее… несколько лет назад мы смеялись над PHP-программистами, сегодня мы смеемся над архитекторами башни из слоновой кости с их расстоянием и книгами. Десятки или сотни развертываний в день, каждая мысль и идея моментально опробована и проверена на практике — не похоже на мир, в котором чтение книг имело бы какой-то смысл. Вам понадобится месяц или два, чтобы прочитать книгу, и это время четырех двухнедельных итераций, и к тому времени у вас будет целый новый набор проблем, которые нужно решить.

Но книги — это нечто большее и нечто иное, чем инструменты для решения насущных проблем. «Эрудированность» — устаревшее слово в нашем мире эффективности, решения проблем, прототипирования и мгновенных результатов поиска. Но «эрудиция», в то же время, это как раз то, что позволит вам распознавать проблемы, к которым вы подходите, когда-то уже решенные. Именно это качество позволит вам находить закономерности, замечать связи и аналогии. Меня иногда удивляет моя неспособность что-то «погуглить». Глядя на проблему, у меня возникает ощущение, что кто-то, должно быть, уже решил ее, и статистически маловероятно, что я первый программист, пытающийся найти решение. Тем не менее, я не могу найти решение в Google. Часто дело в моей неспособности назвать некоторые вещи и ввести правильный поисковый запрос. Что бы мне помогло, так это чтение хорошей книги заранее, которая дала бы мне язык и рамки для моих запросов.

Позвольте мне на мгновение быть менее практичным… Быть программистом — значит быть ремесленником, учиться владеть инструментом. Всегда круто и приятно наблюдать за человеком, который является мастером своего дела и работает с любым инструментом так, как будто он родился с ним на руке, но, в конце концов, важно то, что он сделал с инструментом и как они использовали свое мастерство. И книги для меня — это способ запомнить это, вдохновение для того, чтобы применить свои навыки.

В этом году я понял, что с некоторых пор я почти полностью перестал думать и думать о том, что я должен сделать. Меня затянуло во все эти эффективности, «не пытаться, а просто делать»; Я стал слишком полагаться на дисциплину и привычки. Как будто тот факт, что я способен писать чистый и красивый код, как-то связан с тем, что этот код делает. Как программист, меня утешает тот факт, что все не может пойти слишком плохо, если вы двигаетесь только с небольшими постепенными изменениями, не так ли? Я втянулся в agile, devops и несколько других безумств, начав чувствовать себя в безопасности и освободившись от размышлений. Можно сказать, что именно поэтому мы вырабатываем привычки, правила, условности и практики — чтобы освободиться от мышления… но это может зайти слишком далеко, чувствуя себя как цель.

Когда в этом году я пошел в библиотеку, я снова научился уважать книги. Некоторые из них были как дыхание для моего мозга; дал мне очень необходимое расстояние. Помог мне заново научиться сосредотачиваться, садиться и делать только одно дело; не ожидая немедленного возврата или решения проблемы сразу.

Итак, вот мой список книг за 2016 год, которые стоит прочитать, и отдельные мысли, оставшиеся после каждой из них. Это ни в коем случае не резюме, а выбор или мысли, вдохновленные книгой.

Личный

  • Даниэль Канеман — «Мышление быстрое и медленное»

Наш мозг и чувства могут быть запрограммированы и сильно подвержены влиянию того, что мы слышим или видим, и у нас нет возможности предотвратить это. Событие, знание об этом не помогает. Поэтому очень важно заботиться о качестве и правдивости того, что вы видите, слышите и читаете. Немало правды и в поговорке «Кто с волками дружит, тот и выть научится»…

  • Малкольм Гладуэлл — «Выбросы»

В 2017 году легко обмануться тем, сколько у нас возможностей и контроля над своей жизнью. Для большинства из нас это приводит к неизбежному чувству поражения и сожаления, когда выбранные нами возможности не приводят к большому успеху и реализации. «Выбросы» снимают с вас это бремя, напоминая, как сильно удача (хорошая или плохая) влияет на нашу жизнь. Прекрасные примеры того, как для многих важно оказаться в нужное время и в нужном месте, могут заставить вас чувствовать себя немного менее критично по отношению к себе.

  • Нассим Николя Талеб — «Антихрупкость: вещи, которые выигрывают от беспорядка»

Очень утешительная книга. Мы живем в мире, в котором «изменения — это новая константа», и как бы мы это ни отрицали, это болезненно. Каждое изменение имеет свою цену и требует от нас узнать что-то новое, иметь дело с новыми чувствами и людьми. Это страшно. «Антихрупкость» может принести некоторое утешение, предоставив способ и философию, чтобы справиться с этим фактом; даже больше; получить от этого прибыль. Новый универсальный способ борьбы с изменениями.

  • Эммануэль Каррер — «Le royaume (Королевство)»

Интересное чтение для тех, кто когда-либо боролся с (не)христианством.

IT

  • Джин Ким, Кевин Бер, Джордж Спаффорд —«Проект Феникс: роман об ИТ, DevOps и помощи вашему бизнесу…»

Еще раз напомним, что в ИТ важно решать правильные задачи. Инструменты важны, но они нужны для решения актуальных проблем. Также заставил меня скептически относиться к возможности заставить что-то работать в команде, которая не может сидеть за одним столом (потому что люди разбросаны по миру, например, в разных часовых поясах).

  • Майкл Т. Найгард — «Выпусти!»

Вероятно, одна из первых книг по DevOps. Чувствовал себя немного устаревшим, но содержал действенный совет по проблеме, с которой я сталкиваюсь всегда… Какой уровень регистрации ошибок я использую, когда? Я не видел ни одной тактики для этого, которая бы хорошо работала — мои логи всегда в беспорядке и нечитабельны для любого человека без знания кода. Предложение из книги состоит в том, чтобы использовать уровень журнала «ОШИБКА» тогда (и только тогда), когда ошибка требует вмешательства обслуживающего персонала.

  • Эрик Эванс — «Дизайн, ориентированный на предметную область: решение сложных задач в основе программного обеспечения»

Классический и полный хороших идей и полезной лексики. Среди прочего, напомнил мне, как важно использовать правильные слова и иметь возможность общаться с другими, используя тот же набор словарного запаса. Подчеркивает важность языка и общения между командами, программистами и экспертами в предметной области. Помогает выявлять проблемы и решать их до того, как они проявятся в виде сложного, бессвязного беспорядка в коде.

Есть некоторые программисты, которые странным образом гордятся тем, что мало говорят; которые оправдывают свою неспособность ясно писать или говорить тем, что они «программисты», «интроверты» или «имеют строгий, математический» ум. Большое предупреждение, чтобы не стать одним из них (и одна из причин, по которой я решил начать обучение письму).

Нет ничего плохого в том, чтобы быть кратким, но краткости иногда просто недостаточно.

  • Сэм Ньюманн — «Создание микросервисов: проектирование мелкомодульных систем»

Больше вопросов, чем ответов, но они указали мне направление «Domain-Driven Design» ;)