Program above and beyond your actual ability by using FreeMind

Technology is complicated.

These days building even the simplest website requires knowing at least half a dozen separate technologies, almost double if you want your site to be scalable and modular. Learning to program has always been challenging for beginners, but these days there are so many disparate pieces that even the best programmers are regularly called upon to write code in languages that they don't fully understand.

The question, then, is how can we possibly produce high quality code?

That is, given that it's no longer feasible to be an expert in all the tools we're required to use on a daily basis, how can we possibly produce code that's not just good enough some of the time, but that's consistently well commented, easy to read, efficient, and reusable?

The most obvious solution is simply by programming less. After all, the most readable line of code is always the one that isn't there.¹ How can we do this? One strategy is just to use the built-in tools of the language whenever possible rather than writing our own code that duplicates functionality.

The problem is that when you're not an expert at a given language then it's not obvious what functionality is already built in. And for most relatively minor problems, it's usually faster to just write a new function rather than trying to find out if a better solution already exists.

Why is this?

First you need to do a Google search to find the right page in the documentation. That 'page' might actually be dozens or hundreds of pages long. Then you need to control-f to try to find a tool that does roughly what you're looking for. But often what you're looking for doesn't come up, or else what comes up is only one of the many functions that could potentially do what you want, and the first one you find isn't actually best option.

When the quick search fails you end up paging down through the list of functions, scanning over the names and maybe the first couple sentences of the descriptions, trying to find a good fit. But this is extremely slow and tedious, so most likely you'll just end up going with the first thing that's close enough. This is bad.

But the worst part is that you probably won't even remember the exact method and how it works the next time you need it, meaning that especially for somewhat obscure methods you'll need to repeat this whole process again and again, getting only marginally faster each time.

We can do better. Not just a little better, but vastly better.

How?

In one of his essays Paul Graham speculates that perhaps the best hackers are the ones with the largest working memory, "so that when they look at a large program they don't just see that line but the whole program around it." However, he goes on to suggest that fortunately this isn't entirely necessary because you can cheat by using a really dense programming language. ²

This is exactly the right idea, but we need to take it a step further. In the same way that one can become a better programmer just by using a denser language, one can similarly become a better programmer by using denser documentation.

So how do we do this?

By using a specific piece of mind mapping software called FreeMind. While there are many software programs for doing mind mapping, FreeMind is unique because it has what its authors refer to as "a strong emphasis on folding." This is a distinction that's critically important. However, rather than formally defining mind mapping and folding, I'll explain by way of example.

Here is a link to the (partial) documentation for my own stack: python.mm. You can get it by right clicking and saving as a .mm file. Download it now. The way you view it is by installing FreeMind.

Now let's say you want to quickly look up how to check whether a dictionary has a certain entry in Python. Just use your arrow keys to scroll through the different nodes, and use the spacebar to expand a given node: Python > Dictionaries > Check if a dictionary has a key > key in d. Here is what you should see:

(Click to embiggen)

Instead of having to do a Google search and then scrolling through tons of documentation, or else trying to guess the right method based on the autocomplete suggestions in your IDE, you can actually look up the real answer in less than 10 seconds. If this doesn't impress you, it should. But what's even more impressive is that faster information lookup is just a small fraction of the total benefits we get from working this way.

The big picture is this: using FreeMind lets us densify the documentation for our stack by a factor of at least 1,000. Why is this important? Because it allows a programmer with 1x ability to program with 3 - 5x efficiency, and if you're already a 10x developer it will basically turn you into a god.

I know this is a big claim, so let's go through all of the things that FreeMind is going to let us do point by point:

