4 ms·

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

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

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.