ProblemSolving Checklist
John Denker
* Contents
1 Prerequisites, Prior to ProblemSolving
Consider the following parable:
Once upon a time there were two farmers, Simplicio and Salvatio. They
were very similarly situated. They operated neighboring tomato farms.
Their fields were nearly the same size.
On harvest day, Simplicio said “I’m going to work really hard
today. I’m going to work so hard that I harvest twice as many
tomatoes as the other guy. I planted twice as many plants, so there
should be no problem. I’m going to turn a huge profit.”
However, there is one slight problem. Because the plants were too
close together, they weakened each other. Then the worms came along
and finished them off. As a result, there are hardly any tomatoes in
Simplicio’s field. It doesn’t matter how hard he works on harvest
day; he can’t harvest tomatoes that aren’t there.

Problemsolving day is like harvest day. You get to harvest and
profit from facts and ideas that are in your brain. The process is
subject to a crucial constraint: You cannot harvest stuff that isn’t
there. If you didn’t put ideas into your head in the proper way, you
won’t be able to get them out when needed, no matter how hard you work
at it.
Let’s be clear: In large measure, your success at problemsolving
depends on what you did during previous days, months, and years. You
have to learn stuff over time. There are right ways and wrong ways to
do this; see e.g. item 1.
When reading this document – or any other writeup on problemsolving
– please be aware of its limitations. There is nothing wrong with
what is said here; the problem is what is not said. There is some
value in problemsolving techniques per se, but you must look
elsewhere to find the other 95% of what you need for effective
learning, thinking, and problemsolving.
Here’s another limitation: A checklist such as this one (or
reference 1) can be useful as a reminder of things you
already mostly know. However, it’s hard to learn new ideas from a
checklist. It’s too condensed. In some cases, an individual item on
this list (e.g. item 46) would become a book chapter
or an entire book if spelled out. If you want to learn, it helps to
have more detail. It helps to see the ideas applied to examples.
There are quite a few good examples in reference 2. An
additional nice example is discussed in reference 3.
2 General Suggestions

Whenever you encounter a new idea, mull it over. Think
about all the ways in which it is connected to – or inconsistent
with – things you already know.
This applies all day every day, whether you are trying to solve a
particular problem or not. It applies to every new idea you
encounter, whether it comes from something you read, or an experiment
you did, or a calculation you did, or whatever. This is discussed in
some detail in reference 4.
The connections are necessary if the idea is to be useful,
because they are what allow you to recall the idea when needed. To
say the same thing the other way, if you put an idea into your brain
but have no way of recalling it when needed, it might as well not be
there. An idea that can be recalled in many ways is vastly more
useful than one that can only be recalled in one way.

As a related point: Even when you’re not working on
a specific problem, look for patterns in the world around you. This
might lead you to formulate a good question or a hypothesis that
needs testing. Conversely, always be on the lookout for anomalies,
for deviations from the expected pattern.
This is important for two reasons:
 On a daytoday basis, it is a
crucial part of the learning process mentioned in item 1 and
discussed in reference 4.
 On more rare but more important occasions, it contributes to
scientific creativity, perhaps to the discovery of something new and
important.

Don’t panic.

Check the work.
In more detail:

Show the work.
 Check the work.
 Show the checks.
Following this advice may slightly increase the workload in the short
run, but it greatly reduces the workload in the long run, especially
when dealing with complex problems. For details on this, see
reference 5.
Checking the work at each step along the way greatly increases the
odds of getting the right answer. In a complex calculation, there
will be mistakes, and showing the work makes it easier to find and fix
the mistakes. Showing the work and showing the checks makes it easier
to check and recheck the work. It is particularly valuable in a
teamwork situation, because it helps other people check the work and
learn from the work. For more on this, see section 4 and
item 15.

Don’t believe everything you read. This can be
considered a corollary of item 1. It can also be considered a
corollary of item 4, insofar as you are checking the
other guy’s work.

Document the code. This is a corollary of
item 4. It shows how the code was designed, which
greatly facilitates checking. This is discussed in reference 6.

Write out a glossary, spelling out what your notation
means, and what your terminology means. Do not rely on the name of
an idea encode the full meaning the idea. We routinely give short
names to complex things; that’s what names are for. For more on
this, see reference 6.
This is particularly important when you are working as part of a
problemsolving team. You are free to make up whatever notation and
terminology you like, but don’t expect other people to guess what it
means.

Draw the diagram.
 If it’s an electronics problem, draw the circuit diagram.
 If it’s a relativity problem, draw the spacetime diagram.
 If it’s an electrostatics problem, sketch the field lines
and/or the equipotential contours.
 If it’s a statistics problem, make scatter plots and
diaspograms of the data.
 If it’s a scheduling problem, draw the PERT diagram.
 et cetera
There exist thousands of different types of diagrams; reference 7 lists more than 100 examples. If you cannot find a
preexisting way of representing the data, invent something. If this
is not easy, do it anyway. Remember the sardonic proverb:
When all else fails,
look at the data.





When given an assignment, make sure you
understand the statement of the problem, so you don’t go off and
solve the wrong problem. See also item 10.

When given an assignment, check to see how illposed
it is.
 Sometimes realworld problems start out underdetermined. In
such a case:
 You might need to find the entire solution set.
 You might need to turn it into an optimization problem,
i.e. to find the optimal element of the solution set. If the
statement of the assignment didn’t specify the optimization
objective, you may need to ask questions to figure that out.
 You might need to track down some additional information,
to make the problem fullydetermined or (better) overdetermined.
 Realworld problems are very often overdetermined in a good way.
That allows you to solve the problem more than one way and check for
consistency. If it isn’t overdetermined, see if you can make it
overdetermined, to facilitate checking, as discussed in section 4.
 Sometimes the assignment is overdetermined in a bad way,
i.e. not consistent with itself, or not consistent with the laws of
nature. In that case it may be necessary to turn it an optimization
problem, to see how close you can come to satisfying all the
stated objectives. Again, if the statement of the assignment didn’t
specify the optimization objective, you may need to ask questions to
figure that out.
 Sometimes you get an assignment with just barely enough
information to permit a solution. That is typical of textbook
problems, but very atypical in the real world. It should make you
suspicious that there’s something you’re not being told.
 Sometimes the assignment is not illposed in the technical
sense, but merely illconceived. Negotiate with the person who
posed the question, so that you can figure out what question
should have been asked ... and answer that instead.
Procedures for dealing with illposed problems are discussed in
reference 8.

Formalism can be very powerful, and sometimes it
delivers a valid result whether you understand it or not.
 A lot of people know how to count reliably, but couldn’t give
a formal, rigorous definition of “integer”.
 A lot of people know how to perform long division reliably,
but couldn’t really explain how it works.
 A lot of people know how to play the piano proficiently, but
don’t fully understand how a piano works inside. They couldn’t
repair one, much less build one from scratch.
 Much of quantum mechanics is in this category. Our ability to
calculate superaccurate results using the quantum mechanical
formalism far outstrips our ability to visualize and understand
what’s going on. Richard Feynman said he didn’t really understand
quantum mechanics ... even though he probably understood it better
than anyone else in the world at the time.
You are absolutely not required to fully understand every element of
what’s going on before starting the analysis and calculations. It is
common to understand a problem well enough to solve it, and then
achieve a much deeper understanding by pondering the solution. See
also the discussion of formalism in section 5.

Sometimes experiment delivers a valid result,
whether you understand it or not. It is fairly common to obtain a
experimental result and not fully understand it until later.
There are layers upon layers of understanding. There is such a thing
as serendipity.

When Penzias and Wilson observed excess noise in their antenna
system, that was a valid experimental result. They did not
understand its origin – or its cosmic significance – until later.
^{1}

During the process of solving the
problem, build up an understanding of what’s going on (as far as
possible). That is to say, don’t blindly follow the formalism (any
more than necessary).
Analysis helps with the understanding ... just as understanding helps
with the analysis. You can leverage one against the other, again and
again, recursively and iteratively, like the itsybitsy
spider.
Even though it is sometimes possible (as mentioned in item 11 and item 12) to obtain a
formallycorrect result without understanding it, this should be
considered only a first step. It is not something to be proud of.
Don’t walk away from the result until you have made a serious effort
to understand it. See also item 14 and item 17.

If a complicated derivation produces a simple result,
go back and look for a simpler derivation. This is part of the
process of understanding, as mentioned in item 13.

After you have found one solution, see if you can
find another solution to the same problem. Try to make the solutions
independent, to the extent possible. If they have some steps in
common, that’s not tragic, but try to minimize the overlap.
Example: There are two remarkably dissimilar solutions to the
Mississippi Flow problem (reference 4).
Example: There are two remarkably dissimilar solutions for finding the
Johnson noise in a parallel combination of resistors (reference 9).
Obviously this overlaps quite a bit with the suggestion to Check The
Work (item 4) but it is worth mentioning, because it is a
specific way of checking the work. The obvious approach is to
carry out the same calculation a second time, checking and rechecking
each step along the way.
The nonobvious approach is to carry out a completely different
calculation that produces the same result. This has the tremendous
advantage that it can catch conceptual errors, not just arithmetic
errors. (The downside is that if there is an error, this will not
tell you exactly where to find it.)
Simple example: Check by doing the inverse problem. Given the task
10 − 7 = ____, the answer plus 7 had better equal 10.
Intermediate example: If you use trig functions to find the sides of a
triangle, the answer had better uphold the Pythagorean theorem and
other trig identities. Similarly, any physics answer had better
uphold the various conservation laws.
Fancy example: Given the task of estimating (closed book) how much
Mississippi River water flows past New Orleans in a year, there are at
least two completely different ways of approaching the problem,
leading to completely independent estimates.
For students who have never seen the problem before,
finding one solution is hard ... and finding two
independent solutions is even harder, much worse
than twice as hard.

If you don’t immediately see how to get started on the
assigned problem, it may help to do some warmup exercises. That is,
attack a similar but simpler problem.
 Try doing some numerical examples, i.e. instances drawn from the
more general class. This may involve a simple spreadsheet or a fancy
numerical simulation.
 Conversely, if given a problem with numerical values, try
working out the general case. It’s amazing how often the general
case is easier to handle than ten special cases ... or even one
special case.
Here’s an example that recently came across my desk:
Suppose you have to multiply (20.14 + 20.04) × (20.14 −
20.04). You could grind it out, and obtain 4.018. On the other
hand, if theory tells you that 20.14 is really 2cosh(ρ) and
20.04 is really 2sinh(ρ) where ρ=3, then you know the
answer has to be 4, exactly, independent of ρ. So that’s a
solution to the current problem and innumerable others, because it
works for all ρ.Furthermore, you get to go looking for a good physics reason why the
answer had to be independent of ρ, which makes you smarter in
the long run.
 Try doing an analogous problem. Try introducing approximations.
What do we mean by analogous? That could be almost anything you
know that has some features in common with the current problem.
Here are some hints on places where you might look for analogies
and/or approximations you can introduce:
 If you have a problem involving distance in three
dimensions, see if there is an analogous problem in two
dimensions or one dimension. For that matter, see if there is an
analogous problem in zero dimensions (involving no distance at
all, just counting). Sometimes such analogous problems can be
found, and sometimes not.
 Try a version of the problem with more symmetry and less
detail, such as the proverbial spherical cow.
 More generally, you might try approximating things by some
sort of series, perhaps by expanding everything to lowest order.
You can get better and better approximations by including more and
more terms in the series.
There are lots of ways of doing this: Taylor series, Fourier
series, et cetera. For example, the sphere mentioned in the
previous item is the lowestorder term in an expansion based on
spherical harmonics.
 If the problem involves a random distribution, consider
approximating it by a uniform distribution. You can always go back
later and put in the fluctuations as a correction term.
Sometimes your first approxmation turns out to be good enough. If
not, maybe you can redo the analysis using slightly better
approximations. Sometimes the approximation is off by a factor of
infinity and cannot be repaired, but presumably you learned something
from the process of doing the analysis. Remember the spirit here try
something and see if it works. If not, try something else.
The difference between an approximation and an analogy is that you
don’t even pretend that the analogy is the right answer. After
doing the analogous problem, you set it aside and start attacking
the original problem, using what you learned from the analogy as a
roadmap.
 After doing the warmup exercise, sometimes you have to set it
aside and start working on the main problem from the beginning
... but sometimes not. Sometimes you can convert a simple, crude
model into a fancier, nuanced model by a process of successive
refinement. This is discussed in reference 10.

After you have solved the assigned problem, see if
you can generalize it. This is an important part of building up an
understanding, as discussed in item 13.
 On the input side: Try to obtain the same result
with lessstrict assumptions.
 On the output side: Given a result, explore is ramifications,
implications, and applications. Check whether it is consistent (or
inconsistent!) with other things you know. This may or may not help
you with today’s problem, but it will certainly help you with other
problems down the road. It will make you smarter in the long run.

Given a word problem, find a way to formalize it.
This often involves choosing a set of variables, and then writing some
equations that express relationships between the variables. This in
turn may involve choosing a suitable frame of reference, system of
coordinates, vector basis, et cetera.

Don’t hesitate to break one hard problem into a
great many easy problems. You don’t need to be Superman. That is to
say, you don’t need to be able to leap tall buildings at a single
bound if you can walk up the stairs. There are a lot of steps, but
each one is easy. See also section 3.
For example, balancing a complicated chemical reaction equation would
be wellnigh impossible if you didn’t have a systematic way of doing
it. Gaussian elimination might require 20 steps or even 100 steps,
but each step is cutanddried and incredibly easy, so you just grind
it out. Or tell the computer to do it. Problem solved.

Attack the problem from all angles. If necessary,
chip away at the corners. Try something and see if it works.
If not, try something else. Use your intuition to help decide what
is a plausible line of attack. See also section 3.
Feynman compared knowledge to a grand tapestry. Something you don’t
know is like a hole in the tapestry. You can fix it by weaving
upward from the bottom, downward from the top, and/or inward from the
sides. Sometimes it pays to start in the middle of nowhere and
construct something from scratch, and then patch it into the main
tapestry later.

Beware that a great many people who ought to
know better emphasize the straightbackwards attack, i.e. starting
with the conclusion and working backwards. This is no worse than
many of the other possible lines of attack, but it is no better, and
there are thousands of possibilities.
The straightbackward approach works particularly well for some of
the multipleguess tests that plague our classrooms today, but does
not work nearly so well in the real world.

As emphasized by Pólya (reference 2),
pay special attention to the hardest subcase you can solve, and the
easiest subcase that you cannot (yet) solve.

Paper is cheap. Don’t try to cram calculations
into a corner of the page; start a new page. Don’t skip steps in an
attempt to save paper. See reference 11.

When you use one equation to derive
another, you should not do it by revising the initial equation in
place. Instead, leave the original equation alone, and write the
derived equation on a new line. This is important for making the work
checkable. See reference 11.

Generally, you should avoid erasing anything in your
working notes. If it’s wrong, draw a tidy diagonal line through it,
rewrite it correctly if necessary, and proceed from there. Ditto for
seeminglyworthless dead ends. Anybody who is reading your work
knows what a mistake is and what a dead end is, and won’t be confused
or surprised to find such things in your work. Contrast item 26.
For additional details, see reference 11.
Rationale: In the best case, erasing isn’t the trouble. In the worst
case, you run the risk of erasing something valuable.

If you are keeping your notes on a computer, use a version
control system. This allows you to “tidy up” the current version
as much as you like. Meanwhile, previous versions can be retrieved
at the touch of a button.

Keep track of the difference between the main goal
(solving the maze) and the various subgoals (reconnoitering some
branch of the maze). Often making progress toward the main goal
requires giving up on a subgoal (i.e. backing out of a dead end).
See reference 4.
3 Piece by Piece, not Step by Step
The “scientific method” is not nearly as methodical as
nonscientists seem to think it is.
Thinking of it as a stepbystep process suggests stepping along a
road, moving steadily forward along a onedimensional path. That’s
not how problemsolving actually works. That may be a good way to
explain the solution once it is found, but that’s not a good way
to find it.
The reality is more like searching a maze (rather than following a
clear onedimensional path). It goes something like this:
Start with an intuitive idea. Draw a qualitative
diagram. That provides motivation to write some equations, which can
be turned into software code, which produces a vastly more accurate
quantitative diagram. Looking at this diagram indicates that the
original intuitive idea is not entirely satisfactory. Checking the
limiting cases shows that the idea works in certain limits, but not in
the general case. This suggests a more elaborate idea. That
motivates writing some new equations and some new code. That produces
a new diagram. Checking the limiting cases and the symmetries
suggests that the “elaborate” model can be made much more
streamlined and more intuitive. That motivates yet more equations.
Alas the equations show that the streamlined model is not actually
correct. So we have to back up and come up with yet another model. A
new concept is brought to bear. It is sophisticated but not
complicated. This motivates an entirely new approach, including new
equations, new code, and new diagrams. The result is elegant and
provably correct. It is intuitive in retrospect. There is an
algebraic proof and a nonalgebraic geometric proof, which can be
checked against each other. An analysis of the symmetries, limiting
cases, and analogies makes it even more plausible and intuitive.
One lesson to take from this story is that a checklist is not a
dolist. You should check each of the items enumerated in section 2, but you don’t necessarily need to do them all. You
certainly don’t need to do them in any particular order. Some of them
will get done multiple times at various stages of the game.
Very commonly you chip away at one corner of the problem and go as far
as you can until you get stuck. Then you set that aside and start
chipping away at another corner.
Very commonly a seeminglypromising line of attack turns out to be a
dead end, and a big chunk of preliminary work has to be abandoned.
Abandoning something is painful and difficult for psychological
reasons, but it has to be done.
Consider the following styles:
 The way ideas are presented in textbooks and in the scientific
literature. This is very polished, logical, systematic,
sophisticated, and elegant.
 The way problems are actually solved.
 The way problemsolving skills are actually learned.
For most of the last 2300 years, there has been a tendency to pretend
these are all the same thing ... when in fact they are not. Not even
close.
I like elegance and polish as much as the next guy, but not when
it requires pulling rabbits out of hats in such a way that the
students cannot understand the process.
There will always be enormous temptation to polish things, for some
good reasons and some notsogood reasons.
 One semijustifiable reason is efficiency: Real problem solving
involves a lot of backtracking out of dead ends. It is more
efficient if you can skip the dead ends, with the help of 20/20
hindsight.
The polished method works fine if you are using the
solution for the third or fourth time.


The polished method isn’t at
all representative of the process of discovering the solution
for the first time.

If all you want is a solution, the elegantly polished
solution is fine.


If you want to learn how to solve problems, you
need to see the problemsolving process, which is rarely (if ever)
elegant.

When teaching, or when writing a textbook, you have to decide whether
you are training solutionusers or educating solutiondiscoverers. It
isn’t practical to show the gory details every time, but I suggest
showing them at least occasionally.
 Another factor is that people always like to pretend they are
smarter than they really are. The temptation is to say “here is my
elegant solution to the problem” without mentioning that the elegant
solution was found only after 13 lesselegant solutions. The smartest
person in the world might have been able to find the elegant solution
the first time, but most of us aren’t that smart.
There’s even a name for this: hindsight bias. That means you
are much more likely to see how somebody thinks they should have
solved the problem, not how they really solved the problem.
4 Checking
Let’s follow up on the idea of checking the work, as mentioned in
item 4.
4.1 In General

Design the work from the outset to be
readily checkable.

As a means to this end, leave breadcrumbs (or
whatever) to mark your path. Very often, the solution requires a
large number of steps. Document things in enough detail that each
step can be checked locally, independently of the others. This
makes checking vastly more efficient and vastly more reliable,
compared to a situation where the only way to check the solution is
to redo the whole thing from scratch.
Solving a hard problem often includes a process that is equivalent
to searching a maze. Mathematically this corresponds to enumerating
the corners of a highdimensional hypercube. In computer science,
it is called walking the tree. In any case, when you return to a
given node, it is important to know what’s been tried before;
otherwise you risk gross inefficiency, up to and including infinte
loops. Therefore you need to leave bread crumbs to mark the path.
This is superextra important in conjunction with item 32.
An example of a relatively simple problem that rewards systematic
treewalking is Cheryl’s Birthday. A more elaborate example is Who
Owns the Fish (reference 12).
Figure 1: Logic Puzzle : Cheryl’s Birthday

If you solved the problem in a flash of divine
inspiration, go back and figure out a way it could have been solved
methodically, step by step. This is necessary so that mere mortals
can check your work. Also, you may discover that the inspired
solution is only part of a larger solutionset.
Also: Inspiration is a way of obtaining an answer very quickly ...
but beware that all too often, it is a way of obtaining a
wrong answer very quickly.

Have somebody else check your work.

If you can’t find any individual with exactly the
right skills to check the work, put together a team of
specialists, each of whom can handle some part of the job.

Check earlier rather than later.
Publish in haste;
repent at leisure.





If there are more than one or two items, use a
checklist to make sure that every part of the job gets done.
4.2 Checking a Number

Check the order of magnitude. If the height
of the tree comes out to be 10 km, you’ve done something wrong.

Check the dimensions. For details, see
reference 13. Also compare item 46.

There are other things that are technically
not dimensions, but can be checked in the same manner. An example
is vector character. If the answer is supposed to be a vector, and
you’ve got a scalar, you’ve done something wrong.

Apply numbertheoretic checks, such as casting out nines.
4.3 Checking a Formula

Check a few typical cases numerically. Apply
the checks discussed in section 4.2, such as magnitude,
dimensions, et cetera.

Check a few boundary cases (up against one constraint)

Check a few edge cases (up against two
constraints simultaneously)

Check a few corner cases (up against multiple
constraints simultaneously)

Check a few symmetrical cases: Maybe
the triangle is isosceles. Maybe the elliptical orbit is circular.

Check a few simple and/or familiar
special cases: Maybe the triangle is a 306090 right triangle.

Check the results against the various
relevant symmetries, conservation laws, sum rules, et cetera.

Check the scaling behavior. This is a more
general and more powerful extension of item 36.
For details, see reference 14.

Check that your answer depends on the givens in
the proper way.
For example, if you prove that a^{2} + b^{2} = c^{2} for «all»
triangles, you’ve proved something that isn’t true. The statement
should be restricted to right triangles in the Euclidean plane
... and your proofe of the statement should be clearly dependent on
these restrictions.
It’s bad luck to prove things that aren’t true.




4.4 Checking the solution to a problem

Solve the problem in more than one way. Any
problem worth solving is worth solving twice. For example, if a
physics problem can be solved in terms of forces, solve it again in
terms of energy, i.e. the principle of virtual work. If you
can apply Newton’s third law in terms of equalandopposite
forces, apply it again in terms of momentum conservation.
Maybe for an easy, nontricky problem you can get away with solving
it only once, but if you are dealing exclusively with easy,
nontricky problems you wouldn’t be reading this document.
This is of course related to item item 4: check the work.

Check that you have found the entire
solution set. Sometimes simplelooking questions have multiple
answers, some of which may be very much less obvious than others.
Example: SouthWestNorth equilateral triangle on the surface
of a sphere.
5 Formalism, Algorithms, et cetera

As mentioned in item 11, formalism can
be very powerful. Learn to use the formalism.
Formalism is a tool. Any tool can be abused ... but that doesn’t mean
you are obliged to abuse it. Powerful tools, when properly used, make
it easier (not harder) to understand what’s going on. For example:
Consider the following contrast:
Maxwell’s paper on electrodynamics is almost unreadable.
That’s because he didn’t use vector formalism. Vectors were not
invented until many years later.


Nowadays, we write the Maxwell
equations in terms of vectors ... or, preferably, bivectors.



When you see the vector equation, you need to know the
vector formalism to make sense of it.

Without vectors, you are left with a bunch of dry
mathematical equations, and figuring out what they mean physically is
exceedingly difficult.


Using vector ideas, you can visualize what’s
going on. The vectors have a physical significance.

If you try to do without vectors, you wind up with so many
equations it’s difficult to keep track of them.


The vector equations
are quite compact. You can look at them all at once.

So, when trying to solve an electrodynamics problem, there are three
possibilities:
 The best option is to learn to use the formalism properly, and
use it to solve the problem.
 If you try to use the formalism without fully understanding it,
you might get the right answer, or you might not. You might just
generate a big fancy mess.
 If you try to solve the problem without using the formalism at
all, you’re just wasting your time. Learning the formalism is far
easier than trying to solve the problem without it.
Here’s another example that supports the same conclusion:
If you learn to play the piano, in the sense of hitting
hitting the right notes, it does not automatically bestow artistry or
a “feel” for the music.


Learning to play the piano does not
prevent you from acquiring artistry and musical feeling, and may even
help.

After all, you could program an unfeeling robot to hit the
right notes.


Just because you “could” play like a robot doesn’t
mean you are obliged to.

In all cases, remember the proverb:
It is a poor workman who blames his tools.




I say learn to use the tool, and then do something sensible with it.
6 Practice

There is a saying that «practice makes
perfect» but that is quite wrong. The fact is, practice makes
permanent. Practicing the wrong things is worse than nothing.
Practice makes permanent.




7 References


TeachMath
“Mathematical Habits of Mind”
http://honeymath.blogspot.com/2012/05/mathematicalhabitsofmind.html

George Pólya,
How to Solve It: A New Aspect of Mathematical Method
1st edition (1945), 2nd edition (1957), Princeton University Press

Timothy Gowers,
“Proving the fundamental theorem of arithmetic”
https://gowers.wordpress.com/2011/11/18/provingthefundamentaltheoremofarithmetic/

John Denker,
“Learning, Remembering, and Thinking”
www.av8n.com/physics/thinking.htm

John Denker,
“Principles of Teaching and Learning”
www.av8n.com/physics/pedagogy.htm

John Denker,
“Suggestions for Writing Good Software”
www.av8n.com/computer/htm/goodsoftware.htm

Wikipedia article: “Diagram”
https://en.wikipedia.org/wiki/Diagram#Specific_diagram_types

John Denker,
“How to Deal with IllPosed Questions”
www.av8n.com/physics/illposed.htm

John Denker,
“Perspectives on Johnson Noise”
www.av8n.com/physics/johnsonnoise.htm

John Denker,
“Modeling a Collision with Successive Refinement”
www.av8n.com/physics/collisionmodelrefine.htm

John Denker,
“Hints on How to Do Math”
www.av8n.com/physics/mathhints.htm

Puzzle: “Who Owns the Fish?”
www.av8n.com/physics/whoownsthefish.htm

John Denker
“Dimensional Analysis”
www.av8n.com/physics/dimensionalanalysis.htm

John Denker,
“Scaling Laws”
www.av8n.com/physics/scaling.htm