Finding a way to show them might be difficult, but rewarding.
(unsolicited advice) What I've learned in working on that skill; avoid coming from a position of supremacy, and rely on actions/results to communicate most of the message. Also, a lot of acceptance and patience.
I like to write a lot of pseudo code before real code, gradually digging down into lower level implementation details, so as to not waste time worrying about syntax while making higher level decisions.
However, it's taken me a long time to develop what I have of that skill; to feel out the different layers decisions will be made, then write pseudocode with the intent of eeking out and resolving most of them.
Doing so, things end up feeling more like trade-offs than compromises.
(unsolicited advice) What I've learned in working on that skill; avoid coming from a position of supremacy, and rely on actions/results to communicate most of the message. Also, a lot of acceptance and patience.
I like to write a lot of pseudo code before real code, gradually digging down into lower level implementation details, so as to not waste time worrying about syntax while making higher level decisions. However, it's taken me a long time to develop what I have of that skill; to feel out the different layers decisions will be made, then write pseudocode with the intent of eeking out and resolving most of them.
Doing so, things end up feeling more like trade-offs than compromises.
Good luck!