Comments 30
Замечательная статья!
Сам перешёл к простым методам логирования выполненных задач и планов в Ворде.
Усилий - 10 минут в день. Отдача - всегда ясно, что предстоит сделать и что уже сделано. Особенно такой подход помогает в прдготовке к еженедельным созвонам с начальством, на которых надо рассказать о том, что было сделано за неделю.
На каждый день есть две записи - достижения (что сегодня сделал, чем воообще занимался) и проблемы (что не получилось, опиисание проблем). В принципе, в день получается как минимум 3 строчки (дата, заголовок, строка с выполненными задачами), По сути, так как документ исключительно мой, добавляются описания воспроизведения ошибок, размышления, варианты писем. На самом деле, годичный лог всех задач - это менее 100 страниц текста.
В самом верху списка пишу список всех моих задач. Со ссылками на "баг-трекер" (лукавлю, конечно, у меня там воообще список всех задач группы, да, все 20 штук).
Ибо KISS есть самый базовый принцип всего! :-)
KISS это просто приём из демагогии.
Если строго следовать принципу простоты, тогда весь код надо писать в main одной сплошной простынёй. Все эти разбиения кода на функции, классы, модули, всё это переусложнение. Никакой типизации - типы данных это сложно. Никаких юнит тестов, никакой документации - к чёрту все эти переусложнения, keep it simple stupid.
Возможно вы скажете, структуризация и типизация кода, а также написание юнит тестов и ведение документации это никакое не усложнение, а наоборот механизмы уменьшения сложности. Но это уже демагогия. Т.к. факт заключается в том, что всё вышеперечисленное это усложнение кода. Да, наверное это усложнение через некоторое время себя оправдает и сделает процесс разработки проще. Может быть. Но так можно сказать про любое усложнение, что это усложнение вовсе и не усложнение, а инвестиция в упрощение в будущем. И тут уже всё будет решаться не на объективных фактах, а кто кого авторитетом задавит, тот и прав. Поэтому KISS это никакой не базовый принцип всего, а всего лишь приёмчик из демагогии.
Спасибо за комментарий!
Тут правда можно долго размышлять, но по итогу во всем хорош баланс - классы, тесты и документация - оправданное усложнение, которое за приемлемые затраты дает хороший результат в виде качества кода, удобства сопровождения и тд.
Но если продолжать усложнение, то дальше мы за все большие усилия будем получать все меньшие усилия. Например, если будем писать огромную документацию где только можно в ущерб скорости разработки и другим задачам
Это проблема крупных компаний, где для согласования изменения цвета нужно пройти 5 кругов ада
вполне себе базовый принцип всего, просто чуть по другому интерпретируется - keep it sql, stupid. это как раз оно, когда вместо статьи на 18 экранов текста можно написать три строчки сиквел кода из которых одна intersect🤷♂️
сложность должна быть оправдана, и здесь она оправдывается как никак хорошо: поддерживаемость, расширяемость и стабильность (почти всегда это требования)
Так и надо начинать писать - одной простыней в мейн. Без классов и типов. А потом по мере написания - еще дальше упрощать код путем поиска повторяющегося кода и выноса его в отдельные функции. А потом еще больше упрощать путем объединения похожих функций в классы. А потом еще больше упрощать себе жизнь добавлением типов. Так рождается идеальная архитектура, где нет ничего лишнего и все запредельно просто
Очень странное представление о простом, как о тупом.
Потрясающая статья! Я сам столкнулся с тем, что стараюсь всё "оптимизировать" в том же Obsidian, по папкам разложить, несколько плагинов, шаблонов. А вышло так, что я месяц туда не заходил и ничего не писал. На компьютере стоит Arch Linux, над которым я периодически думаю "А как бы тебя улучшить", хотя мог бы просто пользоваться))
И статья как раз о том, что вместо самой работы, мы пытаемся обустроиться, чтобы нам было хорошо работать. А уж про "Давайте напишем микросервисы" я молчу.
Автору спасибо, буду перечитывать статью и закреплять советы, откликнувшиеся внутри меня
Наполен откладывал проверку почты до самого последнего момента - к этому моменту все мелкие вопросы уже решались самостоятельно.
А потом гугл удалил его аккаунт разработчика
Очень хорошо написано. Мне бы год назад это прочитать. На самом деле буквально удалила все подписки, тулзы, кроме двух. И стала быстрей работать, и качество лучше и стресс ушёл.
Спасибо за обратную связь! А чем пользуетесь?
Из платных остались только ChatGPT и Canva.
В них все делаю, от мини-тулзов до ютуба. До этого были всякие ИИ и для SEO и для копирайтинга и для создания блогов из ютуба и для пинтереста. И в результате я с каждым по отдельности боролась или искала функции, читала документации, переписка с поддержкой, постоянно какие-то дополнения выходили. Аж голова кружилась. Снесла все.
Теперь стало все очень просто и легко. Все нужные мне функции изучены до мозга костей, ничего не нужно искать или изучать. Если там что-то новое и добавляется, то не каждую неделю. Поэтому для каждой новой функции появилось время для полного внимания и фокусирования.
И еще отписалась от всего. Оставила только две рассылки. Все остальное - в топку. Зато время читать рассылки появилось, а не просто в папке "почитать" копить.
База. 2 года руковожу проектами, при этом половину терминологии в статье не понял. Пользуюсь блокнотом и Microsoft To Do. Итог: запущенный с нуля продукт в нескольких странах + ведение уже готовых проектов, где заказчик и бизнес довольны. Конечно в идеале нужно было бы прочитать PMBOOK, но этот талмуд скорее убьет меня, чем я осилю его.
Автор обжигался на излишней сложности, но видимо не обжигался на обратном. Когда сервис, написанный как можно быстрее, с монолитным кодом и вендор-локом повсюду, взлетает и быстро падает, потому что не выдерживает скейлинга, а для новых фич нужно разбивать код и переписывать этот говнодел полностью. Крайне неверный посыл, что разработка хочет делать сложнее, разработка просто понимает, что произойдет в будущем, если не дожать какой-то слой абстракций. Кластер для сайта продажи кофе и отдельный сервис для стаканчиков - это преувеличения, в реальности выбор способа деплоймента всегда имеет какое-то обоснование
Вы привели хороший пример оправданной сложности, если развивать ваш пример, я бы сказал, что излишнее усложнение - это добавлять возможность быстрого масштабирования и отказоустойчивости там, где это не нужно.
Хороший пример от Карла Вигерса - в одном из проектов добились отказоустойчивости системы и сделали время работы 99,99% от всего времени ценой огромных средств и большого количества времени. Нужен ли такой показатель везде? На мой взгляд нет, и чуть большее время простоя тоже приемлемо
Вы написали сложную статью о том, что все должно быть просто только для того, чтобы этим комментарием дезавуировать ее, признав, что нужно правильно выбирать уровень сложности, а не тупо делать "все сложно" или "все просто". Теперь осталось понять: правильно определить необходимую сложность - это просто или сложно?.. :-)
Простота в хорошем смысле - это сложно, дорого, на первых порах долго и требует квалификации. И редко где встречается. Потому что простота - значит читаемый, логичный и понятный код. Видел к сожалению очень мало компаний, которые в это действительно могут. В большинстве случаев из стартапа уже взрослый проект не вырастает психологически, бизнес не принимает, что в подавляющем большинстве стартапный быстропродукт надо выбрасывать и делать новый, с которым жить уже взрослой компании. А это совсем непросто и недешево. И скорее всего нужны будут новые кадры. Но без этого ваша компания утонет в бесконечных косяках созданного "простого" франкенштейна, и по итогу скорее всего перестанет существовать.
Боже, как же я неистово плюсую этой статье. Меня вся эта гонка продуктивности за 17 лет участия в ней загнала в такие дебри невроза, что я уже и забыл, как это - просто что-то делать, не запланировав сорок тайм-блоков в календаре и не создав пару тикетов в Трелло.
Гонка продуктивности нужна не программистам, она нужна бизнесу. И заканчивается она там, где заканчивается терпение разработки и дается понять, что будете еще давить - будете сами проект делать. А так бизнес всегда будет отодвигать планку, а программист всегда будет не успевать и виноват. А "сгорит" - наймут следующего, тоже мне беда. До поры, пока бизнес не поймет, что текучка и дешевый найм угробил проект, если поймет вообще. Возможно, умирая от говнокода и бесконечных багов он снова будет винить программистов))
Нет никакой проблемы сделать просто и нет никакой проблемы сделать сложно. В этом я убеждался на десятках крупных проектах, с которыми приходилось работать. Настоящая сложность и искусство - это правильно попасть в баланс между крайностями для конкретного проекта.
Вы постоянно осваиваете новые инструменты, но никогда не применяете их на практике. / Это я
Ваш «идеальный календарь» требует столько же усилий, сколько сама работа. / Это я
30% рабочего времени сотрудники тратят на заполнение тикетов и отчёты о процессе / Это я
Для вас теперь важнее процессы, а не результат. Спринты, ретро, планирования и доски в Jira становятся важнее кода. / Это я
Dynalist для ведения текущих планов, и долгосрочного списка дел вплоть до 2030. Стал забывать гораздо меньше сделать, с одной стороны, и меньше держать в долговременной памяти, с другой.
Однако исключительная удобность паривела к взрывному росту заметок "по поводу" и выписок, сортировать которые - отдельная плохорешаемая задача.
Поэтому помимо папки 2025.04 есть с десяток папок "завтра","сегодня" и "отпуск". Эту проблему пока не решил
И да, и нет.
Например, покупка сложной камеры - простое решение. Оно линейное, а не комплексное, не включает в себя обучение, насмотренность и так далее.
Сложнее != лучше — почему простые советы работают, а вы их избегаете