[swader999]

I write better non-trivial code when I get up and get away from the screen for a while. Go do something else to get my mind off it. Even sleep on it. Then the insights creep in. Hammering away at a hard problem usually makes a big mess. Sometimes three quarters of my time is spent understanding the requirements, negotiating the solution, researching, talking through the design.

[leesalminen]

Same here! Sometimes I’ve spent weeks thinking through a problem fully, talking to everyone involved (including myself) only to code whatever it was in a couple hours. It’s amazing what our brains can process subconsciously.

[swader999]

Related to this, I typically advocate for the daily stand-up close to mid day so that more work gets time to "sleep on it" and then a chance to add any insights that came to you during the off time. I seem to do better features and code over two work sessions than in one long continuous day.

[username90]

You don't think that coding a prototype in a few hours before talking to people would let them better answer your questions and help reduce that time to a few days instead of weeks? Coding is a very versatile tool and can be used to greatly improve communication.

[tsimionescu]

If it's a very specific problem and you have a candidate solution already known, sure. If it's a vague problem or if you just don't know how to solve it, a prototype would do much less, and is probably a waste of time.

In particular, architectural discussions benefit pretty little from prototyping in the initial phases. If you want to decide if your next system should be microservice based or monolithic, prototyping won't do much.

Similarly, if the basic requirements are not yet understood, asking questions about them is more efficient than implementing a version of possible requirements and asking others to correct it.

[username90]

> Hammering away at a hard problem usually makes a big mess

How can this be? Did you never learn how to use source control? Coding is the best way to explore the solution space, doesn't mean you use whatever you write right now.

[NateEag]

Coding is a good way to explore the solution space, but not the best or only way.

My current guidelines for myself are

1. Take a few minutes (or hours, depending on problem size) to write a clear plan for a proof of concept. What's the terrible, crappy, bare minimum that shows your goal is feasible?

2. Run that document past another person. See if they can simplify the plan for you or find things you overlooked.

3. Hack out the POC.

4. Run the POC past a real person. See if they catch issues in your approach that would be blockers in a production version and resolve them if possible.

5. Write the spec for the actual feature/program based on what you learned from the POC. It doesn't need to be super-detailed or perfect; it just needs to capture the lessons you've learned and give a clear direction for building the real thing.

6. Run the spec past another person. Incorporate their feedback.

7. Write the production version.

This works out pretty well if you keep your specs as plain text in the project repo. You can do the whole process with a standard code review flow.

[8note]

Code tends to be a liability rather than an asset.

A no code solution to a problem tends to be better than one with code

[lolinder]

For me, coding is a great way to explore the solution space when you're down to the last few details. Because coding is implementing a concrete solution, exploration in code tends to only cover a very small subset of the real solution space. On the other hand, if I take a few steps back and look at the problem from a wider angle, I can often find a solution that is both better for everyone and easier to implement.

[tsimionescu]

Code forces you to solve all the details. If (you think) you're close to a solution, sure, then yes, hammering away is a good thing.

But if you're still at the big picture level, code is a horrible way to express that. It inevitably takes you into the weeds.