Как писать меньше кода и получать больше толку

Страшные вещи пишет автор: «если вы преследуете цель писать меньше кода, нужно стремиться к максимально простой реализации, из разряда «лишь бы работало»». По моему скромному мнению, метод написания «тяп-ляп» не выход, я бы скорее выделил идею переносить большую часть проверок из кода в тесты.

Все бы ничего, однако, согласитесь, это не всегда работает. Я думаю нет смысла придираться к частностям, так как в других комментариях уже это сделали, но все же лично меня больше всего задел пункт, с котором я никак не могу согласиться — Не пишите неуязвимый код. Где та грань между НЕ неуязвимым кодом и говнокодом или же на скорую руку собранным дерьмом непонятного качества. Требуемого качества пересечения этой границы помогают достичь тесты, ревью коллег и некоторые другие инструменты и способы улучшения кода, но вот что делать тем кто работает один или совсем небольшими командами?

P.S. Как всегда не стоит забывать что все советы это конечно хорошо, но личный удачный/не_удачный опыт ничем не заменишь

Советы для кого? Для сферического программиста в вакууме?
Есть задачи, которые так решать нельзя. Пример с аппаратом для лучевой терапии тому подтверждение.
Если хотите писать меньше кода, нужно заложить в разработку больше математики.
Большинство интерактивных программ хорошо описывается конечным автоматом. Честно построив модель и получаем хорошее т.з. на минимально-необходимое программирование.
Да, не все «побочные» ветви необходимо сразу реализовать в виде подробного анализа нештатной ситуации. Достаточно стандартного сообщения.

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

А вот на счёт остального скажу — такие рекомендации и без того часто понимают превратно. Вообще, много раз убеждался, что любую разумную идея можно довести до абсурда. И особенно могу сказать про первые два пункта, во что это скорее всего превратится в реальности. Умельцев внедрят функциональность самым примитивным способом хоть отбавляй. После этого соответствующие задачи переходят в статус выполнено и включать в очередной sprint время на refactoring редко кто топорится. Вместо этого реализуется дальнейшая функциональность со всё новыми костылями. В итоге очередную новую функцию становится нереально в сколь-нибудь сопоставимые сроки реализовать без новых костылей, как ни хотелось б. Ну и далее характерный реальзтат, когда исправление одной ошибки создат другую ошибку.