# Think Like a Programmer  ## Metadata - Author: [[V. Anton Spraul]] - Full Title: Think Like a Programmer - Category: #data-structures-and-algorithms ## Highlights - When solving a problem with a program, you also have constraints. Common constraints include the programming language, platform (does it run on a PC, or an iPhone, or what?), performance (a game program may require graphics to be updated at least 30 times a second, a business application might have a maximum time response to user input), or memory footprint. Sometimes the constraint involves what other code you can reference: Maybe the program can’t include certain open-source code, or maybe the opposite—maybe it can use only open source. ([Location 278](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=278)) - For programmers, then, we can define problem solving as writing an original program that performs a particular set of tasks and meets all stated constraints. ([Location 282](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=282)) - If you are unaware of all possible actions you could take, you may be unable to solve the problem. ([Location 339](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=339)) - Restating the problem in a more formal manner is a great technique for gaining insight into a problem. ([Location 365](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=365)) - It’s better to develop a strategy than to attack the problem through trial and error. ([Location 438](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=438)) - When faced with an onerous problem, I experiment with a reduced version of the problem. ([Location 440](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=440)) - Looking for a way to divide a problem is usually time well spent. Even if you are unable to find a clean division, you may learn something about the problem that helps you to solve it. ([Location 443](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=443)) - The main lesson from sudoku is that we should look for the most constrained part of the problem. While constraints are often what make a problem difficult to begin with (remember the fox, the goose, and the corn), they may also simplify our thinking about the solution because they eliminate choices. ([Location 470](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=470)) - You must always have a plan, rather than engaging in directionless activity. ([Location 540](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=540)) - General Dwight D. Eisenhower was famous for saying, “I have always found that plans are useless, but planning is indispensable.” ([Location 545](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=545)) - Planning also allows you to set intermediate goals and achieve them. Without a plan, you have only one goal: solve the whole problem. ([Location 557](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=557)) - restating a problem can produce valuable results. In some cases, a problem that looks very difficult may seem easy when stated in a different way or using different terms. ([Location 564](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=564)) - Finding a way to divide a problem into steps or phases can make the problem much easier. ([Location 580](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=580)) - In the same way, dividing a problem can often lower the difficulty by an order of magnitude. Combining programming techniques is much trickier than using techniques alone. For example, a section of code that employs a series of if statements inside a while loop that is itself inside a for loop will be more difficult to write—and to read—than a section of code that employs all those same control statements sequentially. ([Location 593](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=593)) - when programming, you should try to start with what you already know how to do and work outward from there. ([Location 604](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=604)) - With this technique, when faced with a problem you are unable to solve, you reduce the scope of the problem, by either adding or removing constraints, to produce a problem that you do know how to solve. ([Location 617](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=617)) - An analogy, for our purposes, is a similarity between a current problem and a problem already solved that can be exploited to help solve the current problem. ([Location 642](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=642)) - Sometimes the best way to make progress is to try things and observe the results. Note that experimentation is not the same as guessing. When you guess, you type some code and hope that it works, having no strong belief that it will. An experiment is a controlled process. You hypothesize what will happen when certain code is executed, try it out, and see whether your hypothesis is correct. ([Location 658](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=658)) - Don’t get frustrated. When you are frustrated, you won’t think as clearly, you won’t work as efficiently, and everything will take longer and seem harder. Even worse, frustration tends to feed on itself, so that what begins as mild irritation ends as outright anger. ([Location 673](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=673)) - First of all, never forget the first rule, that you should always have a plan, and that while writing code that solves the original problem is the goal of that plan, it is not the only step of that plan. ([Location 688](https://readwise.io/to_kindle?action=open&asin=B008RQMDU4&location=688))