Think Like a Programmer??

I've heard and read this several times everywhere around the techmosphere.

So I must ask: What does thinking like a programmer mean to you?

UPDATE: For all of you who answered, "Think like a computer!"
I've got a video for you.

Comments

[Josh Leong]

Hahaha that was a good laugh, needed that!

[Dustin King]

{thing i'm looking at} isn't in my favorite language!^[0] ::throws temper tantrum::

Seriously though I think this assumes there's just one kind of programmer, or one way of thinking for programmers. But if I had a specific problem I could tell you how I'd think about it.

.^{[0] Python, of course.}

[Truong Hoang Dung]

You have to know what programming is first. Only then you can start thinking in it.

Programming is the art and science of turning a set of ideas into a list of computer instructions.

That's it.

You have to think both as an artist and as a scientist.

To program as an artist, you have to read The Art of Computer Programming

To program as a scientist, you have to read The Science of Computer Programming

Simple ?

[Truong Hoang Dung]

To me, thinking like a programmer means you can define the problem space and solution space. Then you could make a plan to go from the problem space into solution space.
For some tasks, you might not need a computer to do it, but a computer could help you execute it for you to test it.

Just focus on the: Think like a programmer, not think like a computer.

[Amr Hisham Hussein]

stackoverflow.com/search?q=Think+l...

[Hila Berger]

For me, thinking like a programmer means thinking how to write your code as readable as possible.

[Marco González L.]

Actually, it might be quite interesting to see how could that happens. We might end up having black hat and white hat lawyers.

But isn't that what we do have in real life?

[notyoyoma]

IMO to think like a programmer you must:

1. Take time to understand complex problems
2. Discern whether solutions will work based on your understanding of that complexity
3. Use tools effectively to solve those problems

[Nancy Deschenes]

Maybe I'm not a programmer, more a systems architect, because what I do day to day, the way I think, is more complicated than most of what has been listed.

The way I think is generally 20% "how to make things work" and 80% "how to prevent things from breaking". The happy path is easy. It's the potholes and detours that are hard. I think about the implications of a proposed solution - will it impact other components of the system? What does it imply for edge case? Can it handle the printer catching fire, or the database being hijacked by aliens?

I don't ask "can it fail?" but "under what conditions will it fail?" Then I compare the likelihood of failure to the damage that would cause. If a user enters bad data and gets confusing results, that needs to be fixed. If it only fails once the Java Date maximum value is reached, yeah, I'll live with it.

So, I think this may illustrate the difference: "how do I get to Starbucks from here?"

Normal person:

• Go East of 1st Avenue to the second traffic light, take a left, go about 1km and it will be on your right

Programmer:

• Go East on 1st Avenue. If you pass a Walmart, you went West - turn around. At the second traffic light, turn left. That's the side of the Shell station (what? I'm not the only one who sometimes gets that wrong). If you see the school, you went too far. After you turned left, go about 1km. The Starbucks is on the right - after the bookstore, but before the hospital. Are you going now? it's 7:30PM, and that Starbucks closes at 7.

[Ikem Krueger]

The way I think is generally 20% "how to make things work" and 80% "how to prevent things from breaking".

Pareto principle at work.

Under what conditions will it fail?

I think it is as important to ask:

Under what conditions will it succeed?