Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
When people ask me to make decisions, they're usually looking for a simple response. Something on the order of a basic "yes/no" or "which of these X things would you pick". For better or worse, that's not my style. Never has been. So, whenever people ask me for a decision, what they usually get back is something on the order of:
here's what I considered
here's what I saw the strengths/weaknesses of doing/choosing 'X'
here's what I saw as the risks/rewards of doing/choosing 'X'
here's the weights I put on the above
...and then finally "here's what I chose based on the above". I prefer that people understand why I made a given decision. That way, they have not just the decision/recommendation but its basis. Provides more background on whether the decision/recommendation is valid for why they were asking.
Plus, it provides a measure of CYA. Months down the road you can dig up that email/Slack/etc. conversation to answer the "why the hell did we do this" question if something went wrong or went a different direction than some thought it would. =)
This is a really good point, we usually maintain Architecture Decision Records, usually in markdowns or adoc in a documentation git repo and share that in a mail.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
When people ask me to make decisions, they're usually looking for a simple response. Something on the order of a basic "yes/no" or "which of these X things would you pick". For better or worse, that's not my style. Never has been. So, whenever people ask me for a decision, what they usually get back is something on the order of:
...and then finally "here's what I chose based on the above". I prefer that people understand why I made a given decision. That way, they have not just the decision/recommendation but its basis. Provides more background on whether the decision/recommendation is valid for why they were asking.
Plus, it provides a measure of CYA. Months down the road you can dig up that email/Slack/etc. conversation to answer the "why the hell did we do this" question if something went wrong or went a different direction than some thought it would. =)
This is a really good point, we usually maintain Architecture Decision Records, usually in markdowns or adoc in a documentation git repo and share that in a mail.