Think Like a Programmer??

catcarbn profile image Cat Carbonell Updated on ・1 min read

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.


markdown guide

01101001 01110100 00100000 01101101 01100101 01100001 01101110 01110011 00100000 01110100 01101000 01101001 01101110 01101011 01101001 01101110 01100111 00100000 01101100 01101001 01101011 01100101 00100000 01100001 00100000 01100011 01101111 01101101 01110000 01110101 01110100 01100101 01110010 00100001


In all seriousness though, to me, thinking like a programmer means:

  • Thinking about how I can automate things that I do frequently
  • Thinking about breaking problems down into their smallest components
  • Thinking about how a computer thinks, and how my solutions can be best expressed for a computer.

Hmm thinking about breaking problems into small pieces is like thinking "algorithmically". Right?

I don't believe breaking problems in small chunks and thinking algorithmically is the same thing at all. The first is more about reducing the big picture into small problems you can handle in your human cache memory, whereas the algorithm is an abstraction model of a good way to solve the big picture. Usually the algorithm ends up being the big picture on the implementation side. For exampke say you want to implement Djikstra's algorithm. Thinking algorithmically is thinking about what data structure you'll use because of which operation you need to perform on each step. The small chunk is the implementation of a single step or a part of a step.

Yeah, I think I agree with this. The algorithm is somewhat big-picture thinking, though to put it in code you need to chunk it into the smallest components possible to tell the computer what to do. It's a bit tricky, because while an algorithm is defined by small instructions, the algorithm itself is a composition of those instructions...


This is my life.

Also there are 3 points. Always have 3. Just like Andy and his cats


YES! I popped your Binary message in a converter 😆

"it means thinking like a computer!"


FWIW, “thinking like a programmer” means you decode it inside your brains, not popping it in a converter :-P


Thanks for making me laugh, now all my cats are looking at me

Edit: I only have 3 cats


hahahaha DON'T SASS ME.

Update: I see what you did there.
fry sees what you did there


I love this question, because so often do we read it, but don't necessarily reflect on it!

To me - it's thinking logically and in steps with no assumptions made! I am problem-solving at its finest. And, like anything - it is a skill to practice and reiterate on. So usually I like to break down problems or functionality into small manageable steps.

I want A to do B. I get the logic down (or at least try to in pseudocode whether that be mentally or in the form of comments in my editor <-- a much better approach) and then implement it in code.

I really don't worry about my first draft of code being polished, I allow it to be messy. Then, once I get working functionality I go back and comb through it, rinse and repeat.

For me, that above are the foundations of thinking like a programmer.

The next steps are efficiency!

How can I write my code that is explicit and easy to follow?

One thing I absolutely love is - finding new ways to implement code or a solution in a different way. Sometimes I'll come across an article and get so excited when I find practical bits that are relevant to what I am working on and I can implement it in. It feels like a treasure when you can find and see something in a different way! I LOVE that and cherish those moments!

Aside from development in particular, I find myself solving problems in every day life logically. Why carry my groceries the same route, when I can take this different path and get to the kitchen quicker?


Agree. "The code works, but there must be a simpler/more manageable way to do this." Cue a day researching patterns and badly documented libraries just to MAYBE reduce my 60 lines of code down to 5 lines.

When it works, it's the best feeling in the world. When it doesn't, I always learn something i can use somewhere else.


This is actually the most succinct answer I've got here since you broke down into detail what you do by step.

I find myself solving problems in every day life logically.

Right??? I also think about the grocery problem especially if I buy party-sized things and it's raining outside: 5x 2 liter soda bottles, 5x bags of chips -- how can I carry it all into the house, while running back and forth in the rain the least amount of times?


I'm not exactly sure of the context in which the phrase was used. It could mean translating the problem into logical parts and then those discrete parts into code.

However, it seems to me that thinking like a programmer could be detrimental. For instance, I'm standing on the curb at the airport about ready to check some bags for the family. I think to myself: "I will make sure I have all 3 bags." So I count them: 0, 1, 2. Then I think "Oh no, I'm missing a bag!" And after puzzling for a few seconds realize I made a mental off-by-one error.


I'd say thinking like a programmer would mean something along the lines of "modeling out the problem".

