Уповзище

Программирование - это мандала. Мы собираем сложный узор из цветных песчаных дорожек кода, чтобы затем безжалостно смахнуть всё в корзину. Редкие, очень редкие программы и библиотеки проживают в неизменном виде хотя бы десяток лет. Большинство продуктов просто умирают за ненадобностью (многие - ещё до рождения). Большинство из оставшегося меньшинства за это время проходят через три-четыре смены технологий и радикальные обновления версий.

Программирование - это практический дзен. Обычное дело: неделю читать документацию, две недели писать прототип, чтобы взглянуть на него, признать: "Не то", - и удалить. Обычное дело: пускать в архив (синоним корзины, потому что никто никогда туда больше не заглянет) годовую работу команды, потому что у заказчика изменились приоритеты или закончился бюджет. Обычное дело: проектировать систему так, чтобы любой элемент легко было оторвать, выбросить и заменить. А потом отрывать, выбрасывать и заменять.

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

Мало работ, где процесс столь ценен, как в работе программиста, учитывая уровень зарплат и типичное продуктивное время (часа четыре в сутки, не считая выходных). Мало работ, где результат ценится столь ничтожно (в среднем, учитывая всё сотворённое, а не только задержавшуюся у пользователей верхушку айсберга). Мало работ, где необходимо с такой скоростью бежать через поток новых знаний, чтобы только оставаться на месте.

В этой профессии выживают и задерживаются только просветлённые. (Ну и местами столь же целостно-бесхитростные идиоты - там, где их ещё не заменили автоматизацией и не смахнули в корзину). Только те, кто способны сохранять интерес и самоуважение, всю жизнь непрерывно отправляя в ничто все результаты своей напряжённой работы. Потому что важен только процесс здесь и сейчас.

Ассертивное поведение считают эталоном здорового конструктивного общения и отношения к жизни. Я с этим, в общем, согласен. Ассертивный человек выглядит сильным, уверенным, надёжным, в меру жёстким, но одновременно и внимательным, гибким, сочувствующим и так далее. Однако сложность ассертивности не только в том, что для неё надо извести стадо собственных тараканов, но и в том, что идеально она работает только с такими же ассертивными людьми. Невротизированные собеседники могут принимать эту позицию за чёрствость, холодность, наглость, слабость, обман - всё что угодно из своего привычного спектра. В общем итоге ассертивность даёт приличные результаты даже тогда, но что хорошие люди всегда могут договориться - это романтичная иллюзия.

Любопытно, как это перекликается с принятым в программировании подходом "делай, а не спрашивай". Суть его в том, что перед вызовом метода не следует городить многократные проверки того, а действительно ли та сторона находится в нужном состоянии, правильно проинициализирована и в целом готова к такому запросу. Вызывающий код пишут так, как будто с той стороны всё готово и сработает как обещано контрактами. Если что-то там не так - это задача вызываемого метода сообщить о проблеме, бросив исключение (разбираться с которым будет уже вызывающий, в отдельной ветке кода). Такой подход сильно упрощает код и делает его нагляднее. Но нормально работать он будет только тогда, когда вызываемый тоже написан в том же духе, и будет бросать исключения, а не молча творить ошибочную хрень.

Это не просто два разных подхода - это два разных мира. В одном все многократно переспрашивают всех, ведут долгие вступительные разговоры, догадываются о состоянии партнёра, и рассчитывают на то, что с ними обойдутся так же. В другом все прямо и явно говорят, что они сейчас чувствуют, думают и чего хотят, и ожидают, что если партнёру что-то не подходит, то он так же прямо об этом и скажет, и тогда можно будет поискать альтернативы. Ассертивный мир проще, спокойнее и эффективнее. В мире намёков и догадок зато больше переживаний, даже определённой вычурной эстетики. Никакой вариант не универсален. В ассертивном стиле лучше вести дела, зато стиль намёков идеально подходит для флирта, поэзии и игры. Главное - не смешивать.

А в программировании обязательные условия, которые всегда-всегда должны исполняться, иначе всё пропало и сплошная ошибка, почти во всех языках называют assert.

Тезисы сегодняшнего доклада Романа Сидорченко на симпозиуме:

