My personal experience is that it depends on the context. Writing new functionality is usually easy if it's self contained. If I know what inputs I will have a

My personal experience is that it depends on the context. Writing new functionality is usually easy if it's self contained. If I know what inputs I will have and what outputs I want, then I generally have a pretty solid idea of how to derive one from the other before the first keystroke. But if I find that the new functionality is turning into an internal API that will be consumed in multiple places for multiple use cases, things aren't so obvious anymore. You have a combinatorial explosion of design parameters: not just inputs, outputs, and algorithm, but also issues like ownership of data, ownership of the stack, which inputs are supplied at which point in the process, when is it legal to consume outputs and in what ways, push vs. pull interface, two functions for similar functionality vs. one with a flag. When the design parameter space gets this large, it's hard to reason about it ahead of time, and sometimes the most straightforward API doesn't reveal itself until you write code that uses it and realize that there's needless boilerplate or inconsistency that opens up room for logic errors. Then you go back and refactor to eliminate that. Casey Muratori calls this iterative process semantic compression [1]. I don't agree with all his software development takes, but I think he hits this one pretty squarely on the head. The key insight is that an experienced programmer can write good code on the first pass, but it usually takes a second pass to write great code. [1] https://caseymuratori.com/blog_0015 https://caseymuratori.com/blog_0015