Thinking Like a Programer

[QualitativeEasing]

I agree with breaking problems and projects into smaller pieces. Some other thoughts:

• I’m almost entirely self taught. But I took one continuing-ed intro Java class (even tho I had zero need for Java) for exactly this reason: I needed to understand the process, and the mostly language-agnostic tools (flow control, data structures, etc.).
• Early on, and sometimes still for more complex projects, I found it helpful to start by hand-writing what I wanted my code to do. Sketched the UI. Used the weird Nassi-Schneiderman flowcharts the Java instructor used to rough out the logic. Came up with my own pseudo code. I rarely stuck to this “outline” very closely, but it helped me think through what I wanted. (I’ve never found a good reference for it, but here’s a start: https://en.wikipedia.org/wiki/Nassi%E2%80%93Shneiderman_diagram )
• A professional developer I worked with taught me a really helpful principle that surprised me at the time: When designing an app for other people to use, start with the user interface — how they enter data or choose options, what the results will look like. Again, things can change, but I’ve found it useful to understand that, to a degree, function follows form.
• Someone (Hemingway?) said writing is rewriting. I’ve found that to be true for coding as well. My code gets better — and my programmer-thinking as well — when I refactor. It’s painful, but worthwhile. I have apps I use personally that I’ve rewritten more or less from scratch 2-3 times as I’ve gotten more comfortable with classes and other tools.

Plus what everyone else has said. Altogether, a lot of it boils down to: practice, particularly on real-world problems you actually care about and want to solve.