3 ms·

I believe that nowhere in my response did I suggest that you be incompetent in your management or be a lousy teacher. I specifically mention that you look for

I believe that nowhere in my response did I suggest that you be incompetent in your management or be a lousy teacher. I specifically mention that you look for particularly hard or challenging problems in which to do the pair programming precisely because it's an opportunity to both "scratch the itch" as well as teach. In every group I've ever worked in, worked with, or managed there were inexperienced people and those people tend to get less-interesting tasks simply because they lack the experience or knowledge required for hard, challenging, or critical problems. The best way to speed up their learning curve is to give them tasks that exceed their current capabilities, and the best way to minimize the risk is to provide the safety net of a more experienced and/or capable partner to help them learn to think through the problem and catch errors. As an added bonus it is entirely possible that the more experienced partner actually learns something from the pairing as well.

watwut 9y ago
Give them hard task that you are not itching to do by yourself or don't have strong subjective opinions about. In any case, if your safety net is trully just safety net with enough autonomy for them, then supervising them won't satisfy your problem solving itch. Because it is not supposed to, good teaching is about allowing them as much independence as possible whole you limit yourself to keeping it safe. If you are intervening more then that, then you are not making them more confident about hard tasks (which is exactly what it sounds like you want to do as they tend to pick only easy tasks). It is not true that all juniors avoid harder tasks, my experience was that they seek them. They are eager to prove themselves. Also, what is hard for them is not hard enough to challenge me.
- fallous 9y ago
  You do not give them hard tasks that are critical because of the risk involved, until they prove they can be trusted with those tasks. Supervising and teaching a junior dev working through a hard problem most assuredly satisfies problem-solving itches because in addition to having to think of solutions yourself (often internally) you also have to think about what they're doing and when they struggle you have to figure out a way to lead them to a better path and insure they understand both why they were struggling as well as why a particular path is better. Simply telling someone to do X isn't teaching. I did not say that juniors avoid harder tasks, they almost always underestimate their limits and try and take on more than they are capable of. I said they tend to get the less interesting tasks, because no sane manager working in an actual business hands out the "re-architect our entire infrastructure" job to the most inexperienced member of a team.
  - watwut 9y ago
    Thankfully, critical and hard is not the same, so I can give them hard tasks that are low risk. And I can code review them and check on them while they are working. There are interesting tasks for juniors, even easier to find that interesting tasks for seniors, they just don't tend to be large like "re-architecture everything" which should not be task for single person at all. And which is also largely political task (meaning it is as much if not more about negotiating and convincing people). My experience with younger people is different than yours, clearly, but that might be influenced by how your and my company chooses people and how management behaves. My experience is really that they are very likely to underestimate difficulty and size of task. The advice that most of them needed to hear were usually brainless easy to me - mostly concerning organization of work and code, when to ask customer, how to refactor safely, that sort of thing. Algorithmic or read-up-on-it technical or math or anything else requiring deeper thinking were things they were good at.
    - fallous 9y ago
      I think our experiences aren't that different but our view of what juniors need probably does diverge. "Algorithmic or read-up-on-it technical or math" aren't the things I consider to be deeper thinking for programmers but instead are skills and methods that we'll always be continually having to add or hone. Deep thinking, which through my experience with others qualifies as hard due to the relative rarity in which I've seen them capable or willing to do, are much closer to the things you feel are brainlessly easy. That's not unusual since we often under-value the things that come easily to us by assuming that it comes easily to everyone. Learning how to _think_ about a problem, how to understand it at a fundamental abstract level and then build a mental and theoretical model needed to bring that vision to the point where implementation can occur is far harder than writing the code for the vast majority of people. I also used to think "this is obvious and easy for me so it must be for others as well" but time and again that's proven not to be the case. I learned to focus on making sure my people can think the right way so that at worst they can respond to surprise difficulties or crises on their own but the best hope is that they become better than I am. With the right people in the right environment, if I'm doing my job well I will make myself redundant or superfluous.

watwut 9y ago

Give them hard task that you are not itching to do by yourself or don't have strong subjective opinions about. In any case, if your safety net is trully just safety net with enough autonomy for them, then supervising them won't satisfy your problem solving itch. Because it is not supposed to, good teaching is about allowing them as much independence as possible whole you limit yourself to keeping it safe. If you are intervening more then that, then you are not making them more confident about hard tasks (which is exactly what it sounds like you want to do as they tend to pick only easy tasks). It is not true that all juniors avoid harder tasks, my experience was that they seek them. They are eager to prove themselves. Also, what is hard for them is not hard enough to challenge me.

fallous 9y ago
You do not give them hard tasks that are critical because of the risk involved, until they prove they can be trusted with those tasks. Supervising and teaching a junior dev working through a hard problem most assuredly satisfies problem-solving itches because in addition to having to think of solutions yourself (often internally) you also have to think about what they're doing and when they struggle you have to figure out a way to lead them to a better path and insure they understand both why they were struggling as well as why a particular path is better. Simply telling someone to do X isn't teaching. I did not say that juniors avoid harder tasks, they almost always underestimate their limits and try and take on more than they are capable of. I said they tend to get the less interesting tasks, because no sane manager working in an actual business hands out the "re-architect our entire infrastructure" job to the most inexperienced member of a team.
- watwut 9y ago
  Thankfully, critical and hard is not the same, so I can give them hard tasks that are low risk. And I can code review them and check on them while they are working. There are interesting tasks for juniors, even easier to find that interesting tasks for seniors, they just don't tend to be large like "re-architecture everything" which should not be task for single person at all. And which is also largely political task (meaning it is as much if not more about negotiating and convincing people). My experience with younger people is different than yours, clearly, but that might be influenced by how your and my company chooses people and how management behaves. My experience is really that they are very likely to underestimate difficulty and size of task. The advice that most of them needed to hear were usually brainless easy to me - mostly concerning organization of work and code, when to ask customer, how to refactor safely, that sort of thing. Algorithmic or read-up-on-it technical or math or anything else requiring deeper thinking were things they were good at.
  - fallous 9y ago
    I think our experiences aren't that different but our view of what juniors need probably does diverge. "Algorithmic or read-up-on-it technical or math" aren't the things I consider to be deeper thinking for programmers but instead are skills and methods that we'll always be continually having to add or hone. Deep thinking, which through my experience with others qualifies as hard due to the relative rarity in which I've seen them capable or willing to do, are much closer to the things you feel are brainlessly easy. That's not unusual since we often under-value the things that come easily to us by assuming that it comes easily to everyone. Learning how to _think_ about a problem, how to understand it at a fundamental abstract level and then build a mental and theoretical model needed to bring that vision to the point where implementation can occur is far harder than writing the code for the vast majority of people. I also used to think "this is obvious and easy for me so it must be for others as well" but time and again that's proven not to be the case. I learned to focus on making sure my people can think the right way so that at worst they can respond to surprise difficulties or crises on their own but the best hope is that they become better than I am. With the right people in the right environment, if I'm doing my job well I will make myself redundant or superfluous.