This is all solid advice. I also note that new managers of programmers should read it as well. Managers feel the weight of the responsibility for the project and when one of their engineers is stuck it puts the schedule at risk. For new managers especially, their instinct is to just tell the engineer how to fix the problem.

That solves the near term schedule risk but does nothing to prevent recurrence.

When I'm managing software engineers I try to make it really really clear that getting stuck is a "known" thing and getting unstuck is a "learned" thing. So to come to me early when they are stuck so we can practice ways to get unstuck. If they wait too long to ask for help, it is a much bigger problem. (and when I am programming for someone I can be just as bad at not asking for help soon enough) for one of my employees who was an ex-marine and really really didn't like asking for help, I got him to think about it as asking someone in their unit to provide covering fire, that is "help" and essential to achieve the objective. They understood that reference really well and we got along great after that.

My point being that everyone is a teacher to somebody, so when an article that frames the teaching as instructor to student, don't make the mistake of thinking it doesn't apply to you. There are things to learn in there.