AntiPattern related to, but worse than ArchitectsDontCode. It refers strictly to authors who write on topics related to SoftwareDevelopment. If we can agree that ArchitectsDontCode is an AntiPattern, than the next logical step is to agree that AuthorsDontCode is an anti-pattern. And while the impact of ArchitectsDontCode is significant, the impact of AuthorsDontCode is even greater. The last few years, I've noticed an increasing lack of quality of the books on Software Engineering subjects, when I walk into a bookstore. Very often I find that I'm not willing to spend any money on any book, because it doesn't offer me any new and significant information, and worse, a lot of books abound offer what I as a practitioner consider BadAdvice. Next I observed that many book authors in the field of SoftwareDevelopment are people who don't code (or more exactly don't code anymore). They are busy writing books, doing lucrative consulting projects where they advise others on how they should architect/design/code, so they won't ever know with enough precision what is the quality of their printed advice. Because that's what they produce: advice and opinions. Very rarely can you find a book on SoftwareDevelopment issues where the discourse and the argumentation is close to what can be called a scientific discourse. This is not necessarily a bad thing, or it is the best we can hope at this time (around 2001 and a few years to come), when the fields of SoftwareEngineering and ComputerScience are still quite some distance apart. Even worse, there is a noticeable ideological and political current that is concerned first with keeping that distance. ''example please'' But if the author offers his advice and opinion drawn from real life, successful and non-trivial projects where he/she was on the line - i.e. directly responsible for the end results - you'll notice an increased quality in the accuracy and usefulness of his/her advice. The opposite is authors who give advice based on what they think might be good, what they advised others to do, without being directly involved in the project, and at the best advice and opinions based on projects that they did years ago, when the technology and the problems to be addressed were significantly different from what we see today. ---- '''proposed solution''': Maybe we as readers will come to expect the authors to disclose the last significant project where they did code before writing the book. And we should look at the books of those who don't code with great suspicion, no matter what their names might be. This seems fairly radical, considering that there may be authors who don't code, but still can offer good advice. But those authors should be able to compensate with the rigor of a scientific discourse - the quality of their argumentation should be higher because they can't say ''it worked for me''. ---- We have quite a few book authors contributing on wiki, who do code. Maybe a list would be in order. ---- Maybe there is a more-general AntiPattern or meta-pattern here, which leads to ArchitectsDontCode, AuthorsDontCode, CommitteesDontCode, ProfessorsDontCode, MethodologistsDontCode, ConsultantsDontCode, ResearchersDontCode, EngineersDontCode, DomainExpertsDontCode, SalespeopleDontCode, ManagersDontCode, etc. That higher-level pattern can be summarized as "Those with strong opinions about or influence over how software should work or how it should be developed often do not participate in software development." The problem is it takes a while to form opinions and by then you are burnt and don't want to code within a company anymore. And the most serious AntiPattern is when ProgrammersDontCode, because they are too busy fixing bugs, doing paperwork, managing/meeting other people, or avoiding/quitting work entirely because it is just too distasteful. ---- There is a difference between those who code what they must to facilitate their writings (CodeToWrite), and those who write what they must to facilitate their coding (WriteToCode). Choose your gurus wisely. ---- There's nothing new on this page. The age-old saying says it all: 'those who can, do, those who can't, teach, and those who can't teach, teach teaching' --AndrewQueisser ---- Ahh, that wonderful AntiPattern of Western thought: PolarizingTheContinuum. Why must we wield a knife and divide the world into those who can't but write, and those who can but don't write? There really are authors out there who are good coders, and coders who can write. Additionally, I fear that this discussion has suffered from another AntiPattern of Western thought: QuotingNotThinking. Well-known aphorisms seem to create their own magnetic field: when a discussion veers too close to the subject of the aphorism, it gets "stuck" to the aphorism, and all meaningful thought ceases. Could QuotingNotThinking be adapted similarly to GodwinsLaw, or would it then be a victim of itself? :-) ---- How, then, will we inexperienced programmers separate the wheat from the chaff? Are there any guidelines other than actual experience (which we don't have)? WhoCanYouTrust? ---- I think AuthorsDontCode could be a GreyPattern - see GuruDoesNothing. -- TomRossen ---- Does this apply to authors writing about software culture as well as development? See http://www.runme.org/categories/+text_-_software_art_related/+cultural_critique_of_software/ Then again, perhaps the most comprehensive texts on software culture can be found in places like this one and the JargonFile . ---- As an author, this is created by a corporate anti-pattern - specifically, authors get paid much less than developers. It's damn near impossible for publishers to find an experienced developer who can fill a complex Word template with literate English, finish a book on a tight deadline, *and* write it for peanuts. Authors are usually: 1. Writing a book as a spare time project and/or because they can't find other work and/or because they naively believe writing a book will make them more employable. 2. Wannabe guru types who have a schtick to sell or are/were involved in creating a significant product or technology they are trying to trade on. 3. Generalists who are learning as they go and would typically be in a hypothetical lower quartile of developer skill on a real-world project - but will have learned the topic, written 50k to 100k words about it, and done the same for two or three other topics at the same time. This is not a recipe for quality. But sales simply don't justify paying developer rates to most authors. ---- CategoryAntiPattern