Marijn has an elegant way of scaling his thoughts to the rhythm and measure of whatever medium he happens to be writing in, a quality which makes him consistent

Marijn has an elegant way of scaling his thoughts to the rhythm and measure of whatever medium he happens to be writing in, a quality which makes him consistently good to read. His response to the workflow prompt is especially good. I'd like to reproduce it here as a way of flagging it for people who might not otherwise read the entire thing: My approach to writing software is embarrassingly unstructured. I'm not sure I can claim to have something that merits the term 'workflow'. One thing that is very important for me, and that, had I figured it out earlier, would probably have saved some past projects from dying, is to never have a system in a half-refactored, non-functional state for longer than an hour or so. A lot of momentum and motivation comes from having a working program in front of me. This sometimes means I have to split up big changes in a number of more indirect, trivial steps, and resist the temptation to start hammering out my big change in one go (which, even when seems straightforward in my head, will always hit some complications during implementation). Also, really learning git in depth has had a big influence on how I code. Once you really understand that changes (if you bother to commit often and with care) can be reverted and picked at will, and that branches are cheap and easy to create and maintain, you start to see a codebase differently. I often take multiple shots at making a tricky change — if it feels like my first approach is not working out, I simply commit it, back up, and start again, knowing that if the new approach doesn't work out, I can simply flip back to the old one again. Knowing that this is theoretically possible is not enough—you need to have actually done it, often, to start applying it properly.