Would deffo agree to this. My approach is usually sending out a PR as soon as I can to a group of reviewers / users and goes in following stages. 1) POC - pro

Would deffo agree to this. My approach is usually sending out a PR as soon as I can to a group of reviewers / users and goes in following stages. 1) POC - proof of concept. It does 90% of things, some parts are ugly and messy but validates a hypothesis. The unknown unknowns are discovered. I want to stage this and get this in front of some alpha internal users as soon as I can. First pass reviewers give a on the plan of attack. Lots of sub TODO’s are listed in PR. The goal is to discover edge cases and unknown unknowns. 2) Simple - Go through PR and refactor any existing / new code so it’s readable and DRY. If reviewers don’t understand the “why” of some code, a comment is left. Now 90% of scenarios are covered, probably some edge cases may not work but the edge cases are known. The code is simple and at right layer of abstraction. 3) Correct, Testable - Edge cases are covered, tests are written, internal users have validated that the feature is working as expected. 4) Polish - if it’s slow, then slow internals are swapped out for fast parts. Tests would mostly work as is. Same with UI, css fixes to make it elegant and pretty. Sometimes the process is a day, sometimes it’s a week.