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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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