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?

Comments

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

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

[Jan Peterka]

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.

[Shrijal Acharya]

Couldn't agree more with the last point. 🤝

[Sabrine Drira]

I love your list !
It is helpful.
Thank you

[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!

[Joel Jose]

Yup. That's the best way.

[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!

[Martin Baun]

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

[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! 🖖

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

[Alex]

Learning to problem solve in a larger scale is a huge contributor. You can adopt the same (or very similar) process to solve problems in other areas of life!

[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

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

[Trainn]

Interesting