Socratic Method is hard to use without coming off as patronizing, even if you think you're being careful.
If you're genuinely jumping in to ask real questions to understand the problem, that's great.
Most of the time when I see people use Socratic Method in the workplace it's because they think they're doing the other person a favor by asking leading questions instead of communicating directly. For the person on the receiving end, it becomes a game of navigating the questions and delivering the answers you know the person wants to hear, all done as delicately as possible to avoid disturbing their sense of superiority.
Once you start doing this, every question starts to feel like a loaded question. Is this person genuinely asking my thoughts, or is this question another test to see if I agree with their secret answer? Am I okay to express a differing opinion here, or will I trigger another round of patronizing questions if I give the wrong answer? Is this person asking questions because they don't know, or because they think they know better than me and want me to realize I'm wrong?
It's almost always better to approach the conversation as a discussion between peers. If you go in with implied seniority structures or student/teacher methods (including Socratic method) then it stops being a conversation among peers and starts to feel like another social hierarchy game that must be carefully navigated to avoid upsetting your elders.
Just talk to your coworkers like collaborative peers, even if they're more junior than you. If you want to communicate something, say it directly. Don't ask questions and try to get the other person to guess the secret answer you want.
My boss and I had an open discussion and it may be they just need more practice - coaching is a skill like any other and just because you took a two day class doesn't mean you're an expert yet. So we accepted that while he's more experienced than I am and my mentor in many things, he's junior in "coaching" so we sure working on it together :-)
In the workplace, Socratic method just feels like an unnecessary power move. Someone is trying to cement their role as teacher and the other person as student.
I had a manager who liked to use the Socratic method for everything. He communicated everything in the form of questions. If you gave the "wrong" answer, he'd give a sharp sigh and then rephrase the question, giving you another change to give a "better" answer.
This method was mildly annoying when he was right, but it was completely disastrous when he was wrong. He'd often arrive late to a situation that people had been dealing with for months and assume he knew exactly what was going on, better so than the people involved. He'd start his Socratic questioning, but you weren't allowed to explain the context or how you arrived at a solution. Your only option was to navigate his Socratic questioning until you could gingerly explain that he was missing a key constraint, or that we had already tried that, or that he had received bad information, and so on. It became a tool for him to control the conversation and put you in your place at the same time.
It was a very sad time in my career. I'd arrive to every meeting feeling like I was about to play a psychological game of "guess the right answer" as I navigated the Socratic questions until we could get him to reveal what he was really thinking, or why he was so frustrated, or why he thought we were wrong, or any other number of issues that he just wouldn't tell us.
Now I say explicitly what I think is wrong and what needs changing.
This too can come off badly so I limit reviews to one or two remarks. I also build a relationship with these engineers and explicitly explain how I do reviews different nothing that while I give you solid direction, whether you take my advice is entirely up to you to evaluate and that it is 100% ok with me if you explain why I'm wrong and you're not changing it. - the purpose of my reviews is to catch problems you haven't thought of, if you've already thought about it and made a trade off that's your call to make. (And I trust you to make it)
Translation: I'm too old for this tit for tat shit and have bigger hills to die on than where you put your whitespace.
I don't know how that relates to the Socratic method. But I think it's useful, if done honestly. It's like a little ritual that you do together and it serves both sides as a guideline in the moment, but also helps to converge to a common way of communicating things and writing code.
I seriously doubt a PR is the right medium for the Socratic method, or that trying to employ it in that venue can sound anything other than condescending.
PRs are the end result of the developer's work to address an issue. Communication through a PR is asynchronous and inefficient wrt time. Engaging in gratuitous chatter in PRs actively blocks the developer from delivering his work. Pushing for needless iterations with cryptic open-ended questions where you force a developer to be on the defensive reads as if you're standing in the way while gratuitously questioning someone's ability in a very public way through a medium designed to persist discussions til the end of time.
If a PR has an issue just do the right thing and go straight to the point. If you feel the need to get into what you feel are teachable moments, reach out to the developer through your choice of direct chat.
Maybe I'm just too damn old, but I don't like this trend.
When code reviews were in person, as a senior person, I could deliver feedback without that feedback becoming a public albatross stuck around someone's neck. We all screw up and miss things. Sometimes we don't write the best code. Sometimes we don't know something that should be universal knowledge.
My correcting your mistake or lack of knowledge shouldn't get recorded for all to see.
With the way things currently are, I now have to do two code reviews. One to correct actual problems and teach/mentor and the other for the public checkin to the system codebase.
Emails that have a long list of CCs suddenly become a political hothouse of "If I say X in front of Y it will seem like a criticism and they will clam up and then the whole thing becomes something the "positional authority" has to adjudicate not an experience led discussion"
I feel that this problem is the very reason FOSS mailing lists (ie Linux) were so brutal - it's that or you risk lack of clarity.
I know I sound like someone complaining about woke snowflakes, but there is a line somewhere around here and I wish I knew where it was
Heh, I actually ran into a funny situation because of permanence of code review.
One time I was onboarding a new employee (call him Bob) to how pull requests worked in GitHub, and I wrote up a sample one from his computer. Just to be silly, and because I didn't realize the implications, I said "okay and you fill out the body, describing what you did. As an example, let me just put in some filler text, 'hey, you people suck'."[1]
I was planning to delete the obvious-garbage PR, but I didn't realize ... GitHub doesn't let you delete PRs, only close them! And it triggers emails!
Mercifully, no one said anything. But then months later, another co-worker (call him Charlie) was venting to me about what he didn't like about Bob: "And, another thing, one time, that asshole wrote up this pull request, where he said, hey, you people suck!"
So I owned up: "Oh, uh, Charlie, that ... was actually me. I was writing a dummy pull request to onboard Bob but sent it by accident."
Then Charlie said, "Well ... he's still an asshole!"
[1] I think I wasn't planning to submit it at all, but after a while Bob probably wanted to see it in action and I forgot to remove that part. (And yes, I also now make sure to use more innocuous filler text.)
Is this a thing you’ve seen or just something you’re afraid might happen? If the former, I would say that’s an unhealthy work environment. If the latter, then why point it out?
> "Let's say someone makes the argument that the Socratic method has major flaws related to how it is applied in practice, and that it's better to explicitly state issues with someone's approach or line of reasoning? How might you respond to such a disagreement among your cohort of senior engineers when it comes to code review practices?"
It's always going to come across as "Look I'm patiently trying to lead you arond to the conclusion that you made a mistake or don't understand things correctly, because trust me, I know better."
Also, a lot of junior people know all about how this game is played and will play along, faking the whole 'dawning realization of the error they made' thing and expressing appreciation for the master's wisdom, while secretly thinking, 'am I going to have to go through this every time I make some mistake or other?' I certainly spent quite a bit of time doing that in the past.
I think it's just a lot faster and more efficient to point out errors and issues as you see them, and any decent engineer will absorb that information pretty quickly.
1. You post a question with non-specific action intended to stimulate them to critically think and fix a defect which doesn't exist. 2. The bewildered person tries explaining what is going on blindly, not sure what you are hinting at. 3. If the general explanations connect, maybe you see your mistake and resolve otherwise you explain what you were thinking the defect was. 4. The author explains the lack of defect. 5. You apologize and resolve.
If the person has any confidence at all then they will consider this a demoralizing possibility.
Even if the person didn't make a mistake if you know there is an issue and are withholding that from them because you think them figuring it out by being stimulated from answering your question is benefitial to them, then you are not being immediately helpful in an asynchronous process that has a tendency to drag on. Our society would not be capable of the things it was today if everybody needed to reinvent the wheel frequently as a learning experience; direct communication is a strength we have.
All I am saying is, go sit down with them if you want to use the socratic method. It is multiple times more effective then.
Interesting. Why not turn it around and say that any junior engineer who doesn't use comments left by his more experienced colleagues as a learning opportunity is committing professional malpractice?
Children are often not given the benefit of the doubt. Things aren't explained to them, and they're lied to. Much of the time parents don't even do what's best, but instead whatever they prefer. The child may actually be fine with what a parent wants. But rather than give the child the knowledge and tools to make their own decisions and come to their own conclusions, the parent forces their child to become subservient, removing their ability to be a free human being, making their own mistakes, achieving their own goals. Children often grow up stunted by years of biased information, and the inner working of the minds of others who have grown up in the same system.
Paternalism is wrong because it's wrong to think you know what's good for others. You may know what's good for you. And you may have some experience that tells you some potential consequences of specific actions. But by pushing your own desires and limited knowledge on a child, and not permitting experimentation, growth, or making one's own mistakes, the child does not really grow. They just become a poor copy of the parent, and just as limited. Later they internalize all this and try to justify it by doing the same thing to others or their own children. But it's just a coping mechanism for the trauma they experienced as a small human with no rights.
If you actually respect your co-workers, do not treat them like children. Do not condescend. Do not limit them. And do not prevent them from making simple mistakes. Give them information, teach them, sure. But only if they want to be taught. Not because you think you have some special right to tell people what to do, or force people into situations they didn't consent to.
As a senior myself, I am happy to share information and help people learn and grow. But I would never tell a junior what to do, or lecture them, or prevent them from making mistakes. Everyone deserves to come into their experience in their own way, and be an equal member of the team.
For example: underlying does a task that is correct and valid but not what the higher up envisioned or hoped for. In this case you’re just going to come off as a prick for “gently guiding me” to a conclusion I disagree with, but which I’m not allowed to (non confrontationally) articulate as you’ve corralled this conversation down one narrow path based on your personal preference
As someone who while I was a junior was starved for someone to actually teach and mentor me, I’d say this scenario played out much more often than one where I was given valuable education. yrmv
The main problem with junior engineers is that they have narrow views of the world. Software is complex. Being experienced, is mostly about earning hard won scars through mistakes, missteps, and rewrites. It's tough to convey the scope of impact by just asking them questions. It's much more guiding to just give them what they don't yet have!
I'd much prefer: "Oh, man, so this looks like it shouldn't matter, but let me tell you how I once took down prod for 3 hours by doing this same thing. I can show you how it can fail in this really subtle way".
to: "what is the nature of being?"
The Socratic method for teaching is actually quite good, and it can be employed without condescension.