На самом деле никакой это не манифест.

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

Я на протяжении своей инженерской жизни (не такой уж длинной, но какая есть, хуле) временами ловлю абсолютно тупые косяки с проебом времени, ресурсов и нервов, которые проистекают не из проблемы хардскилов, а из-за некорректного образа мысли, e.g. построить сложную архитектуру с нуля, а не поэтамно переходя от сложного к простому. Или, например, забить на мелкий косяк в логах, который постоянно мелькает в контексте проблемы потому что он кажется нерелевантным (нет, блядь, он релевантный. А сейчас дочитай манифест, а потом пойди и займись процессом поиска связи этого мелкого косяка с общим контекстом проблемы)

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

Как соберется нормальная стопка заметок - издам книжку лет через 30, если доживу.

Погнали. Tут все пока что в перемешку, позже разобью по категориям от приземленных идей “Я делаю” к более абстрактным “Я могу влиять на то, как делаю, но думаю однообразно” к вообще имбовым техникам, тобишь “я могу влиять на то как я думаю, что влияет на то, как я делаю”

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

Engineering manifesto

Handle Exceptions and errors. ALWAYS.

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

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

In distributed systems, suspicion, pessimism, and paranoia pay off.

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

Use single data source, make sure that there is no hidden cyclic data dependencies.

А вот это достаточно забавный случай, который я отловил за пару часов. Но само решение кейса заняло около месяца и два раза требовало рефакторинга (считай два-три дня в сумме проебал, работаю я обычно часов 10/день)

Всегда рисуй граф потока данных. В нем не должно быть циклов, даже если это кажется безопасным. О каких циклах идет речь? Речь идет когда Узел А на вход может получить данные из узла Б, а узел Б всегда отправляет выходные данные в узел А. Казалось бы - выглядит такая схема эволюции данных бредово, но это до тех пор, пока у нас абстрактные кубики с буквами внутри.

Кейс из жизни - надо было мне для заказчика написать ротацию сертификатов в инфраструктуре. Процесс генерации был следующий:

  1. Сгенерировать файлы
  2. Послать в хранилище
  3. Достать конфиг из хранилища
  4. Собрать конфиг для конечного пользователя, положить в шару
  5. Make sure that data flow does not contain any sort of cycles. The engineering of low-latency systems is a discipline of removing abstractions.

ТУДУ - продолжить позжеg