| 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. |