|
|
|
|
|
Google Ads
|
|
|
|
Technorati
|
|
|
|
Feed
Subscribe to the
feed for this blog.
See this post
for info on full versus truncated feeds.
|
|
|
|
Quote
I feel like being wrong is really important to doing decent work. To do any kind of creative work well, you have to run at stuff knowing that it's usually going to fail. You have to take that into account and you have to make peace with it. We spend a lot of money and time on stuff that goes nowhere.
— Ira Glass
[ view all quotations ]
|
|
|
|
Navigation
[ home ]
|
|
|
|
25 Most-Visited Entries
|
|
|
|
Categories
aspnet
blog
books
editing
family
funny
general
history
house
language
movies
music
personal
politics
readings
roundup
seattle
teaching
technology
travel
whidbey
work
writing
|
|
|
|
Blogs I Read
|
|
|
|
Contact
Email me
|
|
|
|
Blog Statistics
Dates
First entry - 6/27/2003
Most recent entry - 8/26/2010
Totals
Posts - 2109
Comments -
Hits - 1,140,239
Averages
Entries/day - 0.80
Comments/entry -
Hits/day - 434
Update every 30 minutes. Last: 2:25 PM Pacific
|
|
|
posted at
05:52 PM
|
trackback
|
|
link
 A diversion. As I will touch on later, there's a difference between a person who can write and a person whose job is writing. A programmer who writes the occasional blog entry is not (yet) a technical writer, who in contrast spends week after week documenting not just the interesting and cool things that are fun to write about, but also the seemingly endless APIs, the unsexy readme files, the installation instructions, and all the other stuff that users need, and who do this on relentless schedules. (As people sometimes say, "that's why they call it work").
Ok, writing. How do you assess writing skills, and specifically technical writing? If anyone's developed a foolproof way, I haven't heard of it.
What about writing samples? A good start, and indeed, a necessary condition, but not a sufficient one. It's hard to imagine a candidate with no writing samples at all getting far in the process. On the other hand, impressive writing samples are always nice, but it's never clear how much of the work actually is the candidate's and how much was contributed by (for example) editorial review. In this regard, blog entries are (IMO) actually good writing samples. If a good blog is added to a sample that shows experience writing API docs, I definitely sit up and take notice. (FWIW, I haven't seen this a lot.) A writing sample can also become an interesting point of drilldown, as I'll explain in a minute.
Writing test? This idea has always been bandied about (you'd never hire an editor without an editing test), but it's never really come to fruition, at least that I've seen. Decades ago I used to administer a writing test that consisted of listing a handful of SQL-like statements and the resulting output and asking the candidate to sketch out the documentation for this "language." However, that's a pretty intensive effort that we don't have the time for in our brisk process. (We might also have some constraints associated with having to administer the same test the same way each time, but I'm not sure about that.)
So we do a lot of our assessment via questions. If I indeed have the charter to investigate the candidate's writing skills (I don't always), during the interview, I ask some questions that are fairly broad, along these lines.- I see that you did some writing for [Product X]. What does that product do? (I just pick something off their resume.) To me this is a pretty simple test for writing ability. Can you describe something to me that I don't know about? Did you bother to establish what I might already know about it? Can you tune your description to my knowledge and interest? Like that.
- You're given a 1.0 product to work on, and six weeks to do it. What do you do? Here I'm looking for thoughts on how to plan, how to prioritize, how to use available resources creatively, what to produce, whether they consider non-writing avenues (e.g. video), how to think beyond the next deadline, maybe how to negotiate with other teams, etc. If they've been in the business for a while, they've faced this one, so I'm all ears about how it went and maybe what they learned.
- What's your experience with editors? Tell me about a time when you and the editor disagreed about something. Obviously, I am leery of people who either have not been edited or who are grumbly about editing. (To be fair, I know writers who are justified in their skepticism about technical editors. Still, a response like "My editor was an idiot, so I just ignored them" is, as you can imagine, not encouraging.)
- How do you know if you've succeeded? I'm looking for some insights into things like getting reviews, checking customer feedback (or otherwise interacting with customers) — whatever they might think of. This might also tell me something about whether the writer is actively interested in doing a good job or has a "it's published, I'm done" attitude.
- What skills do you think make a good technical writer? If "good grammar and spelling" seems to be a focus, I start to have my doubts.
- What's the best kind of documentation? The winner here is "the best doc is doc that's not needed," but I'm interested to hear whether they've thought about the purpose of documentation, how it's used, by whom, etc. For our context, I also like to hear about code samples and other programmer-centric thinking.
- If you could do any job tomorrow, what would it be? This seems like a transparent snare, but an open tech-writer position can attract people who think they might want to look into this writing business because they're tired of what they're doing and hey, they wrote a whitepaper once and that was fun.[1]
If I have a decent writing sample, I might also ask some specifics about the sample -- what was the thinking, why this approach, what were some of the issues, how was it received, etc. I also hope to get some sense of whether they were using a style guide/sheet and had a formal editing and publishing process. I'll also ask what tools they've used, not because I care specifically about those tools, but because I am interested if they've worked in a professional environment and how they feel about that.
If they've provided multiple samples, I might ask which is their favorite and why. What I'm hoping to elicit here is some enthusiasm and pride for their work.
Hmm. I see that these are questions about writing skills in a very broad definition. But that's what we're after.
There's a million more questions (I have a 6-page document full of them), but the specifics aren't really that important. The important point is that what I probe for is to determine whether the person sitting across from me is, in fact, a writer. As Chris Sells once said, "Don't prepare. Be yourself. If you're not a fit for MS, no amount of preparation in the days before an interview will help." (Read his whole interview.)
There are times when it's obvious, either pro or con. There are other times when it's just not clear. (An odd case that I've learned to trust is the person who seems to be -- in fact, is -- a good writer but is not driven to it compulsively, and would not write except as a job.)
I know from experience that it's quite a bit harder to find a really good programmer/writer than I would have imagined in my younger days. As you might expect (?), I've worked with folks where the programming skills definitely were the stronger half of the binomial. That, I suppose, is where my job comes into it. :-)
[categories]
work, writing
|
posted at
08:22 AM
|
trackback
|
|
link
Friend P doesn't know Paradox, so he called me. I don't know the product either, but I did offer to help find someone. I forwarded Friend P's inquiry to about a dozen people who I thought might either have PC history that goes that far back or who know databases. About two hours later someone replied who had indeed worked with Paradox long ago, and I hooked him up with Friend P.
 Frankly, I was not entirely surprised. Naturally, I was not surprised when most of the people I contacted responded with "Nope, not me!" (altho people did remember the software, so I knew my selection of recipients was not too far off). But I was also not that surprised that someone I kind of know proved to be the right contact.
