Ask HN: What's your process for learning?

Here's the approach I use:

- Every time you come across a new term or concept, you create a new "notebook"/document. That's right, one notebook per concept. The title of the notebook is the name of the concept.

- You create a summary for the concept using bullet points. What you're trying to maximize with this set of bullet points is the speed at which, in the future, you can re-read them and achieve a similar brain state to what you had when you originally learned the concept.

- You can then obviously have extended notes below that where you go into more detail.

- Then, crucially, you create something akin to a regex that will allow you to quickly and unambiguously look the concept up in the future. If you just learned what a rectified linear unit is, your pattern might simply be:

rlu | (rectified linear unit)

- You then have a hotkey on your computer -- I use Ctrl-Q, that brings up a text box where you can type the name of the concept you want to bring up (ex. "rlu"). When you press ENTER, it doesn't give you search results if there's an exact match, but instead directly opens the document and makes it instantly viewable / editable.

- As your concept graph starts to grow, you have links within your notebooks to related concepts as they're referenced.

- Each time you read an article that is important to your understanding of a concept, you quickly open up that notebook and add that article, and perhaps one or two bullet points that contain the key things you learned that expanded your sense of that concept.

- This same system can be used for more than learning text book information. You can use it if your a project manager to keep tabs on the millions of things you have to juggle, you can have notebooks for people, for lists, and you can have "regexes" for "programs"/scripts, for web pages, for files/directories, etc, etc.

- More general than "regexes" are context free grammars. In this context what that means is the ability to have named "subroutines" for your regexes. For example, if you end up using RLU as a sub-part of a lot of other notebook regexes, then you might define $rlu to be a short form for (rlu | (rectified linear unit)).

A customer called me at 5 pm. They had a possible six figure hardware sale, but a key aspect of their hardware was too slow, their only embedded software/hardware guy was no longer working there, and they had to have the new code in 24 hours for a demo.

The software component to be sped up was three cores running handwritten assembly, and had been optimized by several people over four years.

The total of my embedded software experience was fooling around with an Arduino. I'd never written assembler before and never see this processor or its family before.

This was going to be good.

I wrote down the problem, and did the math to find out what the solution would have to look like.

It's hugely important to define the problem, and constrain the solution as much as possible. Nailing these down is probably the single most important "trick" problem solving.

With the problem defined, and the solution constrained, I printed the entire processor manual, and read/scanned it through in one sitting. I then went back over the memory and instruction timing sections, since that was going to be the hardest part.

I at least, learn much better by first scanning through a paper book on a subject. This lets you get the big picture all in your head at once, and see how things connect. Unlike just reading an overview, you also get to see the hard details that make up the way the system works. Then go back through later for the sections that matter for the problem you are working on.

I hooked up the customers hardware to the computer, flashed code the existing code to it, then changed the code to turn a status LED off. This was just to verify that I had the code to hardware toolchain working.

I've learned to bite off a small piece at a time, and then build up, rather than trying to solve everything at one go. The first code I ran on the processor just changed a status LED. This let me focus on as small of a chunk as possible, and deal with getting the new IDE configured, etc, without having to worry about the whole class of problems that would come from running my new algo.

I know I need X amount of sleep to solve problems. Even with a crazy deadline, knew I'd do still come out ahead. I went to bed at my usual time.

When I woke up, I knew how to solve the problem. The solution was similar to drawing a diagonal line on a computer screen - which is a really easy problem.

I've found that you can think in your sleep. Maybe this is just me again, but I've learned that as long as I clearly layout a problem, solution, and tools before I sleep, I wake up with the answer. I don't even wonder anymore if it's going to happen. Perhaps this is just the result of a lot of experience, but it never fails. If I'm stuck on something during the day, I just take a shower or a nap and know the answer afterwords.

Because the algorithm was going to be the most important part of this, I coded a JavaScript/HTML 5 canvas visualizer that gave me a live slider for the input variable and showed me a single view the output over many thousands of time steps. The JavaScript version of the algo worked great.

In optimization, the algorithm usually matters far more than anything else. It wasn't that I was the king of assembly language programmers, it was just that I was doing an entirely different thing than the previous programmers had been optimizing. I started with "what would the ideal solution to this problem be", and they started with "let's translate a hardware concept to software".

The second biggest trick to working with a new problem is visualization. I've learned that I can hugely increase my speed of understanding by building tools to visualize the problem and what my code is doing to solve it. For example in the recent, awesome, Halite programming competition, I built a tool that would let me output annotated html5 game maps and documents from within my code. Here's an example visualization output, straight from source code http://braino.org/thoughts/halite_the_simple_way.html OODA loops really do matter, and really are constrained by how much you can see how fast.

After breakfast, I worked out the assembly instructions I'd need, tracking the timing and register values on graph paper. I read up carefully in the docs on each instruction I'd need.

By lunch time I had a paper version that should work, and by 3pm I had it running in the product and had learned how to use an oscilloscope. The customer picked up the hardware and got the sale. The new version used one core instead of three and was measurably, literally ten thousand times improved.

I was now a carded member of the Real Programmers Society.

I find it helpful to type examples as I read too (for programming stuff)