No Docs

No docs is the ultimate approach to retaining job security and keeping your code as mystical as the ancient scrolls. Let's be real, documentation is just a crutch for those who can't handle the raw, untamed power of reading source code. Why help others when you can leave them to revel in the confusion that your genius inevitably spawns?

Getting Started

• Start by writing an attractive library or application. Then open source it.

• Do not write any documentation, or be vague. Leave the users confused.

• Think about the confusion and anger of the users. Celebrate it.

Advanced

However, for the true artist, there are techniques even more effective than merely avoiding documentation. These methods are often employed in some of the most well-regarded projects.

• Never offer a "Hello, World!" example (a.k.a. a minimal working example). This ensures users can't determine if their installation is flawed or if they're simply using the software incorrectly.

  • Example. If you are writing a "getting started" tutorial for a new programming language you create, do not tell the user what the extension name of the language is. Imagine a user with an empty text editor and no idea what to do, not even being able to create a file with the right extension. That's great, isn't it? Let them waste their time in the search engines.

• Tease users with enticing example illustrations. Fuel their desire but keep your tutorial vague enough to impede easy installation or initial use.

  • Example. If your project can be compiled from source, tell users what commands they need to compile, but don't tell them the path to the output executable.

• Write extremely detailed documentation, but in ambiguous natural language. Do not provide too many examples in formal language (aka. example code), so when users get into trouble, they have to look up answers in a mass of vague descriptions. Even better, when they ask questions in the community, you can blame them for not reading the documentation carefully.

• Automatically generate documentation from comments and source code. Experts can get the information they need from such documents, but not the beginners. Because of the "curse of knowledge", the beginners are not able to learn from community.

• Describe only the usage (API) of the library, but do not explain the purpose of it. Users will waste a lot of time before they find out that the library is not suitable.

Good luck!

License

This project is licensed under the terms of the Unlicense, see LICENSE.txt for details.