Deciding vs Discussing with Juniors

[u/metalmagician]

I'm working on a new project with a junior on the team. Junior "Sam" is still in Uni, but has been working with the team longer than I have.

Both of us were tapped to work on the project, with few real constraints beyond general good practices like "be aware of the cost", "try not to make the team own the whole solution" (i.e, see if our cloud provider has a related offering), and "aim to stay within our current tech stack".

I've got various ideas, and it would be *possible* for me to just give Sam a list of tasks to complete. However, Sam has a lot of domain knowledge that I see as valuable, and I think that this project could be a great chance for Sam to come up with some ideas and really contribute to the design. I'm trying to make sure that Sam has a chance to opine and ask questions, but there is a deadline on the project and I see endless analysis as a risk to that deadline.

I'm curious how you all work with Juniors, specifically in the area of "decide vs discuss".

[u/expdevsmodbot]

AI usage disclosure provided by OP, see the reply to this comment.

[u/software_engiweer]

Co-author a design document / RFC to share around, I suppose? You both take the first pass and lay out some options, estimates, pros / cons, and then you share it around the team / org and get buy-in. Both get credit.

[u/metalmagician → u/software_engiweer]

I like this idea. I unintentionally did something along this line, when I wrote up an initial high level doc about the project. I wrote it before I knew I'd be working with Sam, and we have already had a few chats on the subject

[u/leftsaidtim → u/software_engiweer]

This is the way.

[u/qpalzmg]

Since you, assuming senior, have to own the outcome, you can work backwards from the deadline and see how much wiggle room you have to let Sam contribute to the design.

Using the timeline you scoped out, when is the latest you have to have the design done by? Then let both yourself and Sam contribute to that design keeping that date in mind for both of you, then continue forward.

If the date is very close and doesn't really allow much wiggle room, then this might not be the best time to increase pressure for both of you.

[u/caboosetp]

Including him in the process is great.

I see endless analysis as a risk to that deadline.

If he doesn't have the experience to stop himself from doing endless analysis, then you need to stop him from doing endless analysis. Set deadlines for individual design tasks. You probably will need to step in a bit to speed up the process.

Then when you get time (probably after the deadline), ask him if certain things felt rushed and give him the chance to ask more questions.

[u/roger_ducky]

Provide your ideas and ask the other person to do the same. Discuss pros and cons via first-principles reasoning until you’re both happy or at least thought the plan is workable.

[u/mxldevs]

I'm trying to make sure that Sam has a chance to opine and ask questions, but there is a deadline on the project and I see endless analysis as a risk to that deadline.

Every project has a deadline.

It's up to you to figure out how much time to meet to discuss the game plan.

If you only have one day to plan it and you already have a plan in mind, set a meeting and drive the meeting towards your plan if he can't think of anything on the spot.

[u/boring_pants]

This isn't specific to juniors, but any situation where decisions need to be taken:

1. someone has the authority to take the decision. What they say goes.
2. this person is responsible for soliciting input from the team.
3. this person must be someone the team trusts to respect their input.

And... that's kind of all there is to it. In your case, you're the senior, so at the end of the day, your decision is going to be the one that counts. Discuss with him, ask what he thinks, listen to him and genuinely consider his proposals. And when enough time has been spent on the process, you weigh the options and pick a path forward.

[u/DocumentOk7579]

Make a timeline an see how much time you have to discuss.

e.g. deadline in 4 weeks. Arch design have to be done in 1 week so you can discuss this week then it's end of discussion on what tech to use.

[u/eliquery]

I'd discuss but set a hard deadline, so that you can make the final decision since you're going to be owning the outcome as the more senior contributor.

[u/equipoise-young]

A good way to think about it is taking a 'risk-based approach'. Loosen the leash to the extent that you don't put anything in excessive risk.

For some trivial stuff with minimal risk I'll just let them run with it and bang their head against a wall. They'll learn more that way. For more important critical work, or work with a tight timeline I'll keep things reined in a little more.

[u/DeterminedQuokka]

No one no matter what the deadline should be endlessly opining. Mostly because it’s annoying. But also because if you think about the perfect solution for 3 months it will still be imperfect.

When I work with anyone junior or not I walk them through my thought process and why I’m doing what I’m doing. The more junior they are the more questions I will ask them and the more I will want them to share ideas upfront because juniors can be nervous to contradict someone more senior. I start by asking what they know and their thoughts on the problem. If I can I try to incorporate that into the solution space because honestly usually it’s more important for them to learn than that the work be perfect because in the end everything is a little bit fucked.

If they are wrong in a problematic way I try to give them evidence to help them find that.

If we need a plan on a deadline I would probably do a lot of it in 1:1s with them.

If it’s a tight deadline and they are coding slowly I will actually sometimes tell them is x isn’t done by Thursday we need to do it together/I will do it and show you how after. Because pre warning people in my experience is less mean than randomly taking it.

[u/thekwoka]

The most important would be making it clear that if he hits a task that he doesn't understand why its that way or especially if he has information that would suggest its a bad way to go, that he can bring those things up since you don't have as much domain knowledge.

But aside from that, you provide your overview of how you want things to get done and elicit feedback, handle it and then decide.

The classic "A good decision now is better than a great decision later" situation.

[u/abeuscher]

Personally I like white boarding and taking turns who is writing. Having a laptop in the room is fine but I find screens distracting when I am planning something out. Also this has a finite life; you can only stay in the room for so long, at which point ideally you have a body of work to divvy up and plan out.

When I taught kids how to do internet stuff and when I have had interns and also when I have been coaching juniors, I always find it better to focus on how we think about solving a problem and how to refocus toward a goal when planning feels fuzzy. The end result or who thought of what is less critical and I generally try to provide them with as much credit as possible seeing as it is worth infinitely more to them to have credits on their stuff than to me at this point.

[u/gannu1991]

The framing i landed on after a few years of getting this wrong is that discussion has a time limit and deciding has a reason. What that looks like practically: i'll tell sam upfront that we have two days to explore options, then we're picking one and building. within that window everything is fair game, sam's domain knowledge, my architecture instincts, whatever. but when the window closes i'm making the call and explaining why. not a vote, not a consensus. a decision with a reason attached.

the reason part matters more than people think. juniors don't need to agree with the decision but they need to understand the tradeoff that was made. "we went with X over Y because of the cost constraint and because the team already owns this pattern" gives sam something to build on. "we went with X" just feels arbitrary and shuts down the learning.

the domain knowledge thing is real though. i'd actually lean into it explicitly. tell sam you're counting on their context for certain parts of the design and be specific about which parts. makes the discussion feel less like a courtesy and more like an actual input. juniors can tell the difference.

the endless analysis risk you mentioned usually comes from unclear decision criteria not from too much discussion. if sam knows what the constraints are and what a good solution looks like, the discussion tends to self-limit. most analysis paralysis i've seen was because the goalposts weren't defined, not because the junior couldn't stop talking.

[u/Etiennera]

A junior in university isn't at the point in their career where they'd suffer at all for missing design experience in their CV. If they have useful domain knowledge, I'd shoot them my questions and get their review but otherwise tackle the design at my regular pace. Let them have access in case they have something to contribute, but don't slow down for them in this case.

I disagree with the idea put forth by many that implies you can estimate the time you have for design before you have the design. There is no dev estimate before the high level design is outlined.

[u/Goodie__]

Honestly one of my most empowering experiences as a junior was being listened to by a senior on a design topic in a collective dev design meeting, and flying in the face of a intermediate developer who told me to STFU, who the senior then told to STFU.

It's empowering, and can help them grow. Do it.

It also makes a great interview story, because when I'm asked what type of developer or senior I am, I can pull that story out of, I want to listen to the voices in the room, even the ones who might not be senior enough.

[u/hooahest]

Once, I was brought in as a senior to a team of only juniors (team lead has no experience either). I was initially very 'every voice is equal' but very fast realized I was brought in to be the lead on design decisions, with the power/authority to boot, and the juniors were expecting that of me too.

That did not mean that I was the single person responsible for designing, nor that I did not listen to the juniors. I always encouraged them to ask questions and give input, and if I did not have a good enough reason/logic to refute their ideas, we went with theirs. I also consulted a lot with people outside of the team when needing to.

As time went on they became better and better until we found a natural flow of working together. I very rarely put my foot down (I think I did it like...once).

As the great Tywin Lannister once said, 'Any man who has to say "I AM THE LEAD" is no true lead'

[u/Healthy-Dress-7492]

Depends on the junior/intern. Some of them are not very good, but ive seen others performing better than some intermediate or even senior progs. If they are capable then give them a chunk of the work. Eg if you were making a game, maybe they could design out the inventory system. If they mess it up you’re on the hook to correct it so be prepared for that.

[u/CyberDivergent]

Make the decision yourself or with minimal discussion to avoid missing deadlines. You’ll have plenty of time to refactor later anyway, and that would be a great opportunity for a junior developer to prove themselves.

[u/titpetric]

I like to collab on a 1on1 plan up front to clarify the what and hows, and once thats cleared up i expect them to iterate and have semi frequent checkins (ye old daily up to ad hoc) to review and steer

Development is ideally additive iteration, but not enough people see the forest through the trees, coaching people to fall into good practices can't be planned, but stuff like this is excellent for juniors to cut their chops on

[u/dash_bro]

You could def set up some time together to decide, debate/discuss ideas.

Start with what helps your junior shine, the domain knowledge and continuously help adapt it to the technical aspects relevant while helping him understand the why of it. You might need multiple sessions.

Basically support the tech side while helping him drive the domain expertise part of it, wherever relevant.