![]() 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. 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: 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. ![]() The big picture is this: using FreeMind lets us densify the documentation for our stack by a factor of at least 1,000. 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. 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. 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. Now let's say you want to quickly look up how to check whether a dictionary has a certain entry in Python. The way you view it is by installing FreeMind. You can get it by right clicking and saving as a. Here is a link to the (partial) documentation for my own stack: python.mm. However, rather than formally defining mind mapping and folding, I'll explain by way of example. ![]() 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. 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.īy using a specific piece of mind mapping software called FreeMind. This is exactly the right idea, but we need to take it a step further. 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. Not just a little better, but vastly better. This is bad.īut 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. But this is extremely slow and tedious, so most likely you'll just end up going with the first thing that's close enough. 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 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. Then you need to control-f to try to find a tool that does roughly what you're looking for. That 'page' might actually be dozens or hundreds of pages long. 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.įirst you need to do a Google search to find the right page in the documentation. 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. 1 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. ![]() After all, the most readable line of code is always the one that isn't there. The most obvious solution is simply by programming less. 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 question, then, is how can we possibly produce high quality code? 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. 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. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |