Learning how to differentiate between when it’s reasonable to ask for more help and when it’s not is an important skill to pick up since there’s a dividing line for basically all roles you might find yourself in.
Learning how to differentiate between when it’s reasonable to ask for more help and when it’s not is an important skill to pick up since there’s a dividing line for basically all roles you might find yourself in.
Just a few weeks ago at work, one of the TLs told me I should ‘just do X’, and when I pushed back saying it’s going to take a few weeks, he said ‘oh it’s just a couple of lines, I can do it in 10 minutes’. I challenged that. 5 integrations and 2 weeks later we had a first working version, that caused more harm than good in the end because of an assumption that didn’t hold.
I think easy things might be easy in theory, but not necessarily in execution. So when a student comes to you, I suspect they have thought about theory, but find the execution hard because of the knowable unknowns they are not aware of and you are. Many times people don’t even propose things that might seem obvious to them out of fear they might say something stupid. Indicating something is easy in a demeaning fashion is bad. Phrasing it differently has a different effect. E.g. Oh, I think that might be solved with X. It should be relatively straightforward. Look at the work I did <here>, it should match your use case.
My point is that it’s not just about the language you use. Not saying “just” isn’t a magic bullet. Regardless of the phrasing, there’s a lot more pedagogical work that needs to take place to build a good environment.
What would be lost if you said "I think it would be easier if you did Y instead."?
That would convey the thing you think "would be fine" without any of the negative baggage that use of "just" can carry.