How does a programmer think?

Question

This may be a hopelessly vague question. But I am interested to hear whatever logical thought processes people go through when learning a new concept or trying to get their brain around code they might not have ever seen before.

Basically, what general steps does one take to to break down problems and what does it take to "get it"? If you were to diagram a flowchart of how your mental process works when you look at code or try to solve a problem what might it look like?

What common references, tips, and mental assumptions do you find useful in problem solving?

How is this different between different domains? For example in what ways is a web programmer's thought process similar or different from a traditional desktop app developer's process?

Answer 1

This is one of the rare times I would answer with "it just works." I learn things by steamrolling through them. I don't have gimmicks, or devices to help me. Took me some time to learn PHP, but after that Javascript was much easier. Once you tackle one thing, the next items become cumulatively-easier.

Answer 2

Personally, I conduct an internal dialogue with myself 'OK so we need to loop over this list of integers.' 'But we can break when we find the value we want.' 'OK, will the list definitely be initialised when we start?'

I'd be interested to see if any psychological research had been done on problem solving techniques.

Answer 3

I don't think... I process.

This is actually less flip than it sounds. I always break down tasks into their components and then break these down further, and that doesn't just go for writing software! Much like @Mark Pim U go through things sequentially.

My wife gets really annoyed when I make dinner because I take so long to get started.

Answer 4

Similar to Jonathan Sampson - it kind of just works.

When I'm attacking a real problem, I try and think of the most logical way of getting through it is. Then, when everything goes wrong (as it usually does), I have to make hundreds of sidesteps to get things done. Just keep focusing on that end goal, that logical way and you'll get there.

Eventually though, it decides to work for me and I end up with a finished product that is usually nothing like I planned it out to be. As long as the customers are happy, I am!

Answer 5

Ho ho, good luck with this one. It's a great question and I'm sure you'll get a ton of answers. Although I have to say I cannot give a satisfactory answer to this - the last thing I would describe my thought processes as is a flow chart - I don't think there is any golden formula for this.

The only tip in problem solving I can recommend is discussing it with somebody else. In those times when you hit a brick wall, going through it with a colleague is invaluable. Quite often, as well, they will actually not even add much to the discussion - in the process of getting all your thoughts out in the open, the solution can become clear.

Answer 6

People are notoriously bad at examining their own thought processes, but I'll give it a whirl. I test very high for visuo-spacial ability in IQ tests, medium-to-high for verbal skills, and moderate for mathematical skills (explains my A-level Maths grade, I suppose). amd when I start to design software, I think in terms of shapes and the connections between them. When it comes to describing these thoughts to others (or clarifying them for myself), I use simple block diagrams or the object diagrams taken from Jacobson's Objectory method - NOT the over complex stuff that UML suggests. I sometimes write textual descriptions of complex things, mostly as reminders to myself, but never use numbers or maths.

Of course this is just me - I've worked with maths whizzes who were just as good or even better programmers than myself.

Answer 7

Personally, I see code in my head pictorally rather than textually (like Neil Butterworth) - it's a bit hard to describe since (quoting STIV) "there's no common frame of reference."

Answer 8

Divide & Conquer

I start by trying grasp the entire problem as it is, and then start to find patterns I can recognize, and do the same for them in a kind of recursive process, until I have a broken down solution I can implement and follow more easily.

Answer 9

My main skill is identifying similarities between models or systems I already know about and the task at hand. The connections between some of these can seem quite abstract; the key is to spot the connections. This leads to the abstraction of common patterns and approaches which are widely applicable. Related to this, the most important thing I learnt about algorithms was that the problem is never 'come up with a smart algorithm to solve X'. It's 'model problem X such that it can be solved by existing smart algorithm Y'.

Answer 10

I'm a big believer that no matter what type of application you're looking at for the first time, may it be a web app, a desktop app, a device driver, or whatever else, there are three steps one developper usually follows in order to understand how it works :

Get the big picture :

• What kind of app is this (web, desktop, ...) ?
• How is it layered (standalone, client-server, n-tier, ...) ?
• What is the app's purpose ? What is it supposed to do ?
• Who is the app made for ?

See how it works :

• What language(s) is (are) used ?
• How is the code structured ?
• How is the data structure ?

Understand (or at least try to) the way the app has been thought :

• Has it been thought at all ?
• Is the app clearly optimized ? (for performances ? for readability ?)
• Is the app finished ? Or is there room for evolutions ?
• Are there signs of multiple releases ?
• etc...

The 1st and 2nd steps are purely technical, while the 3rd MUST be as untechnical as possible...it's more about psychology and understanding how the app has been built. It obviously requires experience, but as long as you think hard enough and don't waste your brain's time with technical details, you'll eventually get it.

This whole process shouldn't require the use of a keyboard. You're only supposed to read, think, and take notes on a paper (I'm not kidding : pen and paper !).