Slashdot Mirror
WTFM: Write the Freaking Manual
theodp writes "Blogger Floopsy complains that he would love to RTFM, but can't do so if no one will WTFM. 'You spend hours, days, months, perhaps years refining your masterpiece,' Floopsy laments to creators of otherwise excellent programming language, framework, and projects. 'It is an expression of your life's work, heart and soul. Why, then, would you shortchange yourself by providing poor or no documentation for the rest of us?' One problem with new program languages, a wise CS instructor of mine noted in the early look-Ma-no-documentation days of C++, is that their creators are not typically professional writers and shy away from the effort it takes to produce even less-than-satisfactory manuals. But without these early efforts, he explained, the language or technology may never gain enough traction for the Big Dogs like O'Reilly to come in and write the professional-caliber books that are necessary for truly widespread adoption. So, how important is quality documentation to you as a creator or potential user of new technologies? And how useful do you find the documentation that tech giants like Google (Go), Twitter (Bootstrap), Facebook (iOS 6 Facebook Integration), Microsoft (Windows Store apps), and Apple (Create Apps for IOS 6) produce to promote their nascent technologies? Is it useful on its own, or do you have to turn to other 'store-bought' documentation to really understand how to get things done?"
to WTFM, please oh please oh please stop writing flowery, circumlocutious prose.
Succinct... Precise... Concise...
Bullet points, short paragraphs, and simple descriptions are fine in most circumstances; this is not an expository writing project. I don't want to have to wade through your awful prose to decipher what the hell you're trying to say.
If I want to read a fucking story, I'll read a novel.
Real programmers don't document. If it was hard to write, it should be hard to understand. :-)
You youngsters always want things "explained" - geesh.
Seriously, get your hands dirty and work for it.
It must have been something you assimilated. . . .
I consider it no accident that the defacto standard language C (aka, "portable assembler") has a lot to do with not only it being the language of choice for UNIX, but the fact that it was accompanied by one of the masterpieces of programming documentation - "The C Programming Language" - By K&R, who most know also designed and developed the language itself.
Your ideas are no good if they can't be communicated to others. Often, inability to communicate good ideas is more an indicator the ideas aren't that good, than the documentation is lacking.
..don't panic
I once tried Inkscape and realized in disgust that the "manual" was a wiki.
When I was working in aerospace, we would often write the manual first, then implement. This forces developers to deal with ugly problems cleanly, rather than having some elaborate after-the-fact explanation of how to work around some limitation.
I've met quite a few coders who are disdainful of documentation, citing many of the reasons that coders give for being disdainful of comments. - It gets out of date quickly, there's a good chance it doesn't match the actual behavior, etc. "If I want to know what's going on, I have to read the code anyway, so what's the point?" There's also a very slight alpha-hacker subtext, with the philosophy of "if you can't read code, you're not worthy enough to be using this program in the first place". As well as the "works for me" viewpoint - the coder who wrote it doesn't need any documentation to understand it, so why is it necessary?
It's sometimes difficult to convince a coder that there are people out there who are competent, intelligent, successful people but who have no interest in plowing through 1000+ lines of code in order to find out which flag they should use to get .png output. To someone who gets a frisson of pleasure at deciphering a wall of obfuscated Perl, it's a foreign concept that there are people out there that have other things they'd rather be doing.
Former English and journalism majors, who are not always the best programmers but are very very good at explaining how a program works (or ought to work), should be inside every IT company and department on the planet. When I'm not monitoring servers (e.g. watching paint dry), which is my formal job description, I'm writing down everything from internal business processes to how-to installation guides on software for specific networks. My happy place is about fifty pages deep in a Word file.
Occasionally living proof of the Ballmer peak.