3 ms·
I think most issues brought up here would be addressed by writing rfcs and have those go through a review cycle, potentially with attached code that is clearly
by larve 4y ago
I think most issues brought up here would be addressed by writing rfcs and have those go through a review cycle, potentially with attached code that is clearly understood to be a proof of concept. It leverages async by giving someone the autonomy to do clear thinking and clear coding, while avoiding pushing the feedback cycle to when all the work has been done and everybody is stuck with a “lgtm can you reindent the last line” review of a fait accompli .
Added benefits are proper top level documentation, and a log of the discussions and compromises made to cut short on future design discussions.
Edit: typos on mobile
- corytheboyd 4y agoAgreed, the happy path is that code implements a spec that has already been agreed upon, anything less means guess work for both the authors and reviewers of code. Life is about compromise so this doesn't have to be true 100% of the time, but this should be in your team's list of core competencies. Also RFC doesn't HAVE to mean big pedantically formatted and worded monospace document. Templates help make sure common mistakes aren't repeated, but using normal-person English and easy to understand code examples can be very effective.