It also might mean thinking about the current problem, with a bit of an eye towards the future problem (but not too much!)

Otherwise I don't know, I'd hate to think this question could lead to telling people what "types" of thinkers make for good computer programmers. Thinking like a programmer can mean highly logical or highly creative and abstract.

I'd perhaps say that systems thinking (whatever exactly that means) is a way of thinking like a programmer. An operating system, an API infrastructure, a program, it's all a "system" I think.


I have a background as a writer so maybe my perspective is a little different. But I've always felt that "thinking like a programmer" was about effectively using technology to tell a story that people can follow to solve tasks and problems.


The thing about programming is that it’s so abstract that there has to be room for virtually any mental model. Programming is just a collection of shared metaphors and a few eureka moments along the way.


It feels like that episode in South Park with the underpants gnomes.

  1. Examine problem
  2. ???
  3. Solution

That’s why describing your solution is so often such a big leap from implementing it. Maybe you just tried a bunch of stuff. Now tell me what happened.


Overall, being a problem solver and being willing to learn.

  1. Realise machines do not have thoughts.
  2. See them only as surrogates for thoughts we give them.
  3. Compose your thoughts in the clearest way for yourself and your machines.
  4. The better you understand your machines, the more and better and elegantly you can convey your thoughts through them.
  5. Programming expands our minds and the machine's ability to reflect our minds.
  6. 37BF665A000097CEFFFFMMM\0

I always think that this joke sums it up perfectly:

"The programmer's wife sent him to the grocery store. Her instructions were: 'Buy butter, see if they have eggs. If they do, buy 10". So he bought 10 packs of butter."


HAHA order of operations and specificity.

I remember when I was first learning JS, my friends told me this little anecdote emphasizing the importance of "return"

"You give your roommate a list of things to do:

  • get a pizza
  • paint the door red

At the end of the day, he returns with nothing.
But hey, you got a red door."

You didn't specify if he had to RETURN HOME WITH THE PIZZA so... ¯_(ツ)_/¯


That's a great way to remember specificity, thanks!


A large part of my workflow is working to make existing software more maintainable, or setting up structures to scale a code base and keep it maintainable over its entire lifetime.

"Thinking like a programmer" for me is not just about solving problems or breaking a task down into smaller components, but solving the next problem: seeking to anticipate future problems, and make decisions about the current task based on the long term vision.


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
  • Understand objectives
  • Build paths
  • Split things
  • Recognize priorities
  • Categorize stuff
  • Look for order
  • KISS

It's pretty simple to me... It means breaking problems/issues down to their lowest level in my head and weighing the logical outcomes based on different choices until I can see the correct solution. After 35 years of coding I use this all the time without even realizing it in my day to day life. :-)


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 ?


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.


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


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)

I know that maybe I'm going a bit overboard with this, but I've always thought that programmers might make quite good lawyers and write decent laws.

Unless you're a pentester.


...and now I need to disagree :)

I think pentesters would write better laws than those who have never broken someone else's design, it helps to see things from multiple angles.


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?


How to solve a problem with code, so it can be easily automated.

Many things have a graphical interface that makes them accessible to non-technical folk, but pushing technology down a level so it can become the new base to build upon is how we move forward.


One of the key thoughts of a programmer is or should be:
What sort of shit can happen?

Thinking like a programmer is expecting the unexpected and dealing with the uncertain.


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.


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


  • 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.

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?


Having many perspectives, thinking many possibilities, asking many questions and thinking more and more. If I enjoy, I will dig deeper else I leave it.


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


It means looking out all the options that can occur by a given input in order to guarantee that the output is the one desired.
In a way it also means being "predictive".
This also imply thinking in order to provide solutions that offer to the end-user the most intuitive and best experience as possible.


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.


{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.


I think that any user who considers himself to be at least a little programmer or thinks in a similar way knows that it is very important to update drivers in a timely manner. So I think that for many beginners, the information thinkmobiles.com/blog/best-free-dr... will be relevant, where you can find the best automation tools for this process.


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


"I need to download 20pdf on 20 different webpages" - "let me script that for you"


I think it is a thinking to read here (dev.to).


Expand your perspective in the logical way. So that you know your roots by deriving.


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


Hahaha that was a good laugh, needed that!