Ask HN: How to reduce inertia in Hammock Driven Development

[michaelwm]

I've been a software engineer for almost a decade now, and I enjoy working in this field a lot. One of the most influential talks in my career has been Rich Hickey's talk on Hammock Driven Development [1]. It's helped me complete projects with such a simple approach that fits well with how my brain works. I'm a very pensive person and for the most part, everything from initial concept to system architecture I do in my head or on a chalkboard. The hardest part for me, still, is going from the chalkboard to code. In Hickey's talk, this step only takes up one bullet point on one slide, but it's easily the most difficult part of the process for me. I'm a competent coder, and know I am capable of writing the code I need to write. Sometimes, however, I spend a lot of time just staring at a keyboard, unable to type what I want to type. There are a lot factors making me this way, outside of the realm of software engineering, that I'm working on. But in the short term, I was hoping to hear about any strategies employed by people who work in a hammock-driven fashion, or anything similar, to actually take the concepts and systems they design in their head and on paper, and put them into a source file for execution.

[1] https://www.youtube.com/watch?v=f84n5oFoZBc

[Zababa]

I've been recently working on a personal project, and what works for me is defining a relatively small feature that I could implement, implement it and then stop here. For exemple yesterday was parsing. I focused on parsing "let x = <an integer>;", and that's it. This helps me have a sense of progress and build confidence. This is also an application of the technique where you stop working when you're in the flow compared to when you encounter a stopping point. This also helps reduce my anxiety about having to do it again since I know that until now I've been able to complete what I wanted, and again, builds confidence.

I also try to take my sleep seriously, which I think helps. My diet and exercise regimen are lacking, but improving them would probably help too.

> Sometimes, however, I spend a lot of time just staring at a keyboard, unable to type what I want to type.

TDD helps here. I find that often the most difficult thing is to start, and starting by writing a test is way easier for me than starting by writing the implementation.