Борьба с собой не эффективна

Целые два года воевал с Юнити. Как результат низкая производительность, и постоянный поиск мотивации.
Их постоянные изменения и надстройки все ломали по мере внедрения.
Часто отваливались старые компоненты, потому что авторам уже не интересно их поддерживать.

Для программиста игр про вечерам их изменения слишком быстрые.
Можно было остаться и на старой версии, но она 4ка была очень ограничена и нормального интерфейса не было.

Потом появились двумерные инструменты, а сейчас переход на дата ориентированный подход.
Остановился на 2018.2, поскольку 3я все ломала.

Искал выход в виду defold, app game kit, Godot.
И пока смотрю в сторону последнего.
Радость программирования вернулась.

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

Слишком много энергии уходит на борьбу.

Самое сложное оказалось то, что привычки не вырабатываются легко у меня.
Один раз 228 дней вел дневник, и привычка не закрепилась. Хотя занимался в одно время и месте.

Поэтому после двух лет борьбы делаю вывод, что творчество должно идти от сердца, иначе ничего хорошего не сделаешь.
Да ещё и возненавидишь всем сердцем то над чем работает

Множественные выборы зло

Столкнулся опять с тем, что если у тебя есть несколько вариантов решения задачи и все они более менее идентичны по трудозатратам, то сталкиваешься с параличем выбора.

И хорошо если их два - монетка решить этот вопрос может. А вот когда их больше, то это перегружает разум.

Читал историю мороженщика, который продавал 43 видов мороженого. И люди загружались когда просили перечислить все виды. И покупали простое.

Он нашел решение - создал меню на каждый день. И выбрал 5 возможных вариантов

Люди были счастливы.

Так вот тут произошло то же самое. Выбор всегда сложен.

Просто надо взять один и откинуть остальные. Но сколько же боли в этом выборе.

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

Но при этом каждый процесс выбора все ещё мучительный.

Главное ну оглядываться назад и идти уже с тем, что взял.

Устаревшая документация и поиски истины

Разрабатываю календарь на devexpress и столкнулся с тем, что документация не подходит под последнюю версию Delphi.

Редактор вызывается по любому, даже если перехватывать нажатие на элемент и делать самому.
Благо есть исходники, но разбираться надо долго.

Как всегда надо за день что то сделать, а ты этого не знаешь и медитируешь над проектом и документацией, пытаясь понять что да как.

Подход к программированию по интуиции себя оправдывает, когда ты знаешь предметную область и применяемые библиотеки.

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

Получается, пишешь как в тумане и с ограничением времени.
Нужно что-то сделать уже сегодня.

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

Вообще перепатетизм от Аристотеля очень помогает в мышлении.
Ты гуляешь и мозгу поступает больше кислорода. А также эндорфины от нагрузки на мышцы.
В сумме ситуация очень хорошая для мышления и для тела.

Новые возможности в старых инструментах

Delphi ещё как то держится на плаву и даже развивается. Улучшили поддержку мобильных платформ и осовременили язык.
Правда среда глючная и тормозная осталась, но скорость компиляции все ещё на высоте.
Плюс читабельность и структурируемость кода хороша.

Если установить cnpack, то скорость разработки увеличивается.
Плюс ещё надо знать комбинации клавиш для того чтобы не трогать мышку.

Причем все эти комбинации пришли ещё с седьмой версией. Изучив vim понял откуда растут эти уши.

Программисты всегда искали способ быстрее программировать. И скажу комбинации Delphi удобнее и легче запомнить.

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

Поставил расширение vim для visual studio и получил прирост производительности в 20%, потому что своих команд хватает.

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

Счастье программирования и понимание связаны

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

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

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

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

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

Когда сочетаешь хорошую музыку, поток творчества и видение, происходят чудеса.

Документирование может быть интересным

Сегодня на проекте со старым кодом надо было сделать документирование так как он сделан по старым технологиям и очень длинные и сложные процедуры вместе с вызовами к данным и всё это в одном месте то документирование этого всего хозяйства очень непросто поскольку приходится постоянно на отследить что происходит в этом

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

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

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

И тебе приходится видеть несовершенный код и пытаться понять что же он делает поскольку в документации не нужно описывать что он делает надо писать зачем он это делает и как можно короче.

И поэтому мне приходится понимать что делает и итеративное улучшать документацию - то есть, надо сначала нарисовать диаграмму что делает потом с помощью блок схемы или всегда кода расписать общую логику что она делает.

Потом надо будет взять то что есть и понять зачем всё это происходит и вот когда из псевдокода пониимаешь зачем тут это нужно - писать документации.

Поэтому так и сложно документировать поскольку это итеративный процесс ты должен не просто понять а глубоко понять что происходит.

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

Поэтому нужно постоянно следить и предупреждать клиента твоего метода что будет не так. Это конечно зависит от реализации и очень сильно к этому привязано поэтому все ремарки нужно пересматривать когда меняешь код.

Сложный код и мотивация

Разрабатываю игру BoomTris.
Открыл и поиграл в неё. Вполне интересная несмотря на 4 года разработки (последние 2 в замедленном режиме).

Пытался понять в чём дело и что дальше делать - заглянул в HackNPlan и Trello.
Множество задач демотивирует. Даже текущие, которые видны в работе ничего не дают.

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

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

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

Мой класс TowerController связан со многими. Но как его уменьшить даже не представляю.

Как в книге "Шаг за шагом к достижению цели" рассказано, что надо задавать простые вопросы и делать простые шаги. И это реально помогает.

Для меня сейчас самое сложное  - понять как это работает и почему глюки происходят. Когда просто сидишь и думаешь, что же сделать? То приходишь к тому, что в голове пусто - это проснулся центр страха.

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

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

