D&D for short. Oh, wait. Nevermind, D&D is a way of splitting the creation of code into two fundamental pieces; design and development.
Disclaimer: Given that software development is a large and multifaceted industry there are a multitude of needs and constraints all pulling left and right which creates unique challenges and problems. The D&D view is probably not very applicable to say web development since my personal viewing point lies with low level rendering code most of the time and thus probably affects what I deem as good or bad.
Credits to Kodsnack (podcast in Swedish, link) for raising this to my awareness. It made me realise that when I am writing code I have two core modes that I am usually alternating between. The first one is the design mode. This is where I will write pseudocode or code that won’t compile since I got this design idea in my head that I just want to get down before I forget about it. Sometimes I get into this mode whenever I get a new idea of how to design an API that feels right or makes more sense. Being free of the constraint of being correct makes the iteration cycle almost non-existent and thus I can play with the code and just see how it ‘feels’. After playing around for a while the process itself usually ends up generating some new ideas which themselves gets played. In this process feeling and aesthetics are central rather than correctness.
Some might argue that the design part is just software architecture in disguise but I feel that the scope of the two are very different. Architecture might deal with the whole application or just bolt on some design pattern somewhere and call it a day. This is not design it is something different entirely. Design patterns are more of a loose blueprint that are followed to varying degrees and usually involves boilerplate code because the problem domain tries to be very general (as in most programming cases…). Again, it might be all UML diagrams and flow charts depending on what you or your team are actually creating and if it works for you then great! Happy for ya. When using this type of design process that I am describing I am more focused on the form and flow of the both the execution and the movement of bytes. From a high level perspective this design process deals with APIs and how the usage looks and feels while taking considerations for memory and performance. From a low level perspective this mostly starts to resemble data oriented design which makes sense since this is the foundation of my thinking when writing code these days.
The other mode of the two is the development mode. This is where we actually write legit code and wrestle with the compiler. This is also where reality hits us in the face and we thank it for it and ask for more. Now we will get a hint on how our design actually works when applied. The knowledge gained here will serve as a feedback to the design mode and thus enable us to refine the design. There might be something that we totally forgot which actually makes large parts of the design useless but this is fine. Now we hopefully a fair bit more of an idea of what we actually want to accomplish with both the design and the code itself. Sometimes parts of the design survive the first impact of reality. With these fragments of surviving design remaining we start working on the implementation specifics such as edge cases (add some null checks, etc).
More often than not the cycle time between the design mode and the development mode are short but sometimes when tackling a big section of code or a fundamental piece of the codebase the cycle time goes way up.