Introduction
This book is not about how to write a computer program. We already have lots of books about how to write computer programs.
Instead, this book is about self-education. It will cover the psychology of learning, how to learn a skill quickly, and how to attain mastery as opposed to simple working proficiency. With luck, it will one day provide a comprehensive guide for people who want to learn programming skills outside of formal education.
Who is a Self-Taught Programmer?
Who is a self-taught programmer? For now, we define it as anyone who learns to program computers outside of a formal education environment, at any point. So this includes beginners who go online to try their hand at their very first programming language. It also includes programmers who have reached some level of proficiency through independent study and tutoring. It includes all of the masters, because mastery of a still requires extensive additional self-education outside of formal teaching environments.
Recipe for a Useful Explanatory Book
That said, the guiding principle of this book's composition is the Principle of Least Surprise. This chapter from The Art of Unix Programming explains the concept beautifully, if you're interested. How do we apply the Principle of Least Surprise to writing a book?
Like this:
1. Use self-explanatory language. This allows your readers to focus on your message without having to stop and look up your words. Example: the introduction above uses the term "self-education" and not "autodidactism" on purpose.
If you must use jargon to describe something, explain the term to the reader. Examples of terms that would require explanation are "garbage-collected," "concurrency," and "Extended Backus-Naur Form."
2. Use self-explanatory chapter titles. We want readers to be able to find what they're looking for from the Table of Contents. A non-humorous, obvious chapter title is far preferable to a cute title with tech puns and inside jokes. For example, a chapter entitled "Choosing your First Project" is a much better fit for this book than the same chapter entitled "Scoping the Epic Quest."
3. Organize your thoughts. If you are contributing a new chapter, please make sure that the thoughts are well-organized. If they flow well from one to the next, that is excellent. If they at least follow a logical progression, that is sufficient.
For an excellent cheat guide to well-organized writing, you want to look at Section III, 'Elementary Principles of Composition,' in The Elements of Style. The entire book is available for free online as a pdf.
Other guidelines for contributing to this book:
1. Keep it language-agnostic. That does not mean that you cannot express evidence-based statements on the fitness of a language for a particular purpose. For example, it is okay to say "the python programming language requires a minimal amount of setup to begin writing programs, so it is useful as a starter language for a first-time programmer." However, keep in mind that every language possesses self-taught users, and the majority of this book's advice should be useful to all of them.
2. Keep it IDE, color scheme, library, and framework-agnostic. The same rules apply as above for languages.
3. Use examples wherever possible. Examples make information easier to absorb, so include examples wherever you introduce new information. If you are explaining how to schedule study time, an example daily or weekly schedule may help get the point across.
4. Pictures and stories are great, too. The brain remembers information better when it receives that information in multiple different formats. If you learned something important about self-education from a particular personal experience, that experience might be worth sharing. If you are explaining how to diagram a computer program, a picture might help your explanation.
5. When you introduce new terminology, add it to the glossary as well as explain it in the text. The gitbook editor makes this easy: the rightmost button on the top toolbar is for adding terms to the glossary. Speaking of which...