Продолжаю работу с ментатами 🤓

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

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

Ребята кстати постоянно пишут, какие только детские ляпы не допускают даже сеньоры, вплоть до "магических чисел", а ведь это антипаттерн которому уже 1005000 лет, и описан в куче книг. Но когда вы работаете в мейнстриме, ничего другого от коллег кроме как big ball of mud ожидать не приходится.

Хотя мне сложно представить, какое должно быть окно контекста в голове программиста, чтобы одновременно управлять агентами для разработки ну например 3-х систем сразу. Где кривые требования (и то их и нет), путаница в терминах и в целом запутанная ПрО...

Окно контекста надо сворачивать в формальные спеки, в языки паттернов.

Не смог себе отказать в изучении language-ext. Ну уж слишком мне нравится генерить код linq query, монадами и другими прекрасными типами. В целом я посмотрел основные монады, которые мы проходили на вводном курсе State, IO, Either, Fin(Either<T,Error>), Validation, Reader, RSW, IO, Eff(новый), Option, коллекции. Да в целом этого вообще достаточно, чтобы писать 99.9 процентов тикетов, реально. Конечно, там есть и моноиды, группы, монады сырые и всё остальное. Новые higher kinded types конечно пушка, клод сгенерил NonEmpty<T,A> where T : Foldable и я был реально в восторге, что можно так делать.
Конечно я не понимаю всю механику, да и для начала и не надо...

Вы правильно говорите, что это всё "механика", думательные машинки, про это гайд "Функциональные архитектуры", но ключевым именно по механикам будет LPF.

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

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

Решается кстати легко: все такие абстракции давно классифицированы в математике, надо "просто" их изучить и научиться комбинировать.

Новый тимлид скептически относится к разработке на С#, и начал говорить прекрасные вещи, что он микросервис [на Go] с помощью ИИ написал за полторы недели, в то время как текущим сотрудникам требуется месяц и более :)
В общем мои коллеги по цеху это не оценили [что надо будет Go изучать] и начали обсуждать план сваливания, спрашивали и интересовались друг у друга как там дела на рынке, смешно было слышать в общем)...

(Так-то я давно ребят принуждаю к повторному перепроходу моего курса АСД на гошке. Ну а когда разработчики вместо того, чтобы порадоваться возможности - изучить новую темку за рабочий счёт - пугливо сваливают, туда им и дорога, на хх:)

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

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