I have seen so many developers utterly fail at this. They require not just a particular language, but a particular framework and a certain specific mountain of abstractions. Any less that could remotely expose their incompetence is immediate cause for rebellion. Their strong arguments are whining and excuses instead of simply figuring it out.
I don't want to have to work at as a baby sitter if I am hired to be a senior developer. Some junior devs are a pleasure to work with and really bring appreciation to the job and others make me want to quit and go do something else.
I say junior devs, but I have also encountered some senior devs whom I would describe as junior.
I would actually rephrase this and go a step farther -- I have met many people who don't like to learn, full stop. They learn the minimal amount necessary to carve out safe, known territory, and do all the work they possibly can to NOT LEAVE THAT AREA.
This is obviously a great survival trait and may be good in some careers, but it's not a trait I'd like to see in a developer, especially one I fully intend to do my best in growing.
I work with people who did things their own way for 10+ years, never worked as team, never kept up with a quickly changing industry, never improved their skills, that now they're opinionated, they feel that as long as something works it's good to go, etc.
Introducing them to a code review workflow exposed how truly uneducated they were. Code review turned into education sessions, explaining how fundamentally they've misunderstood or misused CSS, javascript, or the tools we use.
It's dramatic how much money and time is wasted because no one with authority to fire them wants to. Back when I ran my own studio I let people go the instant it became clear they weren't going to make it, but these people couldn't pass a simple interview with me.
My company sees it but keeps trying to find ways to solve the problem. You can't throw training at it, you can't throw more meetings.
While it may often seem simple to "just Google it," it can be difficult for people to come up with appropriate queries and weigh results, especially in new/unknown contexts.
A lot of the time we have ready answers if other people ask us questions because we're actively ready to attack and criticize to get an answer, but we're more reluctant to do that with ourselves. So if the teaching approach doesn't work, then another way is to ask him to list up the questions he has, give it 10-15 minutes, then review them himself to see how he would answer them -- the idea is to give him some time to "reset" and get a fresh perspective.
When it was my chance to mentor, I would sit with the junior guy and just talk about the context and problem at hand. Talk about the keywords and then form a query to google. I would sometimes intentionally put in the wrong query and then refine it for better results. It worked.
But juniors are sometimes bad at retaining processes and a similar query would pop up in a few weeks again. Then I would just send them a lmgtfy link (which is a dick move. Don't do this). Have some compassion, patience and empathy. It might take longer but that guy will thank you in the long run.
The skills can be learned and refined over time, but the fundamentals need to be there; if a developer doesn't have the right mindset or ability to learn, then they're never going to grow, no matter how much you poke at them.
One issue I've been fighting (with myself) is knowing when to criticize and knowing when to let him go; I err toward the latter a lot, especially technically, but lean toward giving advice sessions or examples when it comes to communication/professional growth skills. The reason I do this is because it's much, much easier to refine technical skills than it is to refine personal skills... and the personal skills are equally as important at a small company when time is precious and you're working directly with other people who are also under heavy loads and pressure.
I bring this up because I was surprised to see zero mention of independence as a prized quality after the author commented that he did NOT feel like a cog in the machine at the BBC. There is, I feel, a fine line between needing to be told what to do every time and being able to make the right decisions on your own.
The latter quality -- reasoned independence -- is something I think every work environment should foster in its team members in order to have a team that respects and can support each other. Teams fall apart if members need to be told each and every thing they're supposed to do: members will either grow to hate that or will become mindless minions; the team falls apart when the order-giver is no longer there; over-communication becomes an issue and more time is spent in meetings or replying to 100+ e-mail chains instead of developing things for customers.
I rarely see much talk about this kind of growth in developers here though... and it makes me wonder if I'm misguided in placing so much importance on this concept.