Free Software Documentation

Found a site that is trying to improve free software documentation. I found this interesting because the idea is related to a previous post that I had about open source tech writers.

It seems that their goal is to improve the documentation of free software products to increase their adoption. You can check this out on the about tab. The discussion on their FLOSS manuals overview reminded me of thoughts that I was having about having some sort of open source documentation or tech writing business. They basically outline the major models for producing content and being compensated for it. There were several sections that focused on the prevailing mindset, technologies, and economics of doing open source (in this case, for free software) documentation. I agree with them that adequate and consistent documentation is something that keeps most open source and free software from being widely adopted on the desktop.

There have been some free software products out there that have been very widely accepted, such as Firefox. I wonder if it is because the program itself was leaps ahead of the proprietary alternative, or if something else contributed to its success.

Dream Recall

I’ve had vivid dreams for a long time, and at some point in high school I got interested in remembering them. Here are my experiences.

Why I’m interested in this

Dreams are a great way to get to know yourself better. Plus, they are a good way to solve problems. Your subconscious mind works in an environment with different constraints than reality, often providing valuable insights. You may know something that you cannot apprehend consciously. I think that it makes you more creative because you get better at listening to different parts of your brain. Plus, you’re sleeping anyway, so you might as well make the best of it. :)

Dream recall

Dream recall is, appropriately enough, the ability to remember dreams, their details, and storyline. Think of this something like physical strength–it is something you can improve with practice or training. Most people only naturally recall dreams that are especially vivid or when they are woken up at irregular times. But know that pretty much everyone has dreams almost every night.

The very most important thing you can do to improve your recall is to keep a dream journal. This might sound corny. However, most dreams are only memorable when you are first waking up. Again, it’s like a muscle that you can build up, and this is training. As you get better at recalling, you will see more details and remember them for longer. Upon waking from a dream or in the morning, you should turn on a minimum of lights and start writing in a notebook that you have dedicated to this purpose. Just write whatever you can remember, even small fragments, and the act of writing will solidify them somewhat. Colors, places, people, and feelings are good starting points.

I usually write in the past tense (I had a dream that… or I dreamt that…) This seems most natural based on the fact that it indeed happened in the past. As a result, every night I write down tomorrow’s date. This serves to prepare me for sleep and gives closure to the day. When lying in bed, thinking about writing something down the next day usually helps. Mentally rehearsing writing or acting it out during the evening can help you train to write in the morning. The writing doesn’t have to be very legible, as long as you can somewhat read it. You can clean it up later.

Sometimes you cannot remember any dreams. It’s OK. Just keep trying. No big deal. Any detail you remember can help strengthen your recall, so just be persistent. Also, sometimes when I get into bed the next night, I will have a glimmer of a dream from the night before.

If you can recall multiple dreams, write a quick trigger for each of them, like “tarantulas + Bruce Willis” or “high school locker” so that you don’t forget a whole dream when writing down the others. Sometimes a dream will be right on the brink of your mind, just try to find the trigger and most of it will come flooding back.

Interpretation can be useful or misleading. Usually the meaning of a dream is pretty clear if it reminds you of something you have been thinking or worrying about. Other times your brain is just simulating different experiences for practice or synthesizing existing experiences.

Caps Lock Remapping

You don’t really need your caps lock key. Seriously.

You can swap it with a different function that you use all of the time. I recommend switching it to the escape key. You can also change it to function as a control key. But why would you want to do this?

Benefits

First, the caps lock key is modal, which means that much mayhem can result from misplaced keystrokes with the caps on, especially when working with complex text editors. There is little visual and no tactile feedback on the state of the caps lock. This inevitably leads to annoyances when the lock is on. There’s a reason that login dialogs always warn you when the caps lock is on.

Regardless of your text editor preferences, you stand to gain quite a bit from making this change if you use the keyboard even to a moderate degree. Imagine that an annoying dialog pops up and instead of clicking on the close button or invoking alt + F4 or sliding up to the Esc key, you can instead quickly disregard the window with a mere slide of your pinkie. When an application informs that you have unsaved changes on closing, pressing escape is a lot faster than figuring out which of the buttons on the dialog correspond to “please don’t disregard my changes.”

