3 ms·
This is useful, even if it seems "manager-y". TL;DR: Let's say we need to decide on tabs vs spaces. Assign roles to people in the team/organization making the d
by lxe 7y ago
This is useful, even if it seems "manager-y". TL;DR: Let's say we need to decide on tabs vs spaces. Assign roles to people in the team/organization making the decision:
- (R)ecommend: ensures everyone sticks to their role.
- (A)gree: same as I, but can approve/disapprove the decision.
- (P)erform: changes the code to tabs or spaces after the decision is made.
- (I)input: gives input, consults, but has no say in the decision making.
- (D)ecide: this person tells the P's whether it's gonna be tabs or spaces.
Let's see it in action:
Roger: "Should we use tabs or spaces?"
Alice: "Tabs are better because..."
Igor: "I use spaces, they are nice because..."
Ivan: "I use tabs, they are nice because..."
Derek: "Alright, let's use spaces"
Alice: "Well, actually..."
Derek: "Ok, well, tabs it is!"
Roger: "Alright, looks like we have the decision: it's tabs!"
Patrick: "<re-indents the code with tabs>"
- scarejunba 7y agoIn reality, Patrick reindents with spaces and everyone else forgets because most decisions are not meaningful decisions in the company. I'd say about 95% of the decisions companies make do not move the needle, do not aggregate into moving the needle, and are easily determinable to not move the needle.
- richardxlin 7y agoAgreed. Based on experience, unless decisions of this type is automated via a script or post build, people will resume what they are accustomed to.
- scarejunba 7y agoWhile you're right for things like this, I meant that more broadly. I suspect that it applies to build systems, languages, product development, etc.