DEV Community

Think Like a Programmer??

Cat on May 30, 2018

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.

Collapse
 
gabeguz profile image
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

Collapse
 
gabeguz profile image
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.
Collapse
 
briansotodo profile image
b

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

Thread Thread
 
isaacleimgruber profile image
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.

Thread Thread
 
gabeguz profile image
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...

Collapse
 
alexandlazaris profile image
Alexander Lazaris

This is my life.

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

Collapse
 
javascripterika profile image
JavaScriptErika

YES! I popped your Binary message in a converter 😆

"it means thinking like a computer!"

Collapse
 
ben profile image
Ben Halpern

Same 😅

Collapse
 
andy profile image
Andy Zhao (he/him) • Edited

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

Edit: I only have 3 cats

Collapse
 
gabeguz profile image
Gabriel Guzman

Happy to help! :)

Collapse
 
cat profile image
Cat • Edited

hahahaha DON'T SASS ME.

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

Collapse
 
nlound profile image
Nicolás Lound

But computers can't think :/

Collapse
 
javascripterika profile image
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?

Collapse
 
emptyother profile image
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.

Collapse
 
cat profile image
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?

Collapse
 
kspeakman profile image
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.

Collapse
 
rdelga80 profile image
Ricardo Delgado

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.

Collapse
 
ben profile image
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.

Collapse
 
rdelga80 profile image
Ricardo Delgado

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

  1. Examine problem
  2. ???
  3. Solution
Thread Thread
 
ben profile image
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.

Collapse
 
ben profile image
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.

Collapse
 
jfrankcarr profile image
Frank Carr

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

Collapse
 
cjbrooks12 profile image
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.

Collapse
 
chiangs profile image
Stephen Chiang

Collapse
 
scottishross profile image
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."

Collapse
 
cat profile image
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... ¯_(ツ)_/¯

Collapse
 
scottishross profile image
Ross Henderson • Edited

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

Collapse
 
k2t0f12d profile image
Bryan Baldwin • Edited
  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
Collapse
 
notyoyoma profile image
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
Collapse
 
pablomarti profile image
Pablo Martí • Edited
  • Understand objectives
  • Build paths
  • Split things
  • Recognize priorities
  • Categorize stuff
  • Look for order
  • KISS
Collapse
 
nancyd profile image
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.
Collapse
 
ikemkrueger profile image
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?

Collapse
 
ghost profile image
Ghost

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

Collapse
 
threedeeprinter profile image
Dan Benge

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

Collapse
 
slavius profile image
Slavius • Edited

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)
Collapse
 
revskill10 profile image
Truong Hoang Dung • Edited

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 ?

Collapse
 
noquierouser profile image
Marco González L.

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.

Collapse
 
phlash profile image
Phil Ashby

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

Collapse
 
noquierouser profile image
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?

Collapse
 
alexgwartney profile image
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.

Collapse
 
alanmbarr profile image
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.

Collapse
 
pesse profile image
Samuel Nitsche

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.

Collapse
 
kayis profile image
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.

Collapse
 
cathodion profile image
Dustin King • Edited

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

Collapse
 
isaacleimgruber profile image
IsaacLeimgruber

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

Collapse
 
erhankilic profile image
Erhan Kılıç

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.

Collapse
 
cathodion profile image
Dustin King • Edited

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

Collapse
 
revskill10 profile image
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.

Collapse
 
danielw profile image
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.

Collapse
 
ikemkrueger profile image
Ikem Krueger

Or broken hearts.

Collapse
 
fk2000 profile image
fk_2000

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

Collapse
 
kenthmordecai profile image
Kenthmordecai

sometimes out of the box.

Collapse
 
droidmakk profile image
Afroze Kabeer Khan. M

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

Collapse
 
hilaberger92 profile image
Hila Berger

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

Collapse
 
cyborghead profile image
Amr Hisham Hussein
Collapse
 
sandrine911 profile image
Sandrine911

geekgirl <3

Collapse
 
joshleong profile image
Josh Leong

Hahaha that was a good laugh, needed that!