If you’re a Vim user, you stand to gain much more utility from having the caps lock key stand for ‘escape’ instead. Firstly, inadvertent caps lock use will kill you in Vim. Most of the normal mode commands are case-sensitive, so instead of going down ten lines, you’ve just concatenated the next ten lines. Whoops. Second, escape is the function that you invoke to get from whatever mode they are currently in to the normal mode. You press escape a lot. The saving here comes from sliding your left-hand’s pinkie finger over a tenth of an inch instead of having your hand travel two or more inches. Over the course of a year you will save about eight million miles. Instead of using the crufty caps lock key, you can just select a section and press “U”, and then the section will be converted to uppercase. That’s if you don’t want to hold shift down for like five seconds.

On the other hand, if you’re an Emacs junkie or general keyboard user, you might consider remapping the caps lock key to a control key. This is probably still more useful than the caps lock, and moving it up an inch makes it more accessible.

If you don’t like it, you can always go back! You can also remap something you use even more rarely (like the scroll lock key) to function as a caps key. But I get by fine without any caps.

So how do you do this?

For linux, I would try this tip. Another good start is doing a web search or going to this c2 page.

Drawbacks

It takes about a week to get your muscle memory fully used to this. It takes longer if you have multiple computers that use different or default bindings. Once you get used to it though, you will be hooked.

If other people try to use your computer, they will be stymied in the unlikely event that they want to use the caps lock key for its intended purpose. So don’t let them use your computer. :)

Personal MBA

The Personal MBA program founders think that you can understand the fundamentals and mechanics of business by reading a list of books that they have hand picked as the best in the business field. They conjecture you might get close to the same education level as a traditional MBA with much less time and money.

While skeptical that it will line up fully with most MBA programs, I think that this program has the right idea. The best learning comes when one is interested in something and really wants to learn more about it. I am interested in learning more about business and entrepreneurship since I feel that my strengths lead in this direction. It seems that these books will give a high return on time invested, as most of the time I see new connections or learn new skills. While the information might not be applicable right away, just knowing more gives me confidence that I will succeed when the time comes. There seems to be a lot to learn, but it’s not rocket surgery either. Many concepts are similar to each other, and having a background in economics probably helps.

My current PMBA progress is here. Both Getting Real (which you can read for free online) and How to Win Friends and Influence People are highly recommended for their fresh perspectives.

If you are in the Indianapolis area, I could be convinced to do a book swap. Many of these books can also probably be found at the library (although I haven’t looked much myself.) It would be helpful to chat about them to refresh my memory and solidify the concepts, so if you’re reading one, let me know. There are reviews or notes for a few of the books in the notes section of this blog.

Writing Is Like Coding

Matt wrote that coding is like writing. I came to the inverse, although similar, conclusion in high school. Writing words resembles writing programs for the brain. In both, to communicate your meaning correctly, you need to know your audience and signal based on your representation of the underlying system. This will allow the interpreter to understand what you are saying.

I originally felt this parallel when I constructed arguments for essays. Words and sentences must be read through sequentially and the work needs to make sense. This resembles writing a program and running through it in your head before executing. When writing a paper, I found framing arguments often corresponded to declaring variables. The introduction of a paper lines up with initialization, setting the evaluator’s mind in a specific state for later communication. The conclusion is cleanup. Pronouns are abbreviations or aliases to entities. A sentence that could be ambiguous should be expanded out, much like one would use parentheses to clarify a potentially ambiguous expression.

I suppose the common thread between writing and programming is logic and the ability to read, reason about, and judge the source. Obviously the brain is a more fickle interpreter.

This insight makes me wonder about development analogies for writing. What would test-driven writing be like? Could we codify knowledge like: “This sentence presupposes this paragraph to make sense.” Continuous integration for writing? How about collaborative writing with version control and branching?