There is a saying that if you are not part of the solution, you are part of the problem. I don’t know what that means. So I’ve chosen to ignore that basic message wrapped in an aphorism and focus on my mentalist powers: What do I see as the future of content publishing?
I’ve written before about how I see the role at my company. I’ve also been critical both here and in real life about some of the failures in this discipline. That is, I guess, my disclaimer.
The role of the content publisher will diminish at Microsoft. Simply put, there is less need for wordy content. There is greater bandwidth and a growing number of different forms of prescriptive content for users of software.
It bears stating that my view is on the developer side of the equation. In my early career, I worked directly with customers, regular people, who were using databases, spreadsheets and word processors. These were small business owners for the most part who were trying to computerize their businesses. They were solving straightforward problems with software, as opposed to writing code, and expertise was what they were looking for.
As time moved on, extensibility of tools and an increased market (more people using computers for whatever) created a need for tools for tool jockeys. More people created more complex ‘solutions’ and my job role, over time, moved from working directly with customers/end users, to providing big doc sets that described the nuts and bolts of a programming platform. This information was used, not by end users, but by customers who were themselves software creators.
Does that make sense? It was more of a business-to-business relationship. This is all well and good. In particular, COM was big and complex and needed a lot of documentation. These were the halcyon days of big doc sets. Plus, engineers who had moved from one discipline into the software development discipline were used to specs and manuals. But this ain’t a detailed history of the software documentation.
Fast-forward (nice way to skip a lot of stuff) to today. There is considerably less need to tell people about program flow “If statements, case statements” etc. and more need to tell them about how to get your Zune file on your daughter’s friend’s Ipod. (That’s just a joke – no one ever does that – I mean, a Zune file????)
So what is needed today? Today a content publisher needs to be more of an organizers and less of a writer. If you understand code well enough to write it, you’d be better off finding another place to ply that trade.
Indeed, there is downward pressure on salaries in the content publishing discipline. Contingent staff and vendors used to command salaries on par with full-timers. That is not true for the most part today.
There is even less of a need to read code in most jobs. For the most part, it is adequate at most companies to extract code comments using automation and running with them. Even if they are egregiously bad, or even contain questionable language, fixing an online doc set is much easier than sending everyone who subscribes to MSDN a bunch of new CDs. Young people can search for what a “CD” is.
A smart Seattle-born developer once described my job as “taking what he said and localizing it to English.” For me, that has never been more true.
Taking code comments and turning them into reference pages that we ship online is good ‘nuff. Doing it for less money is obviously in the best interest of the business. Going with the first draft is okay if you have an easy way to make fixes for egregious errors. Social networks can fill the gaps too.
This is the future of content publishing for developer content. A smaller set of people with good organizational skills and communication skills will produce automated doc sets that are easy to upgrade. Coordination around the “community” of users will be something to build. Outsourcing, when possible, will be a choice, so good business and negotiation skills will be a plus there. Again, you need good communication skills. Outsourcing will be both off-shore and on-shore so modularizing the needs of your team into easily workable units will be important.
And managing those projects will be important, so building up a good understanding of operations management and project management will be important too. Learn something about Agile and Lean.
I think you might actually be wrong, and it's not just you, it's Microsoft that's wrong.
Mobile devices have create - no, wait, re-created - the entire one-person developer company. Even at the height of the 1980's micro-computer boom, it was never like this. Programming is actually cool again, because it's not all PHP and SQL. And if anyone else says "I can program in HTML" I swear I'll punch them in the face.
Thanks to the re-emergence of this self-taught, full-of-energy-and-ideas developer class, we need good documentation more than ever. Proof? Go look in a book shop (if it hasn't closed down). There are now more books on programming than at any time I can ever remember. Not "how to use a computer" books, but books that actually have source code in them.
I would say there are more programmers looking for more information than ever before. We need information on SDK APIs, and we need good quality, safe, reliable, re-usable sample code. We need documentation with friction' code samples in them (not even Amazing Apple puts code samples in their docs).
So I would disagree with you, and say that there is a huge need for technical programmer writers: you're just not looking in the right place.
Maybe you are wrong as well :) ...
Programming has always been cool. Maybe what you describe as uncool programming is typical enterprise software development, which still may be cool or may be not. Topics such as artificial intelligence, robotics, information visualisation, natural language processing, game programming, audio programming were always cool ;)
Since the recent proof on CSS3's touring completeness you might actually say, that programming in HTML IS actually programming.
Furthermore, the trend you describe with mobile devices is actually almost gone for the individual developer. I doubt that there is still THE gold rush possibility as it was some 2 years ago. Unless you, as a developer, are excellent at many areas (programming, marketing, polishing, documenting, designing), I doubt you will make a living from your mobile application endevours. While I do not say that it is possible, I doubt that it is a model for the mainstream developer. Blockbusters such as Angry Birds or Plants vs. Zombies were not created by one indidivual. While you may come up with a great app idea, the constraints imposed by ecosystem guardians and end-user expectations, may force you to deliver a very polished product. However, the new devices gave rise to new enterprises like NGMoco etc.
Now, while virtual markets reduce some tedious tasks on the developer side, they re-live the same problems real markets face, i.e. finding your application within 1000000 apps, identifying the gems and trusting the million of reviews, establishing a reference price, communicating value.
While I don't know whether there is less need on content. I suppose that:
1. the blogosphere generates a massive amount of content
2. program documentation can and will be generated automatically from alternate represenations, like source code
3. market dynamics will lead to concentration, with less variation there will be less different content
4. the crowdsourcing phenomenon will be leveraged even stronger to reduce initial documentation efforts by offloading work to the community and giving a sense of participation and peer recognition in return
Just some time ago, I was thinking about when will we see the first public libraries disappear for virtual libraries (virtual books, virtual lending), when will start noticing the remaining few public libraries and the last remaining library workers ?
Full-time content publishers now compete with virtually everyone who writes or uses software; I don't know any engineer who hasn't posted a question or solution to a forum/blog/Wiki/eieio. I know many software engineers who have contributed "content" in the form of code or commentary to an open source project. However, these contributions were not necessarily well organized, accessible, comprehensible, or even useful. Regardless of how its packaged and distributed, well written content still has value and, therefore, talented content publishers are still relevant. Whether corporations feel that the public's contributions to the largest content mill, the Internet, constitute a viable replacement for content publishers is the salient question.
I'm not sure I see what people are disagreeing with. Yes. I am looking mostly at my microclimate and things might be different elsewhere Let me enumerate my points in what I consider to be a non-defensive, fact-based way.
I'm mostly talking about so-called developer docs, not end user docs. However, some of the facts are the same.
I'm not saying the amount of developer content will diminish, but I am saying it will come from other, cheaper places. In fact, it never seems to diminish because it never goes away. I still work on MAPI and recently wrote about using NetMon with Office. I worked on that Netmon in 1995.
References will continue to exist, but will be brief and produced through automation - which is a contrast to the past when this was not possible or favored. Long remarks in a Foo::GetBar method are just not needed.
The "need" for documentation is hard to measure and leads to no specific way to put a "value" on it. No one pays for any downloads or views. But the value of the content as measured by what the producers get paid to produce it is diminishing in dollars. Documentation, perhaps bad, is being produced by a workforce that is more a combination of outsourcing to vendors, off-shoring to less expensive areas, and robots (otherwise known as automation but I've been reading Isaac Asimov lately).
Finally, the skills of the so-called programmer writer must change. This is not bad or good. I'm not judging it. I'm stating it as a fact. I write less and tool-jockey more. I lead teams and create statements of work to give to vendors who then give back stuff that I publish through a mastery (or stumbling imitation of mastery) of tools, process and co-ordination. That set of skills is not completely foreign to the industry. In fact, they are common skills. But they are different skills than those that made me a desirable hire, you know, back in the day.
I don't disagree with your points :) In fact, I assume that you are an insider with a viable point. Also, there is lots of work, already visible in the OSS space, which seeks to weave usage-oriented documentation into the programming environment.
One trivial example is the more intelligent intellisense in VS, i.e. one that does not strictly need character-by-character correctness to identify your search for a particular API function. Another non-trivial example, is "intelligent code snippets", i.e. depending on the actual development need that you have, a series of API calls is layed out for you to satisfy your needs. By that I do not mean, that you as a developer look into the available repository of code snippets, and select one that fits your needs, but that your IDE is smart enough to make guesses about what you intent to achieve with code you already wrote. Environments like these will obviate some of the need for rudimentary documentation.
However, I do agree that non-trivial documentation will always be needed, and the writing of such will still be an art for some time to come.