Interesting question, but I wonder if it can even be answered, and, if I can answer it, is it worth even doing so? Could you yourself adopt the same mindset I have when I work just by simply reading my words?

When I am coding I tend to be very 'visual'; the whole structure of the code is largely just shapes that get kinda shoved together, lines drawn between them (connecting them), and they warp in to many different things as I ponder the structure. Also I do all this with a single goal in mind - whatever the particular goal I am working on.

It's extremely difficult to describe since - when I think of a member of a particular class, I sort of zoom-in to the giant square that is ClassA and imagine attaching functionality to it... then I zoom out again to perceive its effect on the whole structure of the code itself, or normally, just the area I am currently working on... Like Google Earth, the farther I am zoomed out the less 'fine' detail there is, and as I get closer to an object the more detail I see.

I definitely don't start typing until I have at least a basic idea of how a feature will work. After I figure out how to implement the feature and while I am doing the implementation, I think a lot about what the side effects, special cases, and limitiations might be. That's when those issues are most visible. When the implementation is done, I test it to verify basic functionality and also test potential problems uncovered during implementation. It might take a couple passes, too.

I tend to do the same as JohnBolton.

I also tend to work outwards from core systems. For example, in my latest project, I began by Building the Window and Application Classes, Followed by Renderer Abstraction, Resource Cache, and then my GameState Manager. When it came time to write "Game Code" 95% of the Engine was in its final configuration, making it very easy and very quick. I can, and have, knocked out simple game-states (such as the credits) in less than 5 minutes.

I also tend to re-factor as soon as I see a "real problem". For instance, initially, my Resource System was based on handles. This had the unfortunate side-effect of forcing my Resource Cache object to be a singleton to get the behavior I desired (handles should directly "dereference" to their resource type). Switching from a handle-based implementation to one based on smart pointers provided the behavior I wanted and also resulted in shorter, cleaner code all around. Despite the centrally important nature of the Resource System, none of the "game code" was disturbed, because the interfaces were solid -- that's another thing I tend to think about as I make implementation decisions: How might I have to change this system in the future, and how do I design now to make it easy to change in the future?

Quote:Original post by Virtual X
This is a very interesting topic which I feel could help people starting out, so share your techniques on how to think while programming :)

And such things (or things similar to it) are a little too infrequently discussed.

Quote:
I believe the problem when starting to code is in not knowing how to actually think effectively when coding, most people just start out learning a few functions and going from there, but is that enough on becoming a professional?

No, not really, though you might be surprised how many professionals know a few functions and go from there.

Personally, I think there's a distinct middle step where you need to better understand the difference between programming (fighting with syntax to do what you want) and program design (fighting with organization to allow you to do what you want more easily).

Quote:
is there a particular mind set you must have for a particular language and is it possible for everything just to 'click' in to place after understanding certain key concepts?

For some. Functional programming is notorious for this. Sure, it's possible to make fairly large leaps after catching a certain concept. Pointers are the often given example since they tend to have that 'click' effect. Still, things don't just snap and suddenly you're a competent programmer. Even professionals have strengths and weaknesses, various levels of expertise with various flavors of problems.

It depends on the task being performed. Sometimes you have to be in the optimization mindset, where you are writing efficient code. Other times you have to be thinking one step ahead and anticipating the problems that the current piece of code could cause. Where are there likely to be errors or malfunctions. You also have to be aware of when you need to break up code or split out common code, etc. Evaulating the refactoring needed in advance.

Writing from an existing specification is different than developing some new technology proof of concept.

Quote:Original post by JohnBolton
I definitely don't start typing until I have at least a basic idea of how a feature will work.

Ditto. But that's usually as far as it goes.
when I start coding I have a very "outide->in" way of thinking and an "inside->out" way of working

Outside-in, about how the caller would want to use a function, pre- and postconditions, extra member variables. I put down al lot of the function prototypes before starting to write the internals of the functions. My train of thought is like "this will call that, that will need this information, then that will pass...", having a big part of the program flow in my head with the function prototypes as a manual, and keeping an eye on the possible problems.
At work I do TDD and after having written the prototypes or having the flow in my head I decide if and how I can test something.

Inside-out, I implement the internals of the least significant function first. Why? Personal taste, and often the top-caller can't do anything without the rest working. Or you have to write dummy functionality, which I do if I ever happen to be implementing something the other way around. Now I think about it, I guess it's also easier to work inside-out because you can fully focus on the current function without having to worry about anything that is not implemented yet.
Along the way if I see something is amiss in the way of a function getting too long or me having forgotten something in the overall picture I take a minute and contemplate my next step. And then I attack the problem right away before causing any more harm.

After the implementation I do at least one second pass to improve the code. Such as removing redundant function parameters, split functions into smaller ones.

Now, I notice this is more my way of working that my way of thinking. I guess it's hard to describe or even be aware of something that is so natural to us. I guess in general my mindset is best described as chaotic during the layout/design of a piece of functionality and very formal and structured while implementing the internals of the functions.
I always notice this when I am discussing things with my colleagues. Discussing or brainstorming about design stuff is awfully hard while discussing implementations is easy as pie. I think one of the causes for this is that an implementation is usually an exact science, whereas the design of something is more personal and open for different solutions that may be equally good.