> With regards to the article's example, refactoring your code for unit tests is making life easier for the computer, not humans. And maybe that's why Bill is a

> With regards to the article's example, refactoring your code for unit tests is making life easier for the computer, not humans. And maybe that's why Bill is annoyed, being human and all. Maybe the tradeoff is actually between: A. short term productivity / speed of development -- use longer functions without factoring out non-repeating code excessively B. long term maintainability -- short and easily testable functions are definitely better So use approach A. to code an MVP and approach B. for a decade-lasting enterprise application on whose development tens of people will rotate? Oh, and... please, if you language allows you, use closures / functions inside function when you factor out a small bit of code that does not repeat, NOT private methods or non-exported functions! This increases code locality it's obvious that one line helper is used only once. And of course, give the mini-functions meaningful names, otherwise there is no point in doing this in the first place - you only factor out to increase readability. And prevent the mini-helpers from using variables from outer scope too much (if your mini-helper uses 5 outer-scope variables, then DON't factor it into a mini-helper). (Advice above is extracted from a talk inspired by smth J. Carmack wrote, but can't remember exactly what...)