Coding has a way of making people feel stupid, and that's absolutely true for me. And I think it's related to the challenge of logic in general, but not the same.

We have this ingrained sense that we should begin at the beginning and read through text.

Unless you have a very strange mind or an incredible amount of experience and some very particular goal, this is absolutely not what to do with code.

I can't tell you how many times I've tried and failed to find an entry point in my own code so that I could get back into understanding it and making progress with it. And I can't tell you how stupid and incompetent and hopeless this makes me feel.

So - I want to tell you a secret: It isn't about being smart.

When I went from writing that code to feeling how I just described, I did not actually get dumber, or forget how to do this.

And I've gotten lots of good information - which really helped me - about this stuff from people who seem decidedly average in terms of intelligence (an opinion, of course, and I don't mean that in any sort of judgy way - people have so many kinds of value).

There are several tricks that I can't fit in one post. Maybe 3 essential ones. But the biggest on the topic of feeling stupid - not even understanding your own code, for example, or anyone else's, and feeling completely stuck - comes from the fact that we want to read code the way we read an article. That isn't right.

The way to "read" code is to change something and hit Run.

That sounds too simple. It probably isn't quite believable.

If you want, I can link you to an article that helped. It goes into much more detail. But maybe you'll believe me when I say that this is second-nature to the best hackers. Your first teacher - or ten teachers - probably won't tell you. It's something most people who know don't really think to say. But it's common knowledge once you get to a certain level.

I'm not sure why coding is so fundamentally interactive. But it is. It isn't a lecture, it's a dialogue. The other side of the dialogue would be messages from the compiler (when things don't work) and the behavior of the app (when they work well enough that you can play with the result).

(Also, when you don't know how to solve a specific error, you've got other people, search engines, and every question other people have posted online. That's an additional wing of dialogue, if you need it. It isn't what I'm focusing on right now, because you yourself can do more than you think. But don't forget that coding languages are actually designed for people, not computers, and there are many other of these people creatures, and professionals rely on these resources also. Most API specs and manuals are online, and you get to them with a search: that too is consulting other people. So one way or another, asking others is generally necessary, even if you're like me and you like to figure stuff out and don't like to ask for help.)

You get a sense for where things are, what they do, etc, etc, etc by changing and running the code. That creates your mental map of the system. For some reason (which I don't understand either), this is the natural way to get in tune with the architecture of the logic. If people don't tell you, it's because they've forgotten they ever didn't know, or it's just their basic personality to tinker and learn that way. That's "reading." It's how to start. And it's how to get unstuck.

Believe me, you can stare at code for hours, days... even for months on and off... even a year or more. I've done it. Many times. Painfully.

Change something. Hit Run.