## DEV Community

Cat

Posted on • Updated on

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

Gabriel Guzman

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

Gabriel Guzman

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.

b

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

IsaacLeimgruber

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.

Gabriel Guzman

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

Alexander Lazaris

This is my life.

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

JavaScriptErika

YES! I popped your Binary message in a converter 😆

"it means thinking like a computer!"

Ben Halpern

Same 😅

Andy Zhao (he/him) • Edited

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

Edit: I only have 3 cats

Gabriel Guzman

Happy to help! :)

Cat • Edited

hahahaha DON'T SASS ME.

Update: I see what you did there.

Nicolás Lound

But computers can't think :/

JavaScriptErika

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?

emptyother

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.

Cat

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?

Kasey Speakman

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

Ben Halpern

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

Ben Halpern

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.

Ben Halpern

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.

Frank Carr

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

Casey Brooks

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.

Stephen Chiang

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

Ross Henderson • Edited

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

Cat

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... ¯_(ツ)_/¯

Ross Henderson • Edited

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

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

Pablo Martí • Edited
• Understand objectives
• Build paths
• Split things
• Recognize priorities
• Categorize stuff
• Look for order
• KISS

K

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.

Gene

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.

taniafarhat

Hi, please can you help me with a progressive web app I want to create?

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?