1. See both the forest and the trees. In the example above, you can see the syntax for how to check whether or not a dictionary has a given key, but at the same time you can see all the other dictionary functions. And not only that, but you can also see a list of all the other (most important) datatypes that Python supports.
   
   Every time you refer to the mind map you get a visual reminder of how the specific tools you're using relate to the larger toolset. For example, every time you look up how to use a RegEx Match Object you're reminded about the relationship between Match Objects and Regular Expression Objects. Especially as a beginner, but probably at every level, having these visual reminders makes it easier to write not only good code, but also comments that are both articulate and thoughtful.
   
   This is huge. Why? Because both creativity and good decision making come from being able to combine pre-existing ideas in intelligent new ways. This means that being able to visualize both the details as well as the larger context and the alternative options at the same time is essentially an IQ supercharger. It's not just a matter of being able to look up the documentation slightly faster; once you get used to working this way you'll come up with vastly better ideas and solutions than you ever would have been able to before. This is something you simply need to experience to believe. I know it's considered poor form to start flame wars online. But based on extensive personal experience, I can't help but thinking that if you're not working this way then you might as well be eating paint chips, at least as far as your effective IQ is concerned.
2. Group tools by functionality. FreeMind lets you group similar tools together based on what they do, rather then having to read through the entire list alphabetically each time. In Python there are four different ways to add values to a dictionary, and they're all conveniently grouped in the 'add values to dictionary' section. Rather than paging through dozens of pages of documentation and going with the first semi-plausible method you find good and then continuing to do it the wrong way for the next five years, you can actually choose the best tool for the job each and every time.
   
   Life is about using the whole box of crayons, and organizing your documentation this way is a big step toward writing code that's concise, readable, and efficient.
3. Never make the same mistake twice. Every time I find a runtime error due to using some tool with the wrong syntax I immediately correct the mistake in the REPL, and then add that REPL example (as well as the initial error) to the MindMap. This way either I won't make the same mistakes again, or if I do then they'll be much easier to find and fix.
   
   Similarly, when I'm using a new built-in method for the first time it often takes a few minutes playing around in the REPL to learn how that method actually works and how to use it correctly. This is fine, but it isn't a process you should ever have to repeat. Being able to cut-and-paste a couple of canonical REPL examples directly into your map is a godsend. Not only should you add one or two examples that show how the tool is used correctly, but often it's useful to add an example or two of ways you'd think it might work based on the documentation but that actually result in errors.
   
   This is huge the next time you need to go back and reference a section. Reading one or two really good REPL examples is often a much faster and more effective way of understanding the tool than reading the official documentation. And even if those REPL examples aren't enough to convey the full functionality of the tool in its entirety, being able to glance at them first generally gives context to the documentation and makes it easier and faster to read. Rather than having to carefully read several paragraphs multiple times to start to understand what the method does and how it's supposed to work, you actually have full comprehension of the documentation the first time, and much faster to boot.
   
   In construction there is a saying that you should measure twice and cut once. When coding it should be just the opposite: REPL once, cut twice.
4. Cast a wide net. In addition to storing snippets from the official documentation along with REPL examples, you can also store Stack Overflow posts, blog entries, quora threads, A List Apart articles, HN comments, etc. The reason that I'm only sharing a relatively small portion of my own personal map is that frankly it has more copyright infringement than a public performance of a pirated Girl Talk album. This is a good thing.
   
   Rarely is the best explanation for complex functionality found in the official documentation. For example, in Python often the explanations for new features in the Python Enhancement Proposals (PEPs) are more clear and readable than the official documentation once they actually get added to the language. Between the tutorials, the documentation, and the PEPs, rarely is the best explanation for a given feature found in just one of these sources. Often each one has insights the others lack, so generally the best approach is to cut-and-paste a few sentences or paragraphs from each into your map.
   
   Often I also like retyping sections from books into my maps. Not only is this much more efficient than looking through the book each time want to look something up, but the act of retyping the most important sections forces you to really focus on what you're reading and helps you to better understand and retain the information. Generally when I'm reading I'll pencil in a dash next to the most important ideas and information, and then at the end of the chapter I'll add these sections to the map. I do this for both technical and non-technical books, and I find that it makes a world of difference.
