Отписал

психотерапия, массаж, готовлю

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

еще вопрос про стресс - сделали ли вы все на работе, чтобы принятие решений не было стрессом. понятно, что есть решения СТО, от которых зависит будет ли будущее у стартапа, но у всех остальных решений цена ошибки не должна быть слишком высокой, no blame culture и всякие post mortem

I disagree but commit

это тоже хорошо, но из другой оперы

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

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

Отдых на выходных без телефона и ноутбука под рукой.

Прогулки по набережной. Сыграть в футбол.
Поботать что-то новое

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

В моей предыдущей команде мы активно использовали термин хук в контексте как-то внедрить новое без необходимости трогать старое.  В разных подсистемах мы под хуком понимали разные вещи - обработчик события/webhook/новый эвент/скриптинг/интерфейс/плагин/etc. Наша терминология немного отличалась от того, что принято считать хуком в программировании, но этот термин прекрасно зашел бизнесу.

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

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

Типичный пример:
dest = ”output/“ + current_date + “/“ + id + “/report.csv”
upload_file(dest, report)

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

Плодятся разные пути. Всегда проблемы с относительными-абсолютными. И фиг потом почистишь старое.

Почему так лучше?

вот чтобы не было таких проблем нужно исходить из того что все пути дадут на входе и ничего самому придумывать не нужно

Я понял о чем речь. Так удобнее, да. Но кодеры жалуются часто в итоге, что слишком формально всё, мол, ремесло и скука.

Если кодеры только на это жалуются, то их жизнь удалась

ну, тут есть обратная сторона - если всё кастомизировать, то получится конструктор) какой-нибудь там 1C/SAP (или даже какой-нибудь свой язык программирования в крайней стадии)

и потом уже надо будет писать код внедрения этого конструктора (по аналогии с тем, как системный интегратор внедряет вышеупомянутые системы) )

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

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