The other day an old co-worker from my days at Microsoft on the Oslo/M/Quadrant projects, asked if a college friend could pick my brain on being a content developer in advance of his upcoming interview at Microsoft for that role. I wrote back a lengthy reply (because it's fun for me to think about such things), and in the spirit of Scott Hanselman's Keys Left pricinple, I'm sharing all of that here.

To respond to the young man's question, I asked myself, what would I be looking for if I interviewed someone for the job? I had to admit that I've been through only one content-specific interview myself. It was just a couple of hours because I already had such a strong reputation. The interview was really more about getting to know people I’d be working with.

First, let me explain how I see the role of "content developer" vs. "programming writer." I personally like the idea of “content developer” much more because it opens itself to many kinds of content that aren’t just about writing: code, videos, presentations at conferences, improving answers on StackOverflow, etc.

I’ve seen too many people with the title of “writer” get stuck in the mindset that their job is to put words on a page, and that they measure success by how many words they write. A content developer, on the other hand, measures success in terms of effectiveness of communication—does the content I’ve produced help developers get to the needed information and answers quickly? And does it answer the questions they actually have, including one they’ve not identified yet because they’re still learning a technology?

Thinking this way, content development is an ongoing process just like software development. And just as with software, sometimes the right answer in that development is to cull, prune, and even wholesale delete large amounts of previous work because they’re obsolete, unhelpful, or otherwise don’t have much value.

Side note: It’s worth thinking about what this means in terms of metrics collected for content. Traditionally, people have worried about page views and time spent on page, but for developers, this doesn’t necessarily make sense. For developer documentation, the real question is whether they found their answer quickly, which means time spent on page is actually irrelevant. (That measure is really applicable only to sites that have on-page advertising, because more time means they can charge more for that advertising space!)

Next, I looked through the job listing itself (on the Microsoft Careers site) to see what skills it identifies for the role. Here are my thoughts on those:

  • “Enable the creation of amazing apps, innovative services, and creative experiences through the education of the developer ecosystem.” This tells you that the role is very much about education, not performance as an code-monkey. It’s about the ability to effectively and clearly communicate, so be prepared to demonstrate where you’ve had success in this way.
  • “It will be your job to learn about Microsoft platforms and technologies in order to teach devs…” I like to say that this role is all about suffering as much as possible in order to save many other developers from suffering. That is, I like to go through pain and anguish to figure out some difficult task because within Microsoft you have the luxury of then going to the engineering teams that create the stuff itself. Nobody on the outside—that is, the customers your serving—have this luxury. So you’re the bridge to take what they know and present it in a way that external people can most effectively utilize. A specific implication of this is that although engineering teams can afford to think in the silo of their particular domain (such as touch input), a content developer has to meaningfully relate those specifics to a much broader picture, such as “gaming apps” that happen to use touch input…and a whole lot of other stuff! So be prepared to demonstrate any experiences you’ve had in being that kind of a bridge, of taking specific details and putting them in a broader context.
  • “This role leverages your passion for teaching, writing, and coding.” And in that order! So be prepared to demonstrate that passion. I will add that one of the most important qualities to demonstrate—something I would certainly look for in a candidate—is empathy. You cannot be an effective teacher or writer if you don’t understand the people you’re trying to educate or communicate with. So how do you go about understanding that audience? Think about that and be ready to talk about it, and if people don’t bring up matters of empathy or knowing your customer, bring it into the conversation yourself. I, for one, like to go to developer conferences for this purpose. I also like to read other blogs, monitor questions on forums (and answer a lot of them!). And when I’m writing, I try to keep part of my awareness separate so it can immediately respond to my work as if I was an outside reader. In that way I’ve been able to anticipate questions that someone might have, and then answer them right away.
  • In fact, a short time later the description says, “You’ll walk in the shoes of your customers…” This is what empathy is all about!
  • “You’ll start by diving into code and collaborating with people across engineering, design, and marketing to understand the end to end story.” Again, big picture thinking is part of the equation here, so demonstrate that you have the ability to collect a lot of specifics and abstract them into the big picture. And clearly, the ability to collaborate is very important. You need to be able to relate well and work with people who aren’t like you, but just as essential to the shared goals. Be prepared to give examples of anything you’ve done along these lines, e.g. working effectively in teams. As a new college grad you won’t be expected to have done too much of this, but even to understand the need is super-valuable.
  • “Deliver code samples and technical assistance”: this is where the rubber meets the road, because in the end it is about delivering content. Be prepared to talk through how you’ve managed your own projects and assignments—how you’ve organized tasks, kept yourself to a schedule, and checked for quality.
  • “Engaging deeply with the community”: again, this is super-important for developing empathy.
  • “Excellent writing skills”: Do you know what the big secret is about writing? That it’s 80% editing. It’s one thing to put your thoughts down on a page. It’s another skill entirely to go through it several more time to make it better and better. If I were conducting an interview I’d actually quiz people on this, i.e. give them a piece of writing and have them think through how to improve it. I’d spend more time on this than I would on code, although I’d probably do the same thing with code (more on this in a moment).
  • “Graphics background a plus”: This isn’t so much about being a graphic designer as it is about the ability to express concepts through diagrams and illustrations. Take a look at the latest MSDN magazine article of mine for some examples. Or for a much bigger piece of work, download my free ebook Programming Windows Store Apps with HTML, CSS, and JavaScript, 2nd Edition. I did all the illustrations and graphics for that one myself—what’s in the book is straight from my files.
  • It’s not mentioned in the job description, but if you’ve done any video production and editing, showing those projects would be a big plus. Take a look at the One Dev Minute video series ( These are really working to communicate as efficiently as possible—they have lots of studio and graphics support, but if you have anything to show that approaches thoughtful editing in the video space, that would certainly be a plus.

Now for a few other thoughts:

  • Don’t worry about tooling—you'll learn on the job in a matter of days. At best, familiarity with some industry standards like Markdown might help, but really, you’ll get all the specifics in the process of the job.
  • The ability to do on-the-spot coding exercises as is traditional with software development interviews is not all that important to content development. In content, your job is much more about using code as a means for explaining concepts, techniques, and so forth. It’s part of documentation. I would want to make sure a candidate could write good, clean, and well-documented code, especially where the commenting explains the bigger picture of how all the code works and how it might relate to code that uses it. In other words, being able to explain why you chose to do something the way you did is often more important than the simple how or what.
  • In fact, what I would potentially ask a candidate is to show me an application project they’ve worked on, walk me through what it does, give me an architectural overview, illustrate the relationships between the key pieces, and explain what pieces could be most useful to other developers writing similar applications, and what parts are more specific to the project itself.
  • Let me return to the question of editing. There are two main things you to consider, and perhaps also practice instead of trying to solve coding problems.


    • I highly recommend spending time with the existing content produced by the team you’re be interviewing with. For example, if someone was interviewing for the team I'm currently in, I'd want them to go through the topics on MSDN under Cross-Platform Development. Reviewing that material would familiarize you with the technical areas that my team's involved with, but more importantly, pick a few topics that you understand pretty well already and ask: how would I improve this content? And overall, could you think of ways to improve the whole table of contents? Does the ordering of Getting Started material make sense to you? If you were just starting out, would you find this content engaging and effective, or are there changes that might improve it. These are things that writers and content developers should have opinions about.
    • If I were doing an interview, instead of having you write code from scratch, I’d show you a few pieces of code and ask how you would improve them to make them more useful as samples or as documentation? (Samples are documentation.) I’ve seen plenty of crappy samples in my time, and could explain to you exactly why they are crappy as a sample (even if they are good code from an engineering standpoint). To that end, find some samples that are relevant to the team you're interested in (including ones they've produced), and study them. Do you think these are good samples? What about them works well as educational material? What about them can be improved and how would you make those improvements? It would probably be helpful to spend more time with one of the samples to the point where you can give an on-the-spot tutorial about how it all works, as I suggested above.


In the end, I think content development is a pretty cool career path. You get to be deeply involved in technology, but you don't get so buried in the details of creating it that you lose sight of how it relates to everything else. I, for one, thrive on seeing, understanding, and communicating those relationships, and enjoy serving other developers in this way. In fact, I'm more delighted with a clear, well-written explanation or a clear illustration about how a piece of code works than I am about getting that piece of code to work in the first place. That's why I've always gravitated to content and community work.

If you feel the same way, this is definitely a career path to consider, especially as content is increasingly seen today as one of the keys to technology adoption, which is especially important with startups and innovators.

It's been a few years since I've taken the time to write a fuller essay for my site, but I'm delighted to offer a new one. Comments are welcome with this post as I don't have comments enabled for the articles themselves.

The California Drought: A Problem of Consciousness? – A defense of my claim that "all problems in the world are ultimately problems of consciousness." It's easy to see this truth in matters of human interactions, but is it also true with impersonal factors like the weather and other natural events? And it ths claim defensible without resorting to metaphysical explanations? It is, because what makes such things a problem in the first place is that humans happen to be in the way of such events, and that placement is subject to human choice and thus a matter of consciousness. The very act of classifying a natural event as a problem in the first place is also itself an act of consciousness, because we could just as well classify such things as opportunities. September 2015

Similar to my previous post, but perhaps not quite as fun, is an account from Fighter: The True Story of the Battle of Britain, by Len Deighton, which I just finished.

Any comparison of the Merlin engine [as used in the RAF Spitfire and Hurricanes] and the Daimler-Benz DB 601A [as used in Messerschmidt Bf109’s] must begin by mentioning the latter’s fuel-injection system. …

Fuel injection, which puts a measured amount of fuel into each cylinder according to temperature and engine speed, etc., was demonstrably superior to the carburetors that the Merlins used. Carburetors are, at best, subject to the changes of temperature that air combat inevitably brings. At worst they bring a risk of freezing or catching fire. And with such large, high-performance engines, the carburetor system seldom delivers exactly the same amount of fuel simultaneously to each cylinder. Worst of all, the carburetor was subject to the centrifugal effect, so that it starved, and missed a beat or two, as it went into a dive.

The RAF pilots learned how to half-roll before diving, so that fuel from the carburetor was thrown into the engine instead of out of it, but in battle this could be a dangerous time-wasting necessity.

Engineers–those on trains–in the 1800s got a good start in the art of hacking. This is from The Story of American Railroads, a thoroughly well-written and entertaining book by Stewart H. Holbrook written in the 1940s that provides many quotable passages:

Although neither the Santa Fe [railroad] or most of the other roads were in a hurry to adopt new inventions, the Santa Fe held in high esteem a gadget known as a Dutch clock. This device, perhaps the most unpopular one with railroad men of the day, was set up in the caboose and it noted and recorded on a tape the speed at which the train traveled. The rule was that freights should maintain a speed of eighteen miles an hour, no more, no less. The Dutch clock soon brought reprimands to all freight conductors who tried to make up time for the breakdowns of equipment that were forever happening.

After considerable discussion of the Dutch clock, the boys figured out a method of handling the menace. On the first sidetrack out of the terminal, the crew would uncouple the caboose, then uncouple the engine, bring it back to the rear on the main line, set it in behind the caboose, then use it to slam the caboose into the standing train at a speed of exactly 18 miles an hour. This, it had been discovered, so affected the Dutch clock’s insides that thereafter it continued to clock 18 miles an hour regardless of the speed developed. This fixing the Dutch clock was considered fine sport, and always left the train crew with a sense of immoderate satisfaction.

I was following a thread recently where a dev was trying to track down an app crash. In this case he had a window.onerror handler set up but it wasn’t being called.

The bottom line in the thread was that if any exception is thrown within the context of a WinJS.Application event, such as onactivated, then it will be picked up only by a WinJS.Application.onerror handler and not window.onerror. On the other hand, exceptions that are thrown in any other function context, e.g. the callback to a setTimeout or a button click handler, will be picked up by window.onerror as well as by WinJS.Application.onerror, which wraps window.onerror.

Consider the following bit of code in an otherwise blank app project:

(function () {
var app = WinJS.Application;

app.onactivated = function (args) {
throw (“Error from on activated”);

    app.onerror = function (e) {
        console.log(“WinJS.Application.onerror e = “ + e.detail.errorMessage);

    window.onerror = function (e) {
console.log(“window.onerror e = “ + e)


    throw (“Error outside of WinJS.Application.”);

Running this code, Visual Studio will call out the exception from the last throw. Pressing Continue you’ll get to window.onerror, followed by app.onerror. You’ll then get into app.onactivated, where that thrown exception will then take you to app.onerror but not window.onerror.

Background tasks, though they are essentially extensions of a app, only have limited capabilities where using the WinRT APIs are concerned. They can access the app’s appdata folders and settings, for example, and perform file I/O with Windows.Storage APIs. No problem there. Background tasks cannot, however, generate UI with the exception of issuing toast notifications and tile update.

Background tasks are also able to perform string lookups in resource files using the Windows.ApplicationModel.Resources.ResourceLoader class or Windows.ApplicationModel.Resources.Core.ResourceManager.current, meaning that they do have access to the app’s localized content.

One issue that comes up with background tasks written in JavaScript is that the task itself, which runs as a web worker, cannot employ the WinJS library. As a result, a JavaScript background task cannot access resources through WinJS.Resources.getString, and occasionally this leads developers to think that background tasks cannot access resources at all. But because this particular WinJS API is implemented with the WinRT APIs, you can just use the latter directly.