Note: "Troubleshooting" and "problem solving" are separate because they are distinct. Similarly, "Multi-time scale planning" and "plan" are distinct.
Troubleshooting, problem solving, planning skills are not taught in school.
metacognition/introspection: "being smarter" means changing how you think. It is useful to start from how you think now, so that you know what to change.
Learn from your own mistakes
Try keeping a log of mistakes you have made. How much time was used (significance)? How will you ensure not repeating the mistake? [If you don't keep a log and review it, you will forget previous mistakes and then repeat them.]
Learn from the mistakes of others
When you observe someone else making a mistake, are you making a similar mistake without realizing it?
You will need to evaluate how you made the mistake, then how you will avoid it in the future.
Why aren't most mistakes evaluated? Because useful evaluation takes time and effort. It is much quicker to acknowledge the mistake and respond, "oops, don't do that again" and then continue on. Analyzing why the mistake occurred and how to prevent it is time consuming.
[These focus on project management, but the same ideas apply to the individual]
http://www.projectsmart.co.uk/lessons-learned-why-dont-we-learn-from-them.html
http://www.projectsmart.co.uk/avoid-the-same-old-mistakes-by-focussing-on-lessons-learned.html
When designing a process, create a feedback mechanism to detect mistakes.
In school, this takes the form of grading. Most students just look at the score (instead of evaluating how the mistakes were made). On the other side, teachers are surprised at the incompetence of their students, but they make no change to their teaching. (The grades can also be used as a feedback mechanism for the teachers.)
Some jobs have performance evaluations, but usually feedback is more subtle
"Mistake" is defined as 'an error in action, calculation, opinion, or judgment caused by poor reasoning, carelessness, insufficient knowledge.' Thus, by recognizing, correcting, and avoiding mistakes we increase knowledge and fix poor reasoning.
Mistakes are part of the the scientific method, which is
Observe situation
hypthesize an explanation
experiment to test prediction
Analyze results of experiment, make corrections to hypothesis
The "experiment" is daily practices, which has occasional mistakes. These mistakes are feedback showing the hypothesis to be incorrect. "Analysis" of mistakes is rare at the personal introspection level.
Why don't people recognize, analyze, and prevent mistakes? Because they evaluate themselves as sufficient. See http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
The last place most people look for fault is to themselves, even though they are the common factor. This is because their initial implicit assumption is "I am correct."
Detecting mistakes can be difficult when there is no feedback. Feedback can come in the form of experiencing surprise in a situation you have previously been in. The surprise means the situation did not match your expectations, thus there was a mistake in your assumptions.
Know what there is to know
Further, this helps to avoid re-inventing an existing process
Before performing a task, evaluate whether someone else has already done it, or some piece of the process. Then re-use their work. If no one else has done it, why not?
"Troubleshooting" is a form of diagnosing the reason behind a question (sometimes hidden as a statement).
Example: "My computer doesn't work" is a statement which can be equivalently formed as a question, "I don't know why my computer doesn't work." Either way, troubleshooting is needed to refine the question
one degree of freedom testing
reproducible error
When comparing two versions, one which is broken but desired and another which works but is not wanted, determine whether it is faster to work from the functioning version or broken version.
Avoid repetitious tasks, as these usually mean you are not learning anything new.
Automate where possible
On computers, write scripts for common tasks
Make checklists for common tasks. This prevents missed steps and allows you to concentrate on other aspects
Basic problem solving techniques:
Know the answer before making calculations
Get order of magnitude estimates. How? Fast estimation tricks:
When adding 1043 + 293, round. The answer should be about 1000+300=1300
When multiplying 9.5 * 1032, round. The answer should be about 10*1000=10000
How a problem scales can tell you about the underlying physics
Have an intuitive grasp of the problem before solving.
Before taking the derivative of an equation, have an idea of what the equation looks like so that you'll know what to expect for the derivative
If the answer is to a complex question, create a simpler model to find an approximate solution first
Draw a picture relating what you know and what you want to solve for
Instead of dealing with messy complex system, isolate the process and draw a box around it. Account for things in the box and passing its boundaries
Make approximations of messy equations. To simplify, separate important from unimportant components based on physical arguments. It is difficult to rank the relative importance of terms without understanding physical relevance of each part.
Do not calculate blindly. Describe the problem qualitatively before doing quantitative analysis. This guides the analytics and gives a reason for doing them.
Use the most appropriate tool(s) appropriate to the task with which you are familiar. If there better tools but you are unfamiliar with them, then you'll need to compare learning how to use the better tool versus using a more familiar but suboptimal tool.
Multi-time scale planning capability: what are my short-time plans, long-term plans. While solving a problem, you need to be able to keep all these scales in mind simultaneously so that you can optimize with respect to all the goals.
Planning = future, learning from mistakes = past
Smart = the ability to make connections within a knowledge base. This requires (1) a knowledge base and (2) problem solving to make the connections.
There are some pieces of "trivia" which can actually be useful. For example, in physics (specifically statistical mechanics) it is useful to know
1 eV is approximately 10,000 Kelvin (related by k_boltzmann)
ionization energy of electron: 13.6 eV
age of the universe: 13.75 billion years
speed of light: 3E8 m/s = 186,000 miles per hour
sun to earth distance: 8 light minutes
earth radius: 6000 km = 4000 miles
For Americans, conversion between unit systems is useful (1 meter=1 yard, 1 gallon = 4 liters, etc).
http://www.nytimes.com/interactive/2011/02/20/magazine/mind-secrets.html
http://en.wikipedia.org/wiki/Method_of_loci
Good questions require well-defined language. Science instills an exactness of language. When I say "probably," I actually mean of the known possible events, the event specified has the highest probability of occurring. Thus, science results in a set of shared definitions. Finding the definitions can come from reading community documents (peer-reviewed journal articles).
Good questions usually result in progress (an increase in the knowledge base).
Results must be communicated. This means publishing, attending conferences.
Work on improving your communication skills. Your skills are useless unless they are communicated (idea versus meme)
Work on improving your social skills. You'll want to have people to talk to.
Tell your audience explicitly to notify you if you are incorrect. Be open to correction (see learning from mistakes).
Establish your goal or objective. The more clearly defined this is, the easier you can break it into steps
Plan your action. What steps are necessary to accomplishing the goal? There will be multiple options, so create contingency plans and do not expect there to be one best path
How will others respond to your plan? Who is the audience, who will be affected?
Do their predicted response benefit your plan? That is, does their reaction positively affect your objective?
As part of 3, you can imagine verbal scripts for upcoming conversations.
This is part of thinking multiple steps ahead, which should include who you will be interacting with.
Instead of setting time deadlines, use task goals. For example, instead of "write project report for 1 hour," use "write 2 pages of project report." The second has no time limit yet produces results. The first approach does not specify results needed, so one can procrastinate.
Stagger finishes when juggling multiple projects.
Smarter usually means a leadership position. Leadership is usually under appreciated
Observation: this process has similarities to martial arts [first, your fight technique is the best; then you can fight with any technique and win; lastly you win fights without technique] and coding [1) define the problem; 2) know which tool to use; 3) know how to use that tool; 4) are there better tools for this problem (and usually Lisp is the answer)].
Knowing how to be smarter is distinct from being smarter. The above information must not only be implemented, but be a way of life. Ingrained into how you behave.
Being smart in one area often has no correlation to overall intelligence. That is, I may be a brilliant programmer but a horrible public speaker. A trick is to bootstrap one skill area into another.
If you don't interact with people who are smarter than you, then you will have a hard time recognizing your limitations. If you are not as smart as the person you compete against, it can be easier to see where you need improvement.
"Safety first" is another saying similar to "learn from your mistakes." It is a legitimate ranking of priorities based on self-preservation and the principle "do unto others as you would have them do unto you." Logical in the evolutionary sense, and usually easy to implement. However, it is rarely carried out well. People carrying out the specific task are aware of the phrase but it is not their primary mission.
Q: Why isn't this list well organized, like "7 habits of highly effective people," or some other expensive seminar?
A: Because I don't think there is some discrete set of points to sell. When I hear "7" I wonder if the points have been shown to be independent, and if it has been proven there are no more than 7.
My other criticism is that by whittling the idea down to a small dumb phrase, you lose the essense of what is being conveyed. Analogously, a lot of people have heard of "E=mc^2." Fewer know what it means, and very few know how to implement or derive it.
http://www.catb.org/~esr/faqs/hacker-howto.html
http://en.wikipedia.org/wiki/Unix_philosophy
http://www.paulgraham.com/articles.html
http://www.paulgraham.com/icad.html
http://www.cs.utexas.edu/users/EWD/
http://www.amazon.com/Thinking-Mathematically-J-Mason/dp/0201102382