Самое забавное - код, который написал использует шаблон "Подписка" во всех возможных классах (от жизни до башен и сетки). И вот отладить это достаточно сложно.
Хорошо ещё Visual Studio позволяет пройтись по всем местам пошагово или расставить точки останова.

Излишняя или ранняя общность даёт отрицательный результат и эффективность работы падает. Думать о расширяемости надо с начала, но двигаться туда надо медленно.
Иначе сложность поглотит и ничего не останется.

Как в Бруксе "Мистический человеко-месяц" метафора асфальтового озера: "Можно вытащить одну ногу, но все остальное погружается, и ни гигант ни маленькое создание не может с этим справиться"

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

Создание тестовых утилит тоже сложная вещь. И часто сидишь и смотришь на код с пустой головой. Но когда просто начинаешь делать (как в молодости) и код сам льётся из под пальцев.

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

Асинхронное падение блоков, несмотря на то, что ушёл от физики в сторону своего движка перемещения - всё равно отлаживать сложно.
После попыток создания такого движка как в матч-3 стал уважать программистов "Treasures of Montezuma" ещё больше - у них там на вид полная ассинхронность падения и действий.

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

Поэтому оставляю это на 2ю версию. Надо просто выложить игру и доделать.
Потом можно будет нанять помощников для отладки.

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

Вот так игра со сложностью обернулась мне боком.
И главное - видеть проблему, принять её и начать пошагово исправлять.

Эффективность, самооценка и самомотивация

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

Только последнее время почему то боюсь приступать. Мало что понимаю.
Прочёл часть книги по Kafka и что-то понял. Надо читать дальше и экспериментировать.

Хорошо, хоть ещё не подгоняют.
Поэтому мне нужно просто сделать свою работу и получить удовольствие и деньги.

Надо бы перестать отвлекаться. Вон - наустановил много разных блокнотов (был OneNote, поставил joplin, zim, wikidpad, cherry tree, rednotebook)

При этом у меня уже есть vimwiki.
Так что вести записи достаточно легко, но что-то мешает.

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

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

Мне нужно просто теперь разогнаться и поднять уверенность в себе. Об этом и говорил Наполеон Хилл. Надо просто верить в себя и идти дальше.

Что этот пацан может знать о программировании - чисто манипулятивное: “Какое говно сделал” без указания что не так и как поправить. Пусть теперь варится в своём котле сам.

У меня за плечами 20 успешных лет. Мои проекты работали по 8-10 лет и прекрасно радовали клиентов без их изысков.
Вообще - фанатизм - это самое плохое, что может быть у программиста.
Программа должна работать, а иногда переписать даже быстрее, чем отлаживать текущий кусок.
Плюс множество библиотек.

Понимаю плюс чистого кода, но его надо применять с умом.

Документирование мыслей и протезы памяти

Как-то мне один знакомый спецназовец сказал, что не надо ничего хранить в голове, а записывать в блокнот.
Он его назвал: "протез памяти".

После этого уже 5 лет этим занимаюсь и это очень помогает.

Сейчас у меня проект, в котором вроде всё просто, но сама структура не простая.
Создавать диаграммы меня "разучили" - клиентам надо срочно, а документирование занимает время. Но при этом, как говорил Авраам Линкольн: "Если мне нужно пять часов рубить дрова - четыре я буду точить топор".

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

Как говорил Пойа: "Математическая проблема - как гора камней и мышь - решение. Ты просто ходишь вокруг и высматриваешь мышь. Двигаешь камни, убирая один за другим. И когда появляется возможность - хватаешь"

Так и тут - наваливается множество проблем. И в этом есть что-то странное. Раньше проблемы приносили удовольствие. Теперь же вызывают неприязнь.
Похоже, работая на кого-то ты можешь потерять себя.

Теперь ищу путь обратно (25 лет научили, что возвращаться всегда легче, когда знаешь ориентиры) к удовольствию от творчества.

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

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

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

Пользовался Zim и OneNote - пока предпочитаю последний. Zim - хорош для вики, но не совсем пока понимаю его работу. Хотя он помощнее будет, чет OneNote.
Синхронизацию документов можно сделать через OneDrive или GoogleDriver. Таким образом документация всегда будет сохранена в облаке.

Чувствую себя как муха - стукаешься об стекло проблемы, отлетаешь и обратно. И ничего не меняется. А всего лишь надо выйти на уровень выше.
Как говорил Эйнштейн: "Проблемы не решаются на том же уровне, что и возникли".

Сохранение концентрации всё сложнее

Поддерживаю web приложение на react/rails и постоянно приходится перезагружать после изменений. 

Вынос сервера на другую машину  помог, но всё же ноут c i7/8G не справляется и сайт приходится ждать по 30-50с на загрузку с нуля.

Это время нужно куда то концентрировать. Тупо смотреть на прогресс индикатор не мотивирует.

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

Одна проблема - вернуться в режим работы сложнее, поскольку у тебя уже другой фокус внимания.

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

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

С ютубом сложнее. Нужно его ещё и скрывать позади документов. Пробовал его держать на втором мониторе, но это бесполезно. 

Раньше эффективность поддерживала моментальная компиляция (как в Pascal/Delphi, так и в C#)

Веб-разработка, особенно большого приложения с кучей компонент на React имеет этот лаг. И его надо заполнить чем-то продуктивным, но легко отбрасываемым, когда сервер и браузер таки отобразят готовый сайт.

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

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

Получаешь два в одном - и протокол работы со справочной информации для себя будущего (или чтобы ввести в курс дела "молодого бойца")

И отвлечение, которое полезно.

Учитывая, что на написание дневника тратится сила - не будет проблемой переключиться и оставить его. 

Звук, а что ещё хуже - видео на фоне сильно отвлекает.