The mindset of a programmer | Hacker News Reader

The mindset of a programmer

prognst.tumblr.com

14 pointskiyanwang5 comments

>If you teach programming, realize that your students most likely won’t have the correct mindset and you need to teach that mindset to them. No matter how much you explain what a snippet does and how it works, your students won’t get it if they don’t realize to think about what those statements actually do and what the big picture is.

Purely awful advice. There is nothing more of a turn-off to a person learning programming for the first time than, "You can't just drop in this jQuery module that solves this one issue for you and move on to the fun part! You have to stop here and delve deep to understand exactly what's going on before you can move forwards."

I would say that's the opposite of the essence of programming. If you can understand what a line of code does from a black-box high level, that's often good enough to move on and complete your project.

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.

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

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

Seems obvious, programming is very much a way of thinking, so of course you have to develop that mindset to do well.

Reply on news.ycombinator.com