The famous "six degrees of separation" comes from an experiment that was done in the late 1960s in which the experimenter asked people to get a packet to a person in a distant city. The idea was that you could hand the letter to someone who might know someone who ... and so on. There were some surprises that came out of the experiment; the most well-known was how short the chain was from the original sender to the recipient. Nowadays -- and very much as a result of this experiment -- we kind of understand this, but before this trial, people thought that it would take many, many more people to connect you to some remote stranger. As it turned out, on average it took between 5 and 6 intermediaries to reach the ultimate recipient.
Thus the power of social networks. What my recent experience underscored, however, was that a lot of the power of social networks comes via the "weak ties" between people. Malcolm Gladwell (from whom I crib most of this info) recounts a study that looked at how social networks work when you're looking for a job:[A]lmost fifty-six per cent of those he talked to had found their jobs through a personal connection [...] This much is not surprising: the best way to get in the door is through a personal contact. But the majority of those personal connections did not involve close friends. They were what he called "weak ties." Of those who used a contact to find a job, for example, only 16.7 per cent saw that contact "often," as they would have if the contact had been a good friend; 55.6 per cent saw their contact only "occasionally"; and 27.8 per cent saw the contact "rarely." People were getting their jobs not through their friends but through acquaintances. In some senses, the weakness of the tie is actually a critical factor in leveraging a social network:[W]hen it comes to finding out about new jobs -- or, for that matter, gaining new information, or looking for new ideas[1] -- weak ties tend to be more important than strong ties. Your friends, after all, occupy the same world that you do. They work with you, or live near you, and go to the same churches, schools, or parties. How much, then, do they know that you don't know? Mere acquaintances, on the other hand, are much more likely to know something that you don't. When Friend P contacted me, he had already inquired without success among people in his immediate work circle, so he threw a line over to my network. When I got his request, I didn't just ask the people who have offices on either side of me; I sent his request to people I worked with years or even decades ago, or in some cases, to people I have never even met in person. My acquaintance with some of the people on the list is pretty slim ("we worked together once" or "a guy whose blog I read") -- some of those ties are pretty dang weak. But it worked, and as I say, I wasn't hugely surprised.
Think about this with respect to Facebook, say, or Linked in (whose slogan is "Relationships matter"). If all you ever wanted to do was talk to your immediate social circle or consult with your professional colleagues down the hall, there would be no need for a social-networking site. The premise of these sites is not that my bestest buddy can contact me, but that the network can capture people to whom I have weak ties. The sites expose chains of mutual acquaintance that result in friends (well, "friends") and professional contacts. (See also this great video explanation of social networks.)
There's lots more to social networks (another interesting outcome of the original study was in identifying "hub people"), but situation after situation reinforces the idea that we're just a few contacts away from a lot of other people. Next time you're looking for a job (or a date), let your social network, and the network it belongs to, help you out.
[categories]
general, work
|
Wednesday, 12 September 2007
|
Roundup
posted at
09:05 AM
|
trackback
|
|
link
The Tech Battle in Seattle. On the O'Reilly blog, Brady Forrest shows a map of Seattle that indicates where various tech companies -- Microsoft, Google, Yahoo, and Amazon among them -- are expanding their Seattle-area operations. This is good for jobs. Probably bad for traffic.[1] Bad (or good, depending on your POV) for real estate prices.
How to optimize your power strip. I've done some of this (esp w/r/t the UPS) and can recommend it.
Lawyers are always bad PR. Charles Miller has a cautionary tale: "What started as the opinion of a small number of commenters on a medium-traffic Australian forum site is now a portrait of a corporate bully trying to silence critics, splashed over the entire Internet."
The 7 Top employee bungles using Office. Philip Su recounts some of the ways in which Microsoft people have screwed up when using Office. As for #6, a guy I used to work with acquired the nickname "Hotstuff" after he received a, um, personal IM from his wife ... while presenting to the entire product unit.
[categories]
roundup, seattle, work, funny
|
Thursday, 5 April 2007
|
Meeting in Building 7
posted at
04:41 PM
|
trackback
|
|
link
But the construction boom at MS has by no means ended, and among the plans for new construction was a building that tentatively named Building 7. Ah, the end of the era.
But! Today in the corporate newsletter they had an interview with the chief of facilities. They asked him about the decision to build Building 7. He said that they'd gotten "a lot of feedback saying 'please don't use Building 7,' so we aren't going to use Building 7 as the official name. [...] Interns need not worry; they will still have their missions to go on."
Who says corporations don't have a sense of humor?
[categories]
work
|
Saturday, 16 December 2006
|
Windstorm
posted at
11:53 PM
|
trackback
|
|
link
Here's a picture I took in my neighborhood.
Update 17 Dec 06 3:30p AFAIK, power is still out to a significant part of the MS campus, including the building that houses the servers that are of interest to my group. I couldn't be working even if I wanted to be. Which is just as well, because my main machine at home turned up dead -- at the moment, I'm guessing a bad power supply, but we'll see. Sheesh, what a mess.
[categories]
seattle, work
|
Wednesday, 13 December 2006
|
Roundup
posted at
11:09 AM
|
trackback
|
|
link
GPS dog collar. Where the heck did that dog go? Here, let me check my mobile phone.
Programmer's Heaven C# School Book. Another free eBook that's an intro to C#. I think that this one contains a particularly clear description of delegates, fwiw. [via The Daily Grind]
Smashing the Clock. "No schedules. No mandatory meetings. Inside Best Buy's radical reshaping of the workplace." Meet ROWE: Results-Oriented Work Environment.
U. scientist makes computing breakthrough. "The technicalities are complex, but the outcome is that if the 'spin' of atoms in a quantum computer could be read, a computer using 64 quantum bits in its calculations would be '2 to the 64th power faster, or about 18 billion billion times faster' than a 64-bit computer of today, the U. noted in a press release. 'Note: billion billion is correct,' the release adds in parentheses."
Holiday Party Excuse Generator. "Answer a few simple questions, and in the time it takes to warble 'Fa la la la la', you'll have an excuse that will either endear or enrage a prospective host." Nice Flash-y stuff. [via Away with Words]
Solio. Solar-powered charger: "Solio is your one stop charging solution for all of your products from cell phones and iPods, to digital cameras, game players, GPS and even Fish finders! One hour of sun will give you enough juice to play your iPod™ for about an hour." I don't know nuthin' about it, but it sounds cool. [via ideal bite]
[categories]
roundup, technology, work, funny
|
posted at
10:20 AM
|
trackback
|
|
link
Yesterday Scott Guthrie posted an entry on his blog making an announcement that the product code-named "Atlas" has now got an official name. Actually, three names, because the product is in three pieces: Microsoft AJAX Library, ASP.NET 2.0 AJAX Extensions, and the ASP.NET AJAX Control Toolkit.
Turns out that people can have very strong opinions about names and code names. Here are comments from the blog that opine on this name change:I'm going to keep calling it Atlas (for a while anyway), it's much cooler ;-)
[...]
I really like the name Microsoft AJAX Library. However, I think “ASP.NET 2.0 AJAX Extensions” is a mouth full to say. Any recommendation for a short name? Also, will the official site still be http://atlas.asp.net/?
Scott: ASP.NET 2.0 AJAX Extensions is indeed a bit of a mouthful. Overtime all of this will just be built-in to the core ASP.NET setup. So I suspect a lot of people will just use "ASP.NET" to describe it all.
[...]
The word 'Atlas' has 2 syllables, 'ASP.NET 2.0 AJAX Extensions' has 12 syllable’s. I wonder if Microsoft is doing itself a disfavor by doing all these renames late in the development cycle. Are there really more pros than cons that defend the name changes? Who is the target audience that will benefit from it (I'm not sure how I will benefit)? The word 'Atlas' is very easy to pronounce, visually recognize, and it's particularly useful when searching help, internet, and blogs (e.g. "Atlas UpdatePanel" or "Atlas cascading dropdown"). This last part also implies that 'Atlas' is easy to use for those who contribute searchable content (i.e. people like Scott Guthrie :-)). A quick search reveals that you (Scott) have over 50 articles with the word 'Atlas' in the header. Anyway, I guess it's not a big deal, but sometimes you wonder if these renames really are beneficial. It certainly has caught my attention...
[...]
In the end the name was surprisingly acceptable IMHO. I was hoping it didn't get named in the lines Foundation or Framework. I think ASP.NET developers will refer to it as "the AJAX extensions" or "the AJAX library" interchangeably because all three modules are likely to be used together in a large part of the applications. Looking forward to 1.0 !
[...]
Why not keep the Atlas name? If its going to be a part of ASP.NET anyways, why bother?
[...]
Hi Scott, Great decision. Like any renaming attempt, you will get many people objecting to the change and stating that Atlas was cooler (it probably was). But the point is that anyone who hears the new name will instantly know what the technology does without any further explanation. This is a good decision.
[...]
Hi Scott, My feeling is that the name Microsoft AJAX Library is completely wrong for the client side library. Many of us have developed a lot around the client side library and all the features of the library can hardly be described by "ajax" (hey, UpdatePanel wasn't always what it is today). The name itself makes it seems that Microsoft is dying to get on the ajax bandwagon all the while it has been at the forefront. Ignoring all and sticking to the facts AJAX is the wrong name since Atlas uses JSON rather than XML =)
[...]
Shucks, I'm going to miss the Atlas name.
Scott: You can still affectionally call it "Atlas" and people will know what you mean. :-)
[...]
Why not Microsoft AJAX Library for ASP.NET 2005? *Rolls eyes* Has anything changed? Will it ever? It's boggling to me that MS gets alot of recognition from codenames... then they throw all that recognition away. Was there anything preventing 'Atlas' from being the actual name? Product naming does not have to functionally describe the product. (Kudos to the Vista name.)
[...]
You passed on an opportunity to expand the "Microsoft Windows Live" and "Windows ____ Foundation" brands? Well done, sir!
[...]
News at 7: The fears were founded today when Microsoft took a perfectly good product name, gave it to marketing, and came up with a very lame replacement. Typical Microsoft.
[...]
It will always be 'atlas' to me :)
[...]
Do all the developers just die a little more inside everytime the naming police get done beating the ever living passion and life out any semi-cool sounding project name? Seriously, you guys do some awesome work but your ability to name anything *sucks*. Please for the love of humanity do NOT even attempt to name your children without outside help.
[...]
Great naming couldn’t be straighter forward and so précis.
[categories]
aspnet, language, work
|
Thursday, 17 August 2006
|
On the naming of products
posted at
12:19 PM
|
trackback
|
|
link
Update Perusing Jeff Atwood's Vertigo blog, I see that he's addressed this question also, and includes links to lists of Microsoft and Apple project code names.
Groups with continuity in their development effort often use themed code names. Around here we worked on "Everett" (Visual Studio 2003) and "Whidbey" (Visual Studio 2005). Next up is "Orcas" (Visual Studio Next) and "Hawaii" (Visual Studio After-Next). The play here is on the geography of Western Washington State and beyond. ("Everett" came about as being "on the road to Whidbey.")
The ASP.NET team likes to use planetary allusions for its projects. Web Matrix was originally "Saturn." The little Web server that shipped with Web Matrix was "Cassini" (a spacecraft orbiting Saturn). Visual Web Developer was code-named "Venus." The ASP.NET AJAX stuff is "Atlas," which is a moon of Saturn, with the added benefit that it shares with AJAX a classical allusion. Now and again if you poke around in the APIs or in the .dlls, you'll still find references to some of these code names, although we're not supposed to bake those into code. (Incidentally, w/r/t Cassini, probably more people know it by this code name than by its official names which is ... do you know? "ASP.NET Development Server.")
Several jobs ago I worked at a now-defunct company that was at the time well funded. The received wisdom at that company was to use a code name based on where you wanted to go for the ship party. Vegas, anyone? Maybe that -- plus rarely shipping -- had something to do with that company's fortunes.
One problem for us is that we have to make about a million references to the product while we're creating the docs, which obviously can be a bit impractical if you don't actually know what the product is going to be called. These days we use tokens that can be replaced at build time with the product name. (Although it's not usually a worry, we cross our fingers that the final product name doesn't have some subtle grammatical difference from the token, e.g. one is singular and the other is plural.) But that doesn't work everyplace, so we're always eager to get the official name.
Toward the latter stages of product development, more and more queries work their way up the chain -- "Do we have an official name yet?", and rumors and nearly-final names will be flying about all over the place. We have to be careful to get the official sanctified name in writing (well, in email) before we assume we've got the real deal. In the midst of a flurry of rumors recently, someone who clearly has trade-show experience was heard to make this observation about the officialness of a product name: "It won't be final until they print it on 50,000 squishy balls."
[categories]
aspnet, work, language
|
Sunday, 6 August 2006
|
Fun technical writing
posted at
09:39 AM
|
trackback
|
|
link
Everyone knows that after legal documents and government publications, technical writing is about the driest kind of reading there is.[1] Who hasn't heard (perhaps said) "I read this stuff when I have insomnia!" And it's not exactly a challenge to find a piece of technical writing that isn't just boring, but outright incomprehensible, even to people who should know what it's talking about.
It's not as if technical writing can't have personality. Anyone who's dabbled in Ruby knows about why's (poignant) guide to Ruby and its famous cartoon foxes. In "a funny manual that works," Gordon Meyer recently noted that "it's very difficult to use humor effectively in technical documentation," but he calls out some examples by David Pogue and Bill Bumgarner where he thinks they've done the trick. I have my own favorites. As I've noted before, a book that had a big influence on me is John Muir's classic How to Keep Your Volkswagen Alive ... A Manual of Step by Step Instructions for the Compleat Idiot, which for all I know spawned the whole notion of "idiot's guide" documentation. A sample that I cite from my famously imperfect memory: "The slow progress that a Volksie bus makes in the mountains means just one thing: leave earlier." Although most people don't think of it as such, The Joy of Cooking is another technical manual that overflows with personality.[2]
So what's the deal? Why is most documentation so boring?
Well, let's have a think. Documentation starts with the disadvantage that it's stuff that no one wants to read in the first place. The best kind of documentation is the kind you don't need at all. Documentation is part of "Job 2," as they say; most people are using the docs (or software) to get something accomplished in their real job. Why is the documentation for a photocopy machine so frickin' useless? Because everyone thinks that using a Xerox machine should be as simple as pushing a button, and having to read something just to get a stupid copy ... well, you can imagine the frame of mind in which the user approaches the task of reading the docs.
Then there is the fact, sad but true, that not every writer can write with personality. The reason -- or one reason, anyway -- that there aren't a lot of funny technical manuals is that few people can write funny to begin with, and fewer still can be funny and know something technical to write about. (If you doubt this, try it: pick something that you know pretty well and write some funny documentation for it. I'm serious about this -- if you do, send me a sample and I'd be happy to talk to you about it and if you want, share it with others.) The notion of personality in docs encompasses more than just being funny, but I'll stand behind my assertion that it's harder than it looks to write accurate, useful docs that also have some of this personality stuff.
Everyone will point at blogs and say "See? There's some damn fine writing!" Yup. I read many of them myself. But blog writers do what they want when they want, and banging out docs rarely affords that luxury. It's hard to sustain that approachable blog tone when you're writing hundreds of topics to deadline.
As a side observation, I offer that documentation with humor is refreshing, but a little of that goes a long way. Even if it were possible to write all documentation that way, I suspect (or anyway, the writing profession at large maintains) that when it's crunch time for your project, it's all, like, enough with the laffs already.
There are other reasons why docs are comparatively bland. Most documentation (as opposed to books) is a team effort, and there's a general belief that a doc set from a company should have a uniform tone. This is an arguable point, and I won't argue it; in fact, the plethora of blogs and whitepapers suggests that people by and large don't care about uniformity. Until they do, such as in API docs, where jocular, personality-laden information tends to be a lot less welcome. Tell me the syntax already, would be one way to characterize API doc readers. (See "Xerox machine" above.)
One of our writers recently did a presentation on documentation for various open-source products. Ruby was one; PHP was another. He had various observations, but one I found interesting was that open-source documentation is often written in one language only. (Guess which.)
Our docs are localized into a minimum of 8 languages. (I can never remember the actual count. 8? 12? 27?) Consider the challenge of writing docs that will have the same personality in 8 languages. Does your humor translate? (No.) Do your examples cross cultural boundaries? Is the tone that American readers find engaging equally engaging to readers in Germany? Japan? Egypt? China?[3] How do people in those countries react to poignant foxes with a fondness for chunky bacon? Hard to predict, innit?
Localization therefore imposes some cultural constraints on how much personality we want to inject into the docs. It also imposes some purely technical constraints -- we use so-called machine-assisted translation, in which software does a kind of initial pass. To make this process as successful as possible, we follow certain guidelines, which call for consistent verbiage, unambiguous words and constructions, straightforward sentence structure, and reasonable sentence length.
These guidelines help translation and they help "ESL readers" -- readers for whom English is a second language. Turns out we have users in many more languages than those we localize to, or that some people just don't have access to the localized docs. But really, documentation that's written in a consistent, straightforward way actually benefits all readers. (Compare those legal and government docs again.)
I'm going to go out on a limb here and suggest that a lot of documentation is pretty well written and is perfectly fine to read, considering. It's clear; it's concise; it gives you the information you need with a minimum of fuss, especially when you don't have time for, or are not in the mood for, a little technical comedy. I won't make this claim for most documentation; the ratings we get from MSDN prevent me from making a blanket claim. But some of the docs get very good ratings, which is of course mostly that the information is great, but is at least partly for the reasons I cite. They're docs that present the smallest possible impediment between your problem and the solution.
So, where does that leave us? Does documentation need to have more personality? I'm all for that, as long as we can work within the constraints that I listed before. Does that mean docs have to be awful? Hardly. I've noted before that the Windows people have guidelines for the "Windows Vista Tone," which attempts to humanize the UI by being more conversational. If they can do it in the UI, we can do it in the docs.
What I think, though, is that we would not see some radical overhaul of the docs. I proposed to my writer that the difference between what he imagines as documentation with personality and some well-written existing documentation is not so great. By the time you've written docs with personality that can also be translated and are readable for ESL readers, you've got something that's probably not so far from a lot of the docs we have today.
I might be wrong; he was certainly not convinced. So it will be interesting to see what happens if or when the writers let their personalities loose in the doc set. Maybe we've got a bunch of David Pogues and John Muirs and chunky-bacon-loving foxes in our midst and we just don't know it.
[categories]
writing, editing, work
|
Thursday, 13 July 2006
|
MSDN changes
posted at
09:58 AM
|
trackback
|
|
link
The problem, however, is that MSDN can be ... hmmm, how to phrase this? ... a teeny bit unwieldy. Like, you know the docs you're looking for are there ... somewhere. And there are the occasional, you know, surprises. Did you know, for example, that all the ASP.NET 2.0 docs are not in www.msdn.com but actually in www.msdn2.com? This isn't so much a problem if you use, uh, certain search strategies to get at the docs, but let's face it, there are two libraries.
Welp, the MSDN folks are on the job. They posted a note recently on their home page advising readers about the existing of that whole 'nuther library. But more to the point, as they say, "In the coming months, the documentation hosted in both libraries will be consolidated into a single MSDN Library." Yay for that.
Managing a site as large as MSDN is quite a challenge, no doubt about it. We see it from both ends, as content providers to that site and, like everyone else, as users, so we're maybe even more eager than ordinary folks to see these improvements. :-)
PS Don't forget the MSDN Devwiki!
[categories]
aspnet, work
|
|
|
|
