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.

[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?

[Daniel Waller (he/him)]

The most important part for me is: "MAKE NO ASSUMPTIONS".
Assumptions without asking to clarify will inevitably lead to extra work.

[Ikem Krueger]

Or broken hearts.

[Dustin King]

I think the different types of artifacts we create each correspond to a way of thinking: source code, scripts, architecture diagrams, spreadsheets, dev tools, etc.

These ways of thinking are our real tools.

Edit to add: LOL @ the video

[Alex Gwartney]

I would say being able to think like a programmer for me. Is being able to break a process down into a bunch of smaller steps. For instance, if you wanted to make a button do something you would break the process down. Such as hover over the button. Process button clicks and performs the action you want to perform. I would say thinking like a computer just makes the concept a bit more confusing. But for me its just being able to logically work through a problem.

[Sandrine911]

geekgirl <3

[Alan Barr]

Usually it is stopping to listen to what the problem is and what the purported solution may be. Then thinking deeply about what possible solutions could be for the use case. Then breaking all of that down into separate problems to be solved.

[Dan Benge]

Thinking through problems logically from the beginning and all possible endings. Being analytical.

[Slavius]

That's exactly it. When people say they want to break the problem down into smaller pieces, that's not programmer thinking, that's architect's role.

Let's say you get a task that you need to write a function that returns a list of database records from start# to end# (e.g. one page of results).

This might be probably a oneliner (sorry, I think in Linq). How do you break it into smaller pieces?

It's more about being able to analyze the problem in your head and then write it in one take.

First ask yourselfg a question: Do I have all important inputs to complete the task? No? Go grab them!

The things important here are:

• Initialize your variables
• Sanitize your inputs (function parameters are integers > 0; end > start)
• Handle all possible conditions (returns 0 results [do not return null but empty array/list], handle exceptions, return max. configured list of results for one page)
• Handle your dependencies (is DB object provided by DI?)
• Document your code (function result, parameters, throwning exceptions)

Another things you should do:

• Test your function
• Make sure the function integrates well (place and name is right, parameters are of correct type, has no extra dependencies if possible)
• Make sure the function is optimal (if the function is executed tens of times per second it must be fast)