Programming is hard
<i>&quot;Not so much on how we can more effectively understand requirements and translate these into code.&quot;</i><p>The first step to understanding requirements: There needs to be a requirement worthy of the name.<p>Because let&#x27;s face facts: programmers are quite often confronted with &quot;requirements&quot; cooked up by some &quot;stakeholder&quot; that don&#x27;t even describe the problem domain, much less a path to how it should be modeled.<p>A lot of the spaghetti that contemporary production code ends up looking like far too often, is programmers having to play a stupid game of &quot;chase the nebulous and ever changing &#x27;requirements&#x27;&quot;.<p>Once you develop for A but then B is required as well, and the architecture didn&#x27;t anticipate that, you may be able to go back and change it ... or not, because usually the requirements change, but the deadlines don&#x27;t, and good luck doing the same, or more, work all over again, in half the time.<p>Yes, programming is a hard problem. It really is. But it is also quite often being <i>made</i> harder than it needs to be.