I like the bottom-up approach more than the top-down. Begin with a simpler form of a system. Show how abstractions are built on top of it, and allow you to hand

I like the bottom-up approach more than the top-down. Begin with a simpler form of a system. Show how abstractions are built on top of it, and allow you to handle increased complexity with a similar cognitive load. That's easy to extend to using someone else's black box code, with the added benefit that when you find the holes in the abstraction, you're equipped to dig into its implementation and find a way around the shortcoming. Showing people how to build stuff with black boxes builds confidence, until the abstraction fails, or something in the black box doesn't work the way they expected (and they don't have the experience to look inside and figure out the problem). They ask about the problem, and in the short term, the best case scenario is that they're handed some more black box code that fixes their current problem. It's true that you can't just throw a student in the deep end (forcing them to understand every little detail of a complex, layered system). You'll discourage them. On the other hand, the most discouraging thought I've ever had while working on a project was "I don't know what's wrong, and I don't know how to find out".