How to come up with new ideas
- You have to be working on something, like a science project. New ideas don't just appear out of nothing.
- (*) Look carefully at the facts you think are fundamental to your project, and ask these questions of each one:
- It is true? Doubt is the most important scientific instinct.
- How do I know? What evidence supports your opinion?
- Then go beyond what you know and be explicit about what you want to know. Write your goal down, but before you jump into trying to find the answer, ask these questions:
- Is this goal worth knowing?
- Why is it worth knowing? What will be changed if I discover the answer to my question?
- Most importantly, is this something I personally need to know, or is it something others have told me is worthwhile? It is fine if the question originated from someone else, but your need to answer it has to come from inside.
- Then go take a walk. A potential path to a solution will come to you. The approach you come up with may not be right, or it may take a lot of refinement.
- Along the way, go back to (*) to examine your assumptions. Be sensitive to the times when something seems odd. These are the clues the world is sending you that there is something wrong with your strategy, or maybe even that a new discovery is waiting to be found.
- Be willing to try your idea out in public. Make it the subject of your next conference talk. It may turn out to be a bad idea, but that is OK. At least you will know that and can go ahead and try a different approach.
- Very often it will take all your creativity just to solve little problems that come up. This is certainly true of any programming job.
- Start each day with a diary entry. What did I do yesterday? What do I want to do today?
- Keep a log book, always. Write down what you did and what the result was. I use Evernote to keep track of each move I make, especially when I am working on a project that involves a lot of coding.
- Empty your email Inbox at least every week. Really, I mean zero. Your Inbox is like a to-do list that other people are allowed to add to; very bad for meaningful productivity. Some things can be archived or deleted after putting them on your calendar or a handwritten to-do list. The hardest item is always the oldest one, the "clinker" that you have been putting off. Deal with this one first and you will then be able to power rapidly through the rest.
- Use a citation manager (I like EndNote well enough, although it has a steep learning curve). Carefully curate references you think are good.
- Keep your tools sharp. Continuously clean out your old code folders. Write a README.txt for each folder, describing what each main program does, and its input and output. Memorize mathematical derivations, and practice working with equations and numbers in your head, or on paper without notes. Make flash cards with important dimensionless numbers.
- Organize all coding projects in this way: (Input) => [CODE] => (Output), where each part lives in separate directories.
- (Input) is for data files that are relatively static
- [CODE] is for your programs
- (Output) is where the results of your code end up, likely to change very often
- Keep your [CODE] in a repository like GitHub. This is essential for (a) keeping track of changes you make, and (b) pushing your code to other machines or colleagues.