Knuth is the author of "Art of Computer Programming". He writes code mostly for instructional purposes, for humans to read, I would think. Literate programmin

Knuth is the author of "Art of Computer Programming". He writes code mostly for instructional purposes, for humans to read, I would think. Literate programming makes sense in that context. And it is true that to create a truly maintainable program you need to provide good documentation, maybe literate programming is the best way to accomplish that. However I feel I don't have the time to invest in producing great documentation. I write code the best I can and my goal is to finish a big project in a timely manner. I feel documenting everything while the program is still evolving would be wasteful because then the documentation should be continually revised and typically it is not. A similar issue applies to unit-testing. If I need to change my program I also need to rewrite the unit-tests. "Testability" is a great goal for software and so is "maintainability". But the most important quality of software is "does it do what it should, already this year". If I wrote a blog-post or a technical article I would put great care into how I best present the software both in code and in documentation around it. But mostly I just write programs for the computer to execute, not for people to read about it. The ultimate example of Literate Programming is writing a book about your program. I had a book once called "How Tomcat Works", about the web-server called "Tomcat". A great book explaining in detail how Tomcat does (did? )work. But who of us have the time to write a book? My priorities are: 1. Write great code that does what it should 2. Write some API documentation about it so I and others can understand how to use it. 3. (The least important) Document and explain how the code works.