* Программисты думают сложными абстракциями. Не образами, не метафорами, не силлогизмами. Многоуровневыми многопоточными абстракциями. Просто потому что постоянно работают с ними, а переключаться между способами мышления - затратно.

* Как следствие, все программисты способны к глубокому, длительному трансовому сосредоточению (состоянию потока). Эта способность - и профессиональное показание, и профессиональная деформация. Программист норовит войти в рабочий транс по любому вопросу, который стоит размышлений.

* Всё сущее программисты категоризируют по удобным критериям. То, чему не удаётся дать компактное рабочее определение и разложить по категориям - не существует, потому что с ним невозможно работать.

* Гармонию, красоту и соразмерность сложных структур программисты чуют интуитивно. Потому что иначе со сложными абстракциями работать не получается. Дисгармония вызывает острое ощущение неправильности и почти физическое отвращение.

* Отстранённая метапозиция по отношению к чему угодно, которой психотерапевтов долго специально учат, у программистов встроена.

* "Вылечить" психику программиста до общечеловеческих стандартов - значит, с большой вероятностью, сделать его профнепригодным. Потому что потеряются вышеперечисленные особенности.

* Хотите работать с программистом? Выработайте общий разговорный словарь и не лезьте трогать в его психике то, что и так работает.

( Дополню своими наблюдениями )

В здешнем здании довольно разветвлённая сеть дверей и коридоров. За дверью может оказаться не комната, а коридор, некоторые двери в нём ведут в другие коридорчики, за некоторыми дверями скрывается тамбур и ещё несколько дверей. Но всё тщательно пронумеровано, на каждой двери висит табличка с полным путём к ней. Например, тут неподалёку есть комната с номером 5.3.3.4.А.

Языки программирования с ленивыми вычислениями не захватили весь мир только потому, что этот результат им пока ещё ни для чего не понадобился.

Зарегистрировался как ФОП (частный предприниматель) смешанного психолого-программистского профиля. Оказалось удобно, что я ещё не ушёл с программистской работы, тут есть бухгалтеры, которые взяли на себя вообще все усилия с оформлением. А там дальше уже разберусь.

Я худо-бедно владею тремя профессиями, плюс ещё на несколько смотрел со стороны, и во всех натыкался на эти грабли. Я начинаю думать, что это глобальный закон. Формулируется он так:

Во всякой профессии есть изнанка, без которой основное дело невозможно или бессмысленно. Изнанка требует качеств перпендикулярных или прямо противоположных тем, которые потребны для основного дела. Она плохо делегируется, потому что правильно сделать изнанку может только человек, глубоко знакомый со спецификой основного дела.

( Например... )

Можете добавлять примеры из своих областей.

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

Наш админ завёл сову.
Приучает её к рукам.
В холодильнике уже припасены мыши.

Пока я настойчиво стараюсь уйти из программистов в психотерапевты, многие люди переучиваются в разработчиков или тестеров. Меня иногда спрашивают, на что смотреть и с чего начинать в этом деле (изучать "программирование как иностранный"). Я в некотором затруднении, потому что сам-то я учился этому четверть века назад, и практически всё с тех пор потеряло актуальность.

Думаю, что порекомендовать можно такое:

• Выучить английский до уровня "свободно читаю технические статьи, учебники и документацию". В программировании без этого никуда.
• Базовое руководство по избранному языку и программированию вообще. Например, A Byte of Python.
• Найти и пройти подходящий курс программирования для начинающих на Курсере.
• И какой-нибудь углублённый курс. Например, Intermediate and Advanced Software Carpentry in Python.
• Основы паттернов проектирования. Можно начать с википедии на эту тему.
• Самостоятельные упражнения. Code Kata.
• Общая философия и психология программирования. The Programmers' Stone. Сюда же: The Pragmatic Programmer (книга не бесплатная, но сканы при желании легко найти; к тому об этом есть статьи, справка-шпаргалка и вики с основными принципами).
• Практические советы по организации процесса и рабочим подходам. Joel on Software, колонка Reading lists.

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

Upd.: Я пополняю список по мере поступления комментов. Стараюсь держать его именно в рамках вводной для начинающих. Например, Structure and Interpretation of Computer Programs - книга великая, но не в самом начале.