[catwell]

This point makes literally no sense to me. He says don't start coding before you fully understand the problem, and then he says the way to explore the problem space is coding (the code-test-improve cycle).

By the way I agree with the last part. Sometimes the best way to understand the problem is writing a half-broken solution for it. You just have to be aware that what you're writing probably won't solve the problem, and make sure all the other stakeholders are aware too (that's usually the hardest part).

[willcipriano]

I've found this sentiment is common among people who dislike coding. They feel code is a burden and do whatever they can to minimize the amount of it that they do.

I've consistently outproduced peers by picking up the compiler early in the cycle and throwing away what I've done if it isn't working out. It requires a bit of self awareness, judgement and taste to know if something isn't going to work but I think the people who hate coding also can't stand throwing effort away like that.

[ravi-delia]

I think the author makes a distinction in the very point you critique between the problem and the solution. If you don't understand the problem, it doesn't matter how dirty your hands get, you'll have trouble solving it. Once you understand roughly what you're trying to solve, you should figure out how to solve it by messing around and seeing what works (as is stated in the article).

[hvidgaard]

I usually go about it differently than hold off coding. I do try to understand the problem fully before I implement anything. I try to figure out what abstractions make the most sense and what to optimize for. Then I write a preliminary implementation and almost without fail I learn something new that changes the parameters of the "problem". Scrap it and do it again just with more knowledge. No amount of analysing and understanding up front have produced a better or faster result for me.

[i_like_robots]

I suppose we can only accurately define a problem when there are no big unknowns, so I wouldn't prescribe readme based development in every scenario - a quick and dirty exploration of the space which can then be scrapped is more important sometimes.

[dgb23]

I agree. There is exploratory coding. It’s a bit like talking to yourself (or your rubber duck) or writing things down, or drawing. It’s the kind of thing you do to load up your head with inputs to just play and it’s incredibly powerful.