DEV Community

Cover image for What is the Best way to Learn to Think Like a Programmer?
Anita Olsen
Anita Olsen

Posted on • Edited on

What is the Best way to Learn to Think Like a Programmer?

Coding jargon, coding questions, code logic, problem-solving skills, logical thinking, creative skills, see things from different angles and thinking outside of the box come to mind. I want to improve and become the best programmer I can be, so I would like to know the best way to learn to think like a programmer.

What would you say is the best way to learn to think like a programmer?

Top comments (17)

Collapse
 
zaparka profile image
Petr Zaparka

Here is my list:

  • Understand why / how code works. If you have a deep understanding of the technology you use and its underlying principles, you will learn new things much faster. It's called first-principle thinking.
  • Ask questions about things you don't understand and ask for feedback. This way, you will learn how other developers think differently about the problem you are trying to solve.
  • Learn about design patterns and why and when they are used.
  • Every time you write code, think about possible ways to improve it. Learn about KISS and DRY principles.
  • Don't try to be too clever. The best code is the most readable code. If you manage to refactor five lines of code into one, but no one understands it at first glance, you made your code worse, not better.
  • Use names for classes, methods and variables that make sense.
  • Learn by doing. You will make mistakes, and that's okay. However, you need to make sure you learn from them.
  • Take responsibility. The difference between a good developer (not a coder) and a great one is owning your mistakes and being open about them.
  • Learn to communicate about code-related issues with people who are not technical. If you can explain a problem to your manager who has never written code in a way he understands, you will have him/her on your side.
  • Read programming books.
  • Sketch problems on paper to make sure you understand them.
  • If you are faced with a decision, write down as many possible solutions as you can and choose the one with the fewest drawbacks.
  • Understand how you make decisions - track your decision-making.
  • You need to learn when to take a break and step back. You will be in problem solving mode that doesn't lead anywhere. You need to step out it, go for walk and see the problem in new light.
Collapse
 
ddaypunk profile image
Andy Delso

Really like this list! The only addition or comment is to not read best practices like they are law. There are times to use them, and times to avoid them. Learn where they make the most sense. This is why I tend to think of DRY instead as AHA, Avoid Hasty Abstractions.

Collapse
 
janmpeterka profile image
Jan Peterka • Edited

Nice list!

Use names for classes, methods and variables that make sense.

This is extremely important for maintainable and enjoyable code, and also really difficult.
Remember that code is both language to communicate with computer and with other people (other developers, you in on year, testers, tired you, PMs possibly). The "people" part is often much more difficult.

Some ideas how to get better (in my opinion):

  • Learn language. You are probably wrinting code in English. If you are not native speaker, don't be afraid to use translator. Use online vocabulary, look into synonyms and words similar what you are thinking about using.
  • Context is important for naming. Consider your domain (look into DDD), also consider consistency with the language you use, and with rest of the codebase.
  • Enjoy this! For me, this part of writing code, even though frustrating at some points, is also really real fun, and finding naming that "clicks" is reward on itself.
  • Code changes. Context changes. It's ok to change your code and naming too.
Collapse
 
shricodev profile image
Shrijal Acharya

Couldn't agree more with the last point. 🤝

Collapse
 
sabrine_drira_6c0faceb133 profile image
Sabrine Drira

I love your list !
It is helpful.
Thank you

Collapse
 
adambrandizzi profile image
Adam Brandizzi

The best way to learn to think like a programmer is... to program! The more you code, the more you understand how it works.

Also, work with other developers. It is very easy to become infatuated with your own work: having partners in coding help you extend your horizons a lot!

Collapse
 
masteing_the_code profile image
Joel Jose

Yup. That's the best way.

Collapse
 
miketalbot profile image
Mike Talbot ⭐

@zaparka has already given a great answer, I'll try from a different perspective.

For me, managing complexity is the biggest problem in coding. There are complex libraries to understand and our own code becomes complex or intricate.

The best practice, raw principle for me is to black box, to develop a skill for thinking in detail when constructing something and then retaining its 10,000 and 30,000ft views when working on something else. Our job is primarily to assemble parts to create a solution, we should develop an ability to assess parts and fit them into the solution we are working on, only building new code when one finds that no existing part fits.

My mantra is then: build what you MUST not what you CAN.

Design patterns and algorithms are just the parts or the tools we use to produce solutions, just like everything else. Understanding basic trade-offs (e.g. use more memory, but get higher performance) is often useful, but know that there are rarely right and wrong answers that can be read in a book or a blog post, right answers are heavily context specific!

Collapse
 
martinbaun profile image
Martin Baun • Edited

For me;

  • Break down your project into smaller milestones
  • Build first, scale later
  • Make it work, Refactor later
  • Have loads of coffee

This helped me with my first project at goleko, it hasn't done me wrong, I'm a convert haha :)

oh, yeah, and checklists :)

Collapse
 
prakirth profile image
Prakirth Govardhanam

My way, (which I learnt from CS50) is to write the solution for a problem in Pseudo-code in ascending steps:

  1. Talk the problem to an inanimate object like a Lego (if you don't have a coding buddy)
  2. List the solution down in simple-language
  3. Add some jargon and context into the solution
  4. Code away!

This is what I do. I guess this should cover logic, problem-solving , creativity and out-of-box thinking as well! 🖖

Collapse
 
kurealnum profile image
Oscar

One thing you could try is programming from multiple different "perspectives". For instance, if you mainly work on the backend, try working on the frontend and think about how choices you made on the backend affect you as a frontend developer. All that being said, I'm still in a similar phase of learning to program as you, so my advice may not be as great as others.

Collapse
 
phalkmin profile image
Paulo Henrique

First, KISS (keep it simple, stupid)

Second, start thinking how you would explain what you are trying to do to a non-dev. No fancy words, no jargons, no complicated concepts, just the basics, which can be understood by anyone.

This is your basic code. If you can do it, you can do (almost) anything

Collapse
 
edward_thomas profile image
Edward Thomas

Okay, so if you want to learn to think like a programmer, first thing you understand is the problem you are going to solve or the utility of your code, once you start getting it, you are half way there.
after that you should focus on visualize the procedure of your code that how you gonna build it, you can try flow charts and pseudo code for this, don't just mug up or copy paste the code, understanding the concept behind it, that's where the success of coder lies.

Hope it helps, all the best.

Collapse
 
trainn profile image
Trainn

Interesting

Collapse
 
officialphaqwasi profile image
Isaac Klutse

Data Structures and Algorithms. Involve yourself in things pertaining to programming, like movies, books, meetup, type of friends etc. With time programming will be your by product.

Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more