There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Sometimes the only way things ever got fixed is because people became uncomfortable.
fred rosenberger wrote:Is it possible to record the meetings, so you can go back later and review what was said? .
Junilu Lacar wrote:What's wrong with saying "I'm taking some notes and I want to make sure I captured some of these thoughts correctly. So you said ... " then read back what you think your notes say and ask "Did I capture that correctly? Did I miss anything?"
Junilu Lacar wrote:Pausing the conversation to reflect what you received to sure you understood correctly is the only sensible thing to do, in my opinion.
Campbell Ritchie wrote: They should actually circulate such notes in advance.
Out on HF and heard nobody, but didn't call CQ? Nobody heard you either. 73 de N7GH
Maybe you should be more assertive and send them the notes by email immediately after the meeting.Junilu Lacar wrote:. . . "I'm taking some notes . . ." then read back what you think your notes say . . . .
Persuade everybody it is quicker to send notes out beforehand.You've got so much to say I have to take notes and I shall send you them afterwareds to check I haven't missed anything.
Campbell Ritchie wrote:Maybe you should be more assertive and send them the notes by email immediately after the meeting.
Persuade everybody it is quicker to send notes out beforehand.
Les Morgan wrote:
If the presenter is going too fast, I make them wait and slow down.
I have recorded on occasions where that feature is reliable.
for anything written on a White Board etc... take a picture, it is full detail and much better to read later.
Les Morgan wrote: people will slow down to make sure things are accurate. Don't be afraid to ask questions if you miss something.
Junilu Lacar wrote:[What's passive about asking to pause the conversation for a second to make sure you've understood a point correctly? This is also in line with the agile value/principle of fast feedback and face-to-face communication and collaboration..
Sometimes the only way things ever got fixed is because people became uncomfortable.
Satyaprakash Joshii wrote:During online meetings, when someone explains details about work on how some work needs to be done
Tim Holloway wrote:When the other one is a "busy person" and cannot be persuaded to let you stop and capture the details. Best case is to get them to promise to send details later. Worst case is you're being railroaded and at that point, it's probably time to dust off the old CV.
Junilu Lacar wrote:
Tim Holloway wrote:When the other one is a "busy person" and cannot be persuaded to let you stop and capture the details. Best case is to get them to promise to send details later. Worst case is you're being railroaded and at that point, it's probably time to dust off the old CV.
This is a whole 'nother spin on the original question. The assumption I'm making is that the people in the meeting have come with positive intent to communicate and get on the same page about some piece of complex work that they're trying to understand well enough to be able to start writing software related to that work.
Satyaprakash Joshii wrote:And some may be just adhoc online one to one meeting to discuss on work.
Sometimes the only way things ever got fixed is because people became uncomfortable.
Junilu Lacar wrote:can't just be written down as a procedure to be followed. If it could be written down as a procedure to follow, then why have a meeting about it?
Junilu Lacar wrote:
Just as we write code and try to keep methods at a single level of abstraction, you would also want to follow a similar principle for your conversations with SMEs.
Satyaprakash Joshii wrote:I am talking more about adhoc one to one meetings.E.g just pinging on chat and calling for a random discussion on work on skype or adding third person dynamically in the meeting for few minutes for some discussion , than the meetings fixed in advance.
Junilu Lacar wrote:The "someone" who explains the details of the complex work is a subject matter expert (SME) and the listener taking notes is a developer, .
Junilu Lacar wrote:
Essentially, getting a single level of abstraction makes the code focused on intent rather than implementation. With respect to the conversations you're having with an SME, you want to make sure you're clear on intent first (high-level summary and functional levels) before delving into subtask details (the fish-eye view). This is how you can iteratively refine your understanding of the work.
Satyaprakash Joshii wrote:If during such meetings, at rapid pace one understands and remembers then one may not even have to write. I write sometimes thinking that I can understand this after analyzing slowly later on, and not at pace of the meeting , so write down now and analyze later slowly.
Satyaprakash Joshii wrote:Is the disadvantage of not maintaining single level of abstraction in coding or communication that it would lead to confusions ?
Junilu Lacar wrote:
Satyaprakash Joshii wrote:Is the disadvantage of not maintaining single level of abstraction in coding or communication that it would lead to confusions ?
Well, first I get out of bed, put my slippers on, I fluff the pillow, smooth out the bedsheet, fold the blanket, put it on top of the pillow, then I walk to the bathroom, I pick up the toothbrush, put toothpaste on it, turn on the faucet, wet the toothbrush, put the toothbrush in my mouth, move my hand up and down, then I brush the front teeth, then the left side, then the right side, then I brush the back of my front teeth, the back of my left side, the back of my right side, then I spit in the sink, turn on the water, then I pick up the glass, fill it with water, ..., then I have breakfast, take a shower, get dressed, get in the car, put the key in the engine, turn the key, put the car in reverse, back out of the garage, click the button on the garage door remote, wait until the garage door is fully closed, back out into the street, then I drive to work.
... when trying to answer the question "How do you get ready for work in the morning?"
Junilu Lacar wrote:
Do you see how it helps keep you more focused?
Junilu Lacar wrote: Don't be afraid to ask for feedback in the moment!
Junilu Lacar wrote:[ There's absolutely NOTHING wrong with asking the other person to check your understanding. Even if you let them talk it all through first, then ask them to listen to what you are taking away, it's still better than looking like you got everything and then it turns out you didn't because you missed something or misunderstood it and that shows up in the work that you did. You look far more inattentive or stupid when that happens.
Satyaprakash Joshii wrote:During the meeting building some understanding and telling it to the other person that this is my understanding , this has to be reasonably quick (because the other person would not pause for 5 minutes to let me think analyse and build some understanding then tell my understanding to him to confirm)
I wrote:
You: "Ok, this what I understood... explain in your own words what you think the other person said"
Junilu Lacar wrote:You: Thanks again for your input. This was a lot to take in so I might have to get your input again on other details. Can I ping you once I've fully digested and analyzed the implications of this new information? I want to make sure I understand this correctly.
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |