My experience with writing assembler is the same. The run-try-correct sequence encourages trying things until it seems to work. The best code I wrote was in as

My experience with writing assembler is the same. The run-try-correct sequence encourages trying things until it seems to work. The best code I wrote was in assembly language. I'd divide the code into blocks with comments. Each comment would document the expected state at that point, what the block would do, and the state after that block. I wrote pages and pages in my noteblock, and while not everything was bug-free most of it was, and I have never experienced such a nice development process. Nowadays I have to consult five coworkers to ask how to call their undocumented methods and initialize the classes. I have recently encountered the book 'Toward Zero-defect Programming', where exactly this approach is recommended. Key points are (from the top of my head): 1. You should know the programming language you're using inside-out. 2. Don't *try* your code, but *reason* about it, and comment/document this reasoning. 3. Do group reviews of the code and try to find holes in the reasoning, and problems with the code.