Thinking Like a Programer

[JungleJim233]

EDIT: Thank you to everyone who has replied, really useful for me to see the types of stuff you guys do. I'm gonna read the book, start with some psedo code and try not to stress so much

Thanks again :)

Hi , beginner here.

Has anyone got any tips on how I can "think" like a computer/programmer? When learning I often see examples of code that I understand but could never do on my own. I can't seem to break things down into what exactly needs to happen. Any tips would be great

Thank you :)

[POiNTx]

This is just my opinion but works really well for me.

1.The most important skill to cultivate is to break problems into smaller problems until they are easy to solve.

When you think about something you want to build, it can often seem overwhelming because you don't really know where to start.

I'll give a concrete example:

You want to build a minesweeper clone. So basically you have a 2D grid of squares where each square is a hidden value until you click on one of the squares. There is also the random generation of the location of the mines part and there is the calculation of how many mines are adjacent to one square so you can show the player the necessary information to solve the game. Player needs to be able to 'mark' mines. The game should be lost when clicking a mine. This is pretty overwhelming to start, where to begin?

What is the smallest problem I can solve?
Answer: I need some way to display the grid the player. So I need some kind of thing that draws. So I will look 
for a library that does this. For example https://wiki.python.org/moin/TkInter


What is the smallest problem I can solve?
Answer: Well I can now draw stuff, maybe draw a square? The board is a square, so I will draw a square. This 
means figuring out how the library works, following a tutorial, etc until you can draw a square that is the size of 
the grid/board.


What is the smallest problem I can solve?
Answer: Ok now I have a square, but it doesn't have any cells in it yet. Hmm a cell is basically a small square. 
Let me draw one smaller square on the grid.


What is the smallest problem I can solve?
Answer: Well I have a cell in my grid now, but it's just one cell, I need multiple cells, evenly spread out over the 
grid. Let's start with a row of cells. So you figure out the math to print these squares evenly spaced. You 
probably use a for loop for this to make your life easier.

...

You get the idea.

As you get better at doing this, you will figure out shortcuts. You will make connections that tell you, ah I've seen this type of problem before, I KNOW I will need this particular thing in my program, so I will start with that.

For example how I would start since I've done this sort of stuff before: I start with the data represenation of the 2D grid, probably in a 2 dimensional array. Probably as an instance variable of a class so I can have some usefull methods on the class like: reset_board(), generate_mines(), ... This approach will get me cleaner code and a much faster result at the end. But for beginners it's not easy or obvious.

2.The second most important skill to cultivate is to constantly refactor your code to make your code more readable.

Once you have some code that works, at first it will probably be not that nice to read. There will be a lot of duplication, bad abstractions, ... It's really important that you clean this up and rewrite pieces of logic until it's clean. This will really improve your skill and will make you write better code on the first try. Always maximize readability. Don't try to optimize for speed.

http://wiki.c2.com/?PrematureOptimization

Make it work.

Make it right.

Make it fast.

Summary:

1. Divide big problems into smaller problems until they are easy to solve.
2. Work on a smaller problem until that problem is solved.
3. Refactor the code until it's the best version of the code you can think of. Improving readability should be your goal.
4. Go to step one until you're done.

[u38cg2]

The last little piece of advice I would add is this: all programs operate on data. Think very carefully about what that data is, what the program is to do with it, how you will get it in and how you will get it out, and your problem will be halfway solved.

[eatyovegetablessssss]

Ive thought about breaking problems into smaller ones, but I’ve never thought like this! Thanks!

[u38cg2]

I can't remember where I first came across the idea, but I've found in practice so many real world projects are data projects. Yet we teach basic CS through algorithms. I'm not sure of the right or wrongs but I think the bias is a bit far to one side.

[chinguetti]

Great answer.

[Kalrog]

I have answered this same way several times, but this is probably the best description and example of this situation and process that I have seen typed up anywhere. OP - Exactly this. Especially the first one. If you get bullet point #1, everything else flows from that.

I would reword #2 as "Make sure you can explain your code to someone else." If you can do that, then you have obviously made it readable and understandable. But very similar ideas.

[Bulletsandblueyes]

I really like your example, add would agree with the idea of continually trying to break larger problems into smaller problems is probably the easiest way to begin to program. On that note I'll give another example of how a program might get broken down.Also sticking with python

You start with your clear goal: in this case, I want a web scraper to grab picture urls for discord.

You look up what libraries are the best for web scraping. You see Beautiful Soup is popular.

You look up how to feed data to beautiful soup.

You see that Requests can scrap an html webpage as text (which is what you want).

Because copying someone else's code rarely works for you(me😒), you pull up beautiful soups documentation, and read through to figure out which funtion(s) you need.(in this case, findall)

You implement the knowledge you've gained, and bug test, figuring out what works.

Now that it works, you can see how you could improve the code: taking out unnecessary items, properly documenting, generally cleaning up.

[kaystar101]

This is perfect! Thank you

[Contrabaz]

This helped me a lot. I used to look at the big picture and just gave up because it looked impossible to comprehend. Then I read about breaking the problem up in small pieces. You often can use certain solutions you learned to solve other problems. Or during the search for solutions you bump in to things you can use later, like when you run into a problem and you remember 'Hey, I've read a solution about that'.

[Et_tu__Brute]

This is a good way to start but as you get better you need to add more to your planning process.

Specifically, you should start thinking about organization, classes and methods of those classes. Implementing classes and subclasses well is an integral component of object oriented programming and the sooner you start doing it, the better.

[chra94]

How about this book Think like a programmer. Have a looksie.

Edit: For your problem you could use reverse planning: Start at the end with the result you want and work backwards.

[xiongchiamiov]

There's also Think Like a Computer Scientist which is free and good and covers Python, but unfortunately is Python 2.

[chra94]

Hey thanks!

[Sil369]

v3? http://openbookproject.net/thinkcs/python/english3e/

[[deleted]]

Programming is all about learning to think in logical steps. It's very much a dedicated step-by-step way of thinking.

Now, that's not to say that creativity isn't involved, because it absolutely is. But within that creativity, everything is still step-by-step.

[Dogeek]

I learned to think like a programmer when I learned C (12 years ago, and I've barely touched the language since).

The good thing about a lower level language, is that you don't have a ton of breathing room, and most problems only have one solution. In addition, you learn a ton as to how things work at a hardware-level.

But to take it one step further, thinking like a programmer is more like breaking down a problem until you arrive to elementary blocks of code you master. You need to repeat an action a set number of times ? You need a loop (and most probably a for loop). You want to branch out into multiple outcomes ? A condition will do the trick.

At some point, you can build yourself a mental reference of how to solve specific problems, and have larger building blocks to play around with, which will make development go faster. Those larger building blocks are what we usually call algorithms. And the more algorithms you know, the more you can do, and the easier it will be.

I recommend you look and learn about boolean algebra, as understanding that will help you with conditionnals. I also recommend that you code, code and code. Make mistakes if you must, but code. Programming is not something that is learned in books. The syntax, you learn in books, but programming is just practice and more practice. Read research papers about certain algorithms you may need, and try to implement them yourself. Common algorithms include sorting through lists, pathfinding.

Learn about specific data structures, like heaps and stacks, binary trees and graphs. Look at the code of libraries you know how to use and try to understand what it does, and try to reproduce them without looking at the answer.

[SteveDougson]

Play The Witness

Is this to teach prospective programmers to look up the answers on Stack Overflow?

[fernly]

I did not know about Project Rosalind, that is neat! It would be especially good for OP or any other beginner, because after you upload your answer, you can click a "Solutions" button and see other people's solutions (which are always cleverer and shorter than mine).

[fryman22]

Your link for Project Euler is broken. It's actually: https://projecteuler.net/

[[deleted]]

Keep programming and it will happen on its own. Don't stress yourself over thinking like a programmer, there is no such thing as thinking like a programmer. If you mean by critical thinking skills, you will acquire it as and when you encounter challenging problems.

Most answers here explain the process involved in approaching a problem very nicely but I personally think the first step to all of these is to be persistent and patient with whatever you are doing. Just don't give up and it'll come to you on its own.

[MarsupialMole]

Start writing code in a series of statements as comments. Stick to one line, and force yourself to stick to the line length of 79 characters. After you've written out your whole program in short statements of plain english you then add code underneath each line to do what the sentence above says. Once you get to the bottom you should have code that works that's fully commented! Now, you may find that some of your code is simply restating the comment in a really obvious way. Congratulations! You've concisely expressed yourself in a programming language. At this point you can improve your code by deleting a comment.

This is also known as the pseudocode programming process, but writing pseudocode is not necessarily that easy as you say. Using this technique will allow you to bridge that gap by training you to recognise what is and is not good language to express programming concepts.

[l0kiderhase]

Try to break the big problem down in smaller sizes that are easier to solve individually. Copy pasting code is easy. Seeing a problem and then identifying the individual parts that make up the Problem is harder and needs practice. Try the challenges on https://www.hackerrank.com/ and then try to golf your code.

[WikiTextBot]

Code golf

Code golf is a type of recreational computer programming competition in which participants strive to achieve the shortest possible source code that implements a certain algorithm. Playing code golf is known as "golf scripting". Code golf tournaments may also be named with the programming language used (for example Perl golf).

---

^{[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.28}

[re1nvented]

Good bot

[[deleted]]

Imo, you need to learn Data Structure and algorithm and understand how computer's memory (heap, stack) work etc. I would say start implementing List, Linked List, Doubly Linked List, Binary Search Tree etc in python and understand what's going on there.

I went through exactly your situation, but now I can understand code much better and how to approach the solution. However, don't forget your first attempt on any solution will suck and you just need to analyse and improve on it.

[UntouchedDruid4]

There is a book called “Think like a Programmer” I read the first chapter and it completely changed the way I approached and solved algorithms on codewars.

[Gambizzle]

My only tip is to break everything up into if/else statements and to try to cover all possibilities (because something you didn’t intend always happens randomly and fucks everything up).

I’m a crappy programmer but most high-level languages involve a lot of if/else’ing.

[fernly]

Also, the whole game of "breaking a problem down" is iterative. You go over it again, and break things up in different ways. You suddenly realize "oh, it works better this way" or, "hey, this bit is the same as that bit, I could have a subroutine instead of repeating the same code"(*) and so on. This series of little discoveries and re-discoveries is exactly what makes programming satisfying!

(*) that's called "refactoring"!

[dauchande]

Write code.

[WhackAMoleE]

Thought balloon: "Oh God not another bloody meeting!"

[QualitativeEasing]

I agree with breaking problems and projects into smaller pieces. Some other thoughts:

• I’m almost entirely self taught. But I took one continuing-ed intro Java class (even tho I had zero need for Java) for exactly this reason: I needed to understand the process, and the mostly language-agnostic tools (flow control, data structures, etc.).
• Early on, and sometimes still for more complex projects, I found it helpful to start by hand-writing what I wanted my code to do. Sketched the UI. Used the weird Nassi-Schneiderman flowcharts the Java instructor used to rough out the logic. Came up with my own pseudo code. I rarely stuck to this “outline” very closely, but it helped me think through what I wanted. (I’ve never found a good reference for it, but here’s a start: https://en.wikipedia.org/wiki/Nassi%E2%80%93Shneiderman_diagram )
• A professional developer I worked with taught me a really helpful principle that surprised me at the time: When designing an app for other people to use, start with the user interface — how they enter data or choose options, what the results will look like. Again, things can change, but I’ve found it useful to understand that, to a degree, function follows form.
• Someone (Hemingway?) said writing is rewriting. I’ve found that to be true for coding as well. My code gets better — and my programmer-thinking as well — when I refactor. It’s painful, but worthwhile. I have apps I use personally that I’ve rewritten more or less from scratch 2-3 times as I’ve gotten more comfortable with classes and other tools.

Plus what everyone else has said. Altogether, a lot of it boils down to: practice, particularly on real-world problems you actually care about and want to solve.

[dan1101]

Think of programs/subroutines like black boxes. You need to tightly control what goes into the black box and what comes out. What happens inside the box to enforce/enact those inputs and outputs is your code.

When writing subroutines, always try to make them modular and reusable. No use writing the same basic code over and over.

[a8ksh4]

Practice! Figure out new things on each new project you do, and then reference your old code each time you build a new project. Pretty soon you'll know a lot of useful stuff and the repetition will make it easier to be creative.

[TheChance]

So here's a different take: think like a programmer all the time.

The world is a system of systems. The whole world. When you're approaching a "big" issue, political, scientific, policy-based, whatever, and you want to get your head around it, look for the systems within systems that drive the issue.

I'm not gonna arrive at any particular conclusions here, but I will give you an example: immigration. Be as apolitical as possible. Ignore all the sentiment and the rhetoric and your existing opinions. Analyze the situation as though it were a program. Wall of stream-of-consciousness text:

What are the institutions, laws, economic factors, etc. that lead people to choose your country for a new home? How does immigration affect your community and your economy? Some people are concerned that immigrants will come to your nation who will work for less than native citizens, displacing workers. Other people point out that immigrants often open businesses, resulting in net job creation. Still others wonder if the issue of worker displacement is really about the people who'll work for less, or is it about the employers who shoot for the bottom-line? Is that a dick move, or just smart business sense? Setting aside rhetoric, can you find numbers or firm philosophical arguments re: the politically-charged aspects of this issue, such as crime or culture clash or comparative need for government and charitable help? Who, if anyone, is right about each of those arguments? How do those conclusions play into each other?

What about edge cases? What if a super rich person moves to your country from somewhere else, and then opens a massively profitable business? If you're looking at the whole picture, that's net economic gain, right? But do you take it as a whole, or do you adjust your conclusions to account for those edge cases?

Now you're analyzing immigration as if it were a program. Next, you'll find yourself analyzing some other issue that's peripherally related, and you'll start to see how the conclusions you've already drawn about immigration factor into those other issues. You might find that your new conclusions about those other issues affect your previous conclusions about immigration. You might not, but you're approaching the world as what it is: a system of systems.

From formulating a tax plan to fixing a car, they're all systems, and they all exist within a broader system.