I probably fall somewhere in the middle and err on the side of paper still. I absolutely always start with pencil and paper and get the basics laid out and the

I probably fall somewhere in the middle and err on the side of paper still. I absolutely always start with pencil and paper and get the basics laid out and then after I think I have identified all the first level problems and issues I'll start building in code. If I find that I missed issues though, I'll return to paper and update my model and rethink it . Then go back to code, and usually I find this means I'll change less code to make things work in the end. At some point there is no point of going back to paper for minor design changes while you are actively developing things though, however I find having & maintaining a high level model, an architecture model and a roles & responsibilities model in documentation form is super helpful and can reduce the time to get up to speed, find issues etc. FWIW, I also have been writing code for a long time and have worked on projects where to compile the entire code base with tests could take hours of machine time to complete, there was no concept of quick change/compile/test cycle for the entire product (maybe small modules). So you absolutely designed things and thought through them first, then moved to code. Obviously interpreted languages now and shorter compile times means you can sit there and experiment and it sometimes is faster then thinking through the problem at least at first, but I'd argue people who do this still usually miss a number of cases and will have to return to the code more then the person who laid it out and through through it (regardless of if they did that on paper or in an electronic document etc). I have worked with people that do both methods, I have my preferences and like the tradeoffs I take, but I would be hard pressed to say one way is right or one is wrong, as long as you get to the same end goal in a reasonable time period I really don't think it matters.