5. Take complete ownership of the text. Let's say you really like a Stack Overflow explanation, but one of the examples isn't quite as clear as it could be. No problem. Just edit the text to make to say whatever it should have said originally. You own the text now, so you get to do whatever you want with it without permission or attribution. (Just don't redistribute this publicly.)
6. Easy memorization. Because each node in FreeMind is folding, your map essentially doubles as a set of flashcards that can help you memorize how to use the core features you find yourself frequently using. In fact, every time you look something up you're essentially drilling yourself with flashcards whether you realize it or not.
7. Never get stale. The problem with programming is that if you take a few weeks off to work in another language or just do something else entirely, when you come back it takes several days to get back into the flow. This is especially frustrating for tools you use only intermittently. How often do you spend hours teaching yourself something, and then the next time you need it the only thing you can remember is that you used to know this, and now you're going to have to spend hours learning it all again? The essence of FreeMind is that it lets you permanently store the entire contents of your mind in RAM, rather than having to offload the vast majority to the hard disk or trash collection. This lets you get back up to speed on any aspect of your stack in just a few minutes or hours, rather than the few days that it would normally take.

The big picture is that to program well you need both information and context. And not just from one source, but from the best of every source available.

One of the biggest reasons why beginners write bad code isn't because they're lacking the ability to do better, but rather because it takes so much time just to figure out what they need to know to get the program running correctly that there isn't any time for them to think about the larger issues: using the best tool for the job, writing code that's concise, readable, and reusable, thinking about how different sections of code fit together, taking the time to periodically refactor, etc.

FreeMind makes it infinitely faster to access this information. And not only are you accessing it faster, but you're getting information that's better because it's synthesized from a variety of sources. And not only this, but it's an entirely qualitatively different experience because you're essentially able to see both the forest and the trees at the same time. This helps you write lines of code that are not only better on their own, but that are also better in the context of the larger program.

To use a gaming analogy, it's like getting the benefits of sniper-level accuracy even if you only have shotgun-level aiming ability.

So, how can one implement this in real life?

When I'm teaching myself a new piece of technology I generally like to start by reading a some combination of books and tutorials, or else taking a class or watching a lecture. The first thing I do is to copy down everything I learn into the mind map. The material from these sources tends to be kind of scattershot, so much of it won't survive once I read the actual documentation. However, it's still useful to get an idea of what the most important features of a language are so that you know where you should be focusing your initial efforts. At the same time, there are often useful warnings about what parts of the language not to use because they're poorly thought out or confusing. I tend to avoid copying these parts into the final mind map so that I won't be tempted to use them later, or else I make sure that they are heavily caveated.

The next step is going through the official documentation and copying the useful bits. It's at this stage that I like to try to get things working in the REPL, and then add in those examples as well. If I still don't understand something then I look it up on Stack Overflow or the mailing lists and then also assimilate the information from there.

Unless I'm working with a relatively simple piece of technology (e.g. Less) I generally don't add everything to the map, just the most important functionality. I then continue to add more and more as I use the language, encounter new blog posts, etc.

The ideal is for every individual to do this for themselves. Feel free to use whatever parts of my map are useful for you, but don't blindly copy. Why? For two reasons:

• You won't understand what's in there or how it's organized. This will eliminate much of the usefulness.
• What should or shouldn't be included and how it should be organized varies depending on your ability as programmer, your knowledge of each specific programming language, how your mind works, etc.

In addition, to all of the benefits for programmers, there are a number of enormously useful non-technical uses for FreeMind as well. Here is a video I made explaining how I use it to organize the most important insights and data from all of the book, articles, academic studies, and government reports that I read:

This is usually where I find the citations for my Hacker News comments. By organizing data this way I'm able to easily find any given fact from anything I've ever read, all cross-referenced and vetted by primary sources. And even though this document would be hundreds of pages long if fully expanded, I'm able to do all this virtually instantaneously.

Pretty neat, huh?

I'll be the first to admit that using these techniques won't make you a 10x programmer overnight. But what they can do is help you to efficiently build up a solid foundation of programming and CS knowledge. And they can help you organize what you learn so that you can actually use it, commit it to memory, and add new knowledge as needed. If that isn't the way to becoming a 10x, I don't know what is.

And if you still can't see the wisdom of this approach, all I can say is just download a copy of FreeMind anyway. Try it out for a few years, you might find that it grows on you.

Notes

[1] I'm talking here about eliminating code by not repeating functionality and by not adding functionality you don't need in the first place. The other way to eliminate code is by condensing the rest of your program until it reads like aramaic, which is obviously a bad idea.

[2] A more powerful language reduces your need for working memory because the more you can see on the screen, the less you need to remember.