9 ms·

I use junior engineers’ code review submissions as an opportunity to teach, and any senior engineer who doesn’t is committing professional malpractice. They hav

by sidlls 4y ago

I use junior engineers’ code review submissions as an opportunity to teach, and any senior engineer who doesn’t is committing professional malpractice. They have to learn, and that requires someone (in the case of a code review) to teach them. One can do it without being condescending, though The Socratic method for teaching is actually quite good, and it can be employed without condescension.

deleted 4y ago
[deleted]
bsder 4y ago
I think the real problem here is that because everything is going online-only, we're falling into the trap of making everything public and recorded forever. 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.
- lifeisstillgood 4y ago
  This. 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
- dan-robertson 4y ago
  I’ve written plenty of bad code before, and some of it was released and some of that led to tricky bugs. I don’t feel particularly ashamed of having written bad code though. Maybe I’m thinking of a different kind of feedback? Like, hopefully the worst problems can be figured out before much code is written, and if someone made some asshole critical comment, I would probably consider it reflecting poorly on them rather than me (indeed I find the permanent record of the comments I left and since regretted weighs more heavily than the record of the comments received – or the poor code committed). But I guess different people react to feedback differently, especially critical feedback and maybe you’re imagining some kind of ‘the whole thing is totally wrong and terrible’ discussion? But that feels to me like a case where a bunch of blame belongs to whatever allowed a bunch of totally wrong code to begin to be written.
- sidlls 4y ago
  I agree that submissions that bad shouldn't have a permanent record. If I see something egregious I'll ask the person in person, or via our chat software, and make a vague comment like, "Please make the changes we discussed over lunch," or whatever, in the comments of the submission.
- actually_a_dog 4y ago
  In my experience, the problem you’re pointing out is a non-problem. I’ve never done an in person code review in my life that didn’t take place in an interview context. Yet, somehow none of my mistakes in writing code (and there have been many) have never become “a public albatross stuck around [my] neck.” 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?
- SilasX 4y ago
  >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. 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.)
thinking4real 4y ago
Eh, even the socratic method is quite patronizing in many situations. 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
- goostavos 4y ago
  100% Agreed. Just say what you think and why. The Socratic stuff works really well if you're making up a pretend conversation where you get to write both parts, and every question gets the perfect answer, and it all gets to ends with perfect enlightenment. In the real world, your questions probably suck, and the answers probably suck more. Nothing is more obnoxious than enduring someone badly doing "the socratic method" on you. 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?"
mentat 4y ago
I ask a lot of questions on code reviews as it's usually less easily perceived as conformational and I have come to assume that I'm missing context when something is really off. Assume that coworkers are competent but may either have or lack context. If your coworkers are genuinely incompetent, then a new position might be better than fighting though PRs.
photochemsyn 4y ago
I don't know how easy it is to avoid coming off as condescending. For example: > "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.
simplotek 4y ago
> The Socratic method for teaching is actually quite good, and it can be employed without condescension. 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.
m463 4y ago
what some people don't get is that they're gatekeeper and have to balance that out.
throwaway892238 4y ago
Ask them if they want a lesson first. Not every junior wants their superiors lecturing them.
- tremon 4y ago
  Yes, and not every kid wants to be told what to do by their parents. But it still happens, because that is part of the parents' role. As it is with senior developers.
  - throwaway892238 4y ago
    You just described Paternalism...
    - deleted 4y ago
      [deleted]
    - tremon 4y ago
      You write that as if every -ism contains contains an automatic and universal value judgement. For those of us who don't subscribe to that model, do you think you can rephrase your argument without isms?
      - throwaway892238 4y ago
        Do you know why children don't like to be told what to do by their parents? It's not because they can't do whatever they want. It's because as a child, your agency is taken away. You have no choices but those given to you, no information but what little is given to you. You live in a world of someone else's rules and decisions, someone else's tastes, someone else's lifestyle. You are forced to live the life someone else wants, rather than your own life. And you are often given restrictions not because it's what's best for you, but it's just what's convenient for the person in power. 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.
PragmaticPulp 4y ago
> The Socratic method for teaching is actually quite good, and it can be employed without condescension. 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.
- NikolaNovak 4y ago
  Yeah ; I'm super open to coaching as opposed to mentoring, but last few years, when my managers tried to employ the coaching / questions methodology, it was obvious and painful : they did not feel like open questions to discover something together ; they felt like fake questions that had a "right" or rather "expected" answer, so it did not feel at all like "me figuring things out for myself " but rather"me trying to guess what I'm expected to say". Typically after a few frustrating minutes I just ask for straight feedback - I am happy and excited to receive constructive feedback and lecturing. 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 :-)
BlackFly 4y ago
The Socratic method is bad over asynchronous communications because if you, Socrates, made a mistake then it takes 3-5 iterations to clear that up. 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.
aflag 4y ago
If you're looking at someone's job title before making a review I'd say you're doing it wrong. Just point out things that are wrong (actual bugs) and things you think could've be done better. If there are no bugs it's probably ok to even approve it already, unless things were really poorly written. It shouldn't matter whether the person submitting the PR is a junior or the highest ranking developer in the company. Code is code.
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]
hgsgm 4y ago
"Socratic" method (which was used in a book, not in actual teaching, IIRC), works when the student wants to figure something out on their own but with guidance, like "You Could Have Invented X" blog posts, or tutoring math. It doesn't work when the "teacher" forces it upon an unwitting "student" to trick the student into discovering they are wrong.
impalallama 4y ago
Socrates was executed for the Socratic method
azangru 4y ago
> any senior engineer who doesn’t is committing professional malpractice 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?

by sidlls 4y ago

deleted 4y ago

[deleted]

bsder 4y ago

I think the real problem here is that because everything is going online-only, we're falling into the trap of making everything public and recorded forever. 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.

lifeisstillgood 4y ago
This. 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
dan-robertson 4y ago
I’ve written plenty of bad code before, and some of it was released and some of that led to tricky bugs. I don’t feel particularly ashamed of having written bad code though. Maybe I’m thinking of a different kind of feedback? Like, hopefully the worst problems can be figured out before much code is written, and if someone made some asshole critical comment, I would probably consider it reflecting poorly on them rather than me (indeed I find the permanent record of the comments I left and since regretted weighs more heavily than the record of the comments received – or the poor code committed). But I guess different people react to feedback differently, especially critical feedback and maybe you’re imagining some kind of ‘the whole thing is totally wrong and terrible’ discussion? But that feels to me like a case where a bunch of blame belongs to whatever allowed a bunch of totally wrong code to begin to be written.
sidlls 4y ago
I agree that submissions that bad shouldn't have a permanent record. If I see something egregious I'll ask the person in person, or via our chat software, and make a vague comment like, "Please make the changes we discussed over lunch," or whatever, in the comments of the submission.
actually_a_dog 4y ago
In my experience, the problem you’re pointing out is a non-problem. I’ve never done an in person code review in my life that didn’t take place in an interview context. Yet, somehow none of my mistakes in writing code (and there have been many) have never become “a public albatross stuck around [my] neck.” 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?
SilasX 4y ago
>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. 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.)

thinking4real 4y ago

Eh, even the socratic method is quite patronizing in many situations. 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

goostavos 4y ago
100% Agreed. Just say what you think and why. The Socratic stuff works really well if you're making up a pretend conversation where you get to write both parts, and every question gets the perfect answer, and it all gets to ends with perfect enlightenment. In the real world, your questions probably suck, and the answers probably suck more. Nothing is more obnoxious than enduring someone badly doing "the socratic method" on you. 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?"

mentat 4y ago

I ask a lot of questions on code reviews as it's usually less easily perceived as conformational and I have come to assume that I'm missing context when something is really off. Assume that coworkers are competent but may either have or lack context. If your coworkers are genuinely incompetent, then a new position might be better than fighting though PRs.

photochemsyn 4y ago

I don't know how easy it is to avoid coming off as condescending. For example: > "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.

simplotek 4y ago

> The Socratic method for teaching is actually quite good, and it can be employed without condescension. 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.

m463 4y ago

what some people don't get is that they're gatekeeper and have to balance that out.

throwaway892238 4y ago

Ask them if they want a lesson first. Not every junior wants their superiors lecturing them.

tremon 4y ago
Yes, and not every kid wants to be told what to do by their parents. But it still happens, because that is part of the parents' role. As it is with senior developers.
- throwaway892238 4y ago
  You just described Paternalism...
  - deleted 4y ago
    [deleted]
  - tremon 4y ago
    You write that as if every -ism contains contains an automatic and universal value judgement. For those of us who don't subscribe to that model, do you think you can rephrase your argument without isms?
    - throwaway892238 4y ago
      Do you know why children don't like to be told what to do by their parents? It's not because they can't do whatever they want. It's because as a child, your agency is taken away. You have no choices but those given to you, no information but what little is given to you. You live in a world of someone else's rules and decisions, someone else's tastes, someone else's lifestyle. You are forced to live the life someone else wants, rather than your own life. And you are often given restrictions not because it's what's best for you, but it's just what's convenient for the person in power. 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.

PragmaticPulp 4y ago

> The Socratic method for teaching is actually quite good, and it can be employed without condescension. 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.

NikolaNovak 4y ago
Yeah ; I'm super open to coaching as opposed to mentoring, but last few years, when my managers tried to employ the coaching / questions methodology, it was obvious and painful : they did not feel like open questions to discover something together ; they felt like fake questions that had a "right" or rather "expected" answer, so it did not feel at all like "me figuring things out for myself " but rather"me trying to guess what I'm expected to say". Typically after a few frustrating minutes I just ask for straight feedback - I am happy and excited to receive constructive feedback and lecturing. 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 :-)

BlackFly 4y ago

The Socratic method is bad over asynchronous communications because if you, Socrates, made a mistake then it takes 3-5 iterations to clear that up. 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.

aflag 4y ago

If you're looking at someone's job title before making a review I'd say you're doing it wrong. Just point out things that are wrong (actual bugs) and things you think could've be done better. If there are no bugs it's probably ok to even approve it already, unless things were really poorly written. It shouldn't matter whether the person submitting the PR is a junior or the highest ranking developer in the company. Code is code.

deleted 4y ago

[deleted]

deleted 4y ago
[deleted]

hgsgm 4y ago

"Socratic" method (which was used in a book, not in actual teaching, IIRC), works when the student wants to figure something out on their own but with guidance, like "You Could Have Invented X" blog posts, or tutoring math. It doesn't work when the "teacher" forces it upon an unwitting "student" to trick the student into discovering they are wrong.

impalallama 4y ago

Socrates was executed for the Socratic method

azangru 4y ago

> any senior engineer who doesn’t is committing professional malpractice 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?