DEV Community

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

Top comments (58)

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)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.