4 ms·

Exactly right. The "big picture" argument is nonsense. The whole reason abstractions exist is so you can focus on solving problems with a minimal understanding

by gonyea 10y ago

Exactly right. The "big picture" argument is nonsense. The whole reason abstractions exist is so you can focus on solving problems with a minimal understanding of the minutia. That's how a "real programmer" does it, so making a novice do the opposite is baffling. Showing people how to build stuff with black boxes builds confidence. Forcing them to understand every little detail is overwhelming and makes them feel dumb.

sreenadh 10y ago
"real programmer". I have no clue who you are or what is your level of programming. But I am a product of the school of thought, where the moments you feel like bashing-up your machine or banging your head against the wall while debugging is when you grow as a programmer. The vital part of debugging is understanding what each line does when it is especially a logical error. I did occasionally train developers and I too followed the approach of not scaring them with the details, but I found the few truly capable and interested programmers among them only when there was an error and they had to get into the details. Now I figure why waste my time & that of the student by sugar coating the mess. Instead of teaching a huge crowd, just focus on the few who will actually benefit and let the rest find their interest elsewhere. Programming is a mess and you need a ton of patience and willingness to assume that everything you know is wrong and look at the problem in a different light.
khedoros 10y ago
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".

by gonyea 10y ago

sreenadh 10y ago

"real programmer". I have no clue who you are or what is your level of programming. But I am a product of the school of thought, where the moments you feel like bashing-up your machine or banging your head against the wall while debugging is when you grow as a programmer. The vital part of debugging is understanding what each line does when it is especially a logical error. I did occasionally train developers and I too followed the approach of not scaring them with the details, but I found the few truly capable and interested programmers among them only when there was an error and they had to get into the details. Now I figure why waste my time & that of the student by sugar coating the mess. Instead of teaching a huge crowd, just focus on the few who will actually benefit and let the rest find their interest elsewhere. Programming is a mess and you need a ton of patience and willingness to assume that everything you know is wrong and look at the problem in a different light.

khedoros 10y ago

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".