Immediately after switching the page, it will work with CSR.
Please reload your browser to see how it works.
This is actually something I love doing with our junior developers: Often they have a question every once in a while, or they don't have any questions for too long so I ask them what they're doing currently. Both often leads to me taking a look, and discovering that they're like five miles deep into a dead end without realising it yet, and we spend an hour or two working on their problem together.
I love that time, since they usually start asking more and become increasingly confident calling my decisions into question, which in turn leads me to reflect on why I do things the way I do them, and we both end up smarter than we have been before.
One other thing I often notice is that when you're good at something, you don't care about looking good doing it. I have no qualms admitting I don't know something, or that I'd also start asking AI, or just throw some at the wall and see what sticks. This tends to build up a lot of trust with the juniors, since they realise I'm also just putting my trousers on one leg at a time.
Sure, it can be frustrating sometimes to wait for them to just… get the obvious right in front of them, but that usually comes very quickly. I can wholeheartedly recommend spending time with your juniors!
There's a quality in strong developers which is difficult to select for in an interview but wildly valuable once they're up and running; maybe the best word is "scrappiness".
When I interview juniors or interns, one of the questions I like to ask is something like this-
"You've got two computer, one Linux one Windows. There's 50gb of files on the Windows machine which need to be moved to the Linux one, but you've only got 1h to do so. What's your strategy?"
Anyone with some experience knows it's a bit of a silly question - there are a tonne of unknowns and countless "correct" answers, but that's just the rub - it's not about the academically optimal answer, but about coming up with an answer that would probably work, given the constraints I'd be arbitrarily throwing at them. It's about realizing that the vast majority of decisions we make in software engineering have costs and tradeoffs, and being able to discuss them with a colleague is 10x more valuable than graph traversal.
More than anything, I try to select for people that I know spent a good chunk of their formative years behind the computer, just like many of us did. The maze-traversal skills you learn as a child installing Ubuntu on your parents' computer stay with you forever. Given the option, I'd take the self-taught-indie-dev-state-college-grad over the honor-roll-ivy-league-leetcoder any day.
> The expert’s intuition is often formidable, but rarely comprehensible. This inability to clearly explain their decisions is what makes it so useful for novices to spend time with experts.
I really like spending time with novices, especially if they are truly interested in the domain. It’s symbiotic because it also challenges my own opinions and judgements and the boost often is for everyone.
It’s not surprising though that it is hard to explain rationale. How one can fit 2 years of pain in a sentence, a paragraph or even day long story?
Direct interaction allows to shorten distance because it aligns on exact personal level. We find the efficient channels of communication based on prior experience, so it’s not building one filar from ground up to have a bridge, but instead use the almost-same-level and build upon it on both sides.
I'd add, work on the niche things that no one else wants to work on but need to be done. That's how I quickly advanced in my career, becoming knowledgeable about systems no one else wanted to touch.