I am a newbie, studying programming and I came across this question today:
A commenter, ChaosPandion, had asked the question if the programmer thinks in syntax or in a faster mental model.
I, while writing a solution will always think about the number of loops or condition to be used (for example). Am I doing it wrong? If so, how can I correct myself and what should I learn?
How a programmer thinks about a problem (and a solution) depends greatly on how they think about things in general, the problem itself and their level of experience in particular. Let's go through them in order:
How people think in general
Different people learn, and think differently. Personally, I am an extremely visual thinker, and tend to use a lot of intuition about how things "fit". That's literally because I have a mental model for different patterns, modules and dependencies within the code. When I can't arrange them into a nice shape, I know the solution isn't adequate.
Others are very logical, they have sets of facts that they look to reduce into a result. Yet others are tied to verbal or auditory sort of learning. They need to hear a problem described to understand the relations and emphasises of it. And of course, nobody is "just" visual or "just" verbal. They mix and match at different levels.
The problem itself
Different problems require different solutions. When I'm designing a architecture to handle thousands of transactions a second, I think about it differently than I do trying to make a scheduling algorithm. They have different needs, and using different problem solving approaches allow me to be more effective than using the same approach for everything.
The Programmer's experience level
When beginners start out, they know syntax and (if they're lucky) they have a good grasp of the concept of variables. When presented with a programming problem, they're going to tackle it with these concepts, because that is what they know.
As they gain experience (especially with different languages/paradigms) they begin to abstract away the concrete syntax into concepts. Instead of thinking "oh make a class that inherits from XYZ" they can think "I need some sort polymorphism here". Design Patterns (when used well) are the sort of thing that extends this further so that the programmer can think about tools that encompass broader swaths of syntax.
This is the primary reason that "learn a variety of programming language paradigms" is a common suggestion in the development of programmers. It's also why C++ has greatly fallen out of favor as a first programming language (in some circles) - you spend too much time thinking about syntax and not learning how to solve problems.
(tl;dr) In general, for most problems, programmers move from thinking in syntax to thinking in their own mental model as they gain more experience.
Your statement that you sometimes think about the "number of loops or condition to be used" is actually a particularly good discussion point.
Observe this code here where you have to explicitly think about the number of loops and the condition:
for(i=0; i<data.size(); ++i) { action_func(data[i]); }
and this code here - which achieves the same result - where you don't:
std::foreach(data.begin(), data.end(), action_func);
My interpretation of what is an efficient/faster mental model of programming is that someone who has one, doesn't add complexity when it isn't needed and sees right to the core problem and not the peripheral ones. This is important because programming is about seeing layers of abstraction from the highest to the lowest level - it is about working vertically in a stack through these layers - not complicating things horizontally. That's the only way to achieve the writing of application code that actually works in a reasonable timescale. Embellishment within a layer comes later. Think Agile - getting from A to B (e.g. client GUI to server-side database) as quickly as possible.
So in the example above, there is no need to talk about loops or conditions - it's not what is trying to be achieved so you don't worry about it and you use the programming constructs at your command that avoid that issue (and a whole class of bugs associated with it). Maybe later, if action_func becomes something more complex you might need to explicitly count the loop. Programming is about expressing what you want to do in the most concise way. In many ways you don't care about syntax - the compiler/interpreter will help you get it right. You care more about the conceptual exactness of what you are trying to do (then you simply search SE for how to write that with correct syntax :)
As to the question - what to learn? My advice is to learn functional programming techniques/learn a functional language where there is a clear separation between algorithm and secondary effects and most concepts you'll learn will have mileage in all mainstream programming languages.
Just keep programming. Given enough and diverse practice you will notice one day (may be a year from now), that you are at the new height and can "program everything".
Hard to tell about programmers in general, but I do not think it's "thinking in syntax". One just translates thought to syntax, which usually becomes a habbit. That is why dynamic and expressive languages like Python are so popular: they allow to write at the speed of thought.
So yes, with practice you will arrive at faster mental model, which, with even more practive, will encompass even more entities at a time.
Do not forget to read some theory on data structures and algorithms, because, while not critical to get programming skills, it adds diversity to your thinking.
Syntax is what conveys semantics. And programmer deals with semantics of solution, syntax being a mean to tell semantics to computer compiler/interpreter.
Number of loops may need to be counted if you are using too many nested loops. But analizing complexity of an algorithm is a theory of it's own.
Also, IMHO, programming is a skill like riding a bike: once learned (you will notice the jump to the new level!), it's there with you. There are different paradigms and approaches (imperative, functional, logical, you name it), but the core skill spans them well, and is not unlike to core of mathematical thinking, i.e. ability to formalize and operate with symbols.
