MDN Product Talk: The Case for Experiments

This is the third post in a series that is leading up to a roadmap of sorts — a set of experiments I will recommend to help MDN both deepen and widen its service to web developers.

The first post in the series introduced MDN as a product ecosystem. The second post in the series explained the strategic context for MDN’s product work. In this post I will explain how an experimental approach can help us going forward, and I’ll talk about the two very different kinds of experiments we’re undertaking in 2015.

In the context of product development, “experiments” is shorthand for market-validated learning — a product discovery and optimization activity advocated by practitioners of lean product development and many others. Product development teams run experiments by testing hypotheses against reality. The primary benefit of this methodology is eliminating wasted effort by building things that people demonstrably want.

Now my method, though hard to practise, is easy to explain; and it is this. I propose to establish progressive stages of certainty.

-Francis Bacon (introducing the scientific method in Novum Organum)

Product experiments all…

  • have a hypothesis
  • test the hypothesis by exposing it to reality (in other words, introducing it to the market)
  • deliver some insight to drive further product development

Here is a concrete example of how MDN will benefit from an experimental approach. We have an outstanding bug, “Kuma: Optional IRC Widget“, opened 3 years ago and discussed at great length on numerous occasions. This bug, like so many enhancement requests, is really a hypothesis in disguise: It asserts that MDN would attract and retain more contributors if they had an easier way to discuss contribution in realtime with other contributors.

That hypothesis is untested. We don’t have an easy way to discuss contribution in realtime now. In order to test the bug’s hypothesis we propose to integrate a 3rd-party IRC widget into a specific subset of MDN pages and measure the result. We will undoubtedly learn something from this experiment: We will learn something about the specific solution or something about the problem itself, or both.

Understanding the actual problem to be solved (and for who) is a critical element of product experimentation. In this case, we do not assert that anonymous MDN visitors need a realtime chat feature, and we do not assert that MDN contributors specifically want to use IRC. We assert that contributors need a way to discuss and ask questions about contribution, and by giving them such a facility we’ll increase the quality of contribution. Providing this facility via IRC widget is an implementation detail.

This experiment is an example of optimization. We already know that contribution is a critical factor in the quality of documentation in the documentation wiki. This is because we already understand the business model and key metrics of the documentation wiki. The MDN documentation wiki is a very successful product, and our focus going forward should be on improving and optimizing it. We can do that with experiments like the one above.

In order to optimize anything, though, we need better measurements than we have now. Here’s an illustration of the key components of MDN’s documentation wiki:

metrics_status Visitors come to the wiki from search, by way of events, or through links in online social activity. If they create an account they become users and we notify them that they can contribute. If they follow up on that notification they become returners. If they contribute they become contributors. If they stop visiting they become disengaged users. Users can request content (in Bugzilla and elsewhere). Users can share content (manually).

All the red and orange shapes in the picture above represent things we’re measuring imperfectly or not at all. So we track the number of visitors and the number of users, but we don’t measure the rate by which visitors become users (or any other conversion rate). We measure the rates of content production and content consumption, but we don’t measure the helpfulness of content. And so forth.

If we wanted to add a feature to the wiki that might impact one of these numbers, how would we measure the before and after states? We couldn’t. If we wanted to choose between features that might affect these numbers, how would we decide which metric needed the most attention? We couldn’t. So in 2015 we must prioritize building enough measurements into the MDN platform that we can see what needs optimization and which optimizations make a difference. In particular, considering the size of content’s role in our ecosystem, we must prioritize features that help us better understand the impact of our content.

Once we have proper measurements, we have a huge backlog of optimization opportunities to consider for the documentation wiki. Experiments will help us prioritize them and implement them.

As we do so, we are also simultaneously engaged in a completely different kind of experimentation. Steve Blank describes the difference in his recent post, “Fear of Failure and Lack of Speed In a Large Corporation”. To paraphrase him: A successful product organization that has already found market fit (i.e. MDN’s documentation wiki) properly seeks to maximize the value of its existing fit — it optimizes. But a fledgling product organization has no idea what the fit is, and so properly seeks to discover it.

This second kind of experimentation is not for optimization, it is for discovery. MDN’s documentation wiki clearly solves a problem and there is clearly value in solving that problem, but MDN’s audience has plenty of problems to solve (and more on the way), and new audiences similar to MDN’s current audience have similar problems to solve, too. We can see far enough ahead to advance some broad hypotheses about solving these problems, and we now need to learn how accurate those hypotheses are.

Here is an illustration of the different kinds of product experiments we’re running in the context of the overall MDN ecosystem:

optimization_vs_learningThe left bubble represents the existing documentation wiki: It’s about content and contribution; we have a lot of great optimizations to build there. The right bubble represents our new product/market areas: We’re exploring new products for web developers (so far, in services) and we’re serving a new audience of web learners (so far, by adding some new areas to our existing product).

The right bubble is far less knowable than the left. We need to conduct experiments as quickly as possible to learn whether any particular service or teaching material resonates with its audience. Our experiments with new products and audiences will be more wide-ranging than our experiments to improve the wiki; they will also be measured in smaller numbers. These new initiatives have the possibility to grow into products as successful as the documentation wiki, but our focus in 2015 is to validate that these experiments can solve real problems for any part of MDN’s audience.

As Marty Cagan says, “Good [product] teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building.  Bad teams hold meetings to generate prioritized roadmaps.” On MDN we have an incredible opportunity to develop our product team by taking a more experimental approach to our work. Developing our product team will improve the quality of our products and help us serve more web developers better.

In an upcoming post I will talk about how our 2015 focus areas will help us meet the future. And of course I will talk about specific experiments soon, too.

MDN Product Talk: Business Context

This post is intended to frame the business context that MDN operates in. This is not a product strategy. It is the second in a series of posts begun here.

One of the questions I asked in my introductory post was, “What does solving problems for MDN’s audience accomplish for Mozilla?”. In other words, what opportunities make this investment worthwhile?

It’s not always comfortable to ask such questions, but they’re important. We operate within constraints; everything we do has an opportunity cost. Why MDN? I’m glad to say it is easy to answer.

MDN is a public service sponsored by Mozilla, a mission-driven nonprofit. Mozilla does not measure success by revenue, we measure success by our global impact. Products at Mozilla are expected to deliver impact on Mozilla’s mission and support at least one of Mozilla’s main product lines.

Mission Impact

Mozilla’s mission is to build the internet as a global public resource open and accessible to all. Web developers are critical to the mission. They choose the platforms and technologies they use to build products:

  • Deploying to the web is a developer choice.
  • Using open web standards is a developer choice.
  • Building content that works across a multitude of devices is a developer choice.
  • Making content accessible to a broad, global audience is a developer choice.

The success of Mozilla’s mission depends on these developer choices. Developers make choices pragmatically — they choose the possible. MDN makes building open and accessible on the web more possible. MDN empowers all developers to make choices aligned with Mozilla’s mission and thereby create the web the world needs.

How do we measure this impact? Look to future posts for more discussion of this.

Top-line Organizational & Product Support

MDN supports Mozilla’s top-line goal to create meaningful relationships with Mozilla product users worldwide. MDN’s current audience contributes approximately 1-2% toward Mozilla’s overall relationship goals; this number is naturally limited by the size of MDN’s market.

MDN is naturally aligned with Mozilla Learning. Mozilla’s learning products build contributors to the web. MDN empowers expert and professional web makers and is uniquely positioned to address those who aspire to be expert or professional web developers. MDN’s alignment with Mozilla’s learning initiatives is obvious, but only recently intentional; in 2015 we will experiment to learn more about how to directly support Mozilla Learning.

Market

In 2015 MDN will focus on three segments — two of them new.

MDN historically has served web developers who want to build standards-based web sites. After a decade of providing high-quality information about web technologies on its documentation wiki, MDN is considered an authority among these developers. (For instance: Instructors at several “web developer bootcamps” in my town tell me they actively guide students toward MDN, away from MDN’s competitors, because they only trust MDN.) MDN serves more of these developers every month and now serves 25-50% of the global market. These developers are MDN’s core users and the choices they make directly impact Mozilla’s mission.

MDN’s authority, expertise and capabilities position it uniquely to serve web learners who aspire to be web developers. The job market for developers is strong and growing. The number of jobs in both web development and software development is expected to grow by 20% or more in the U.S. by 2020. Global growth is expected to follow a similar trend. MDN can match these new web developers with product features that will help them become web developers building standards-based web sites.

MDN’s authority, scale and unique content position it to serve professional web developers who want to build standards-based web sites professionally. Recent surveys indicate that more than half of MDN’s visitors meet that description. A large number of these professionals say they are motivated to build web products that embody Mozilla values like accessibility, compatibility, and security, but are under-served by tools to make doing so feasible. MDN can build new products and features to fill the gap, increasing these professionals’ ability to build standards-based web sites on deadline.

2015 Goals

Considering those opportunities, in 2015 the MDN team has committed to…

  1. “Relationships”: Support Mozilla’s overall goals by continuing the (double digit per year) organic growth of our original segment, web developers who want to build standards-based web sites.
  2. “Teaching”: Support Mozilla’s learning initiatives by exploring and implementing new capabilities that will serve a new market and segment, web learners who aspire to be web developers.
  3. “Services”: Add a new product, “Services” to serve a new segment, professional web developers who want to build standards-based web sites professionally.

KPIs for these live on the Mozilla wiki with other information about the MDN team’s overall vision, mission and objectives.

Summary

Can you put a TL;DR at the bottom of a post? Let’s find out. After this post and yesterday’s, we can now say…

MDN is a product ecosystem that serves an audience whose choices are critical to the success of Mozilla’s mission. MDN serves them at a scale unique within Mozilla and in the market. In 2015 MDN will continue serving web developers who want to build standards-based web sites while building prototypes and experiments to solve problems for web learners and professional web developers.

Next: Products! Stay tuned…

MDN Product Talk: Introduction

In coming days I will post a series of blog posts about MDN, the product I am product manager for. I will talk about MDN’s business case, product strategy, and a series of experiments we can run on MDN in 2015 (and beyond) to help it continue to serve its audience and the web.

Many people familiar with MDN will consider some of the following posts obvious; to them I say, “stay with me.” Not all of this will be obvious to everyone. Some may be novel to everyone. Any of it may need clarification or improvement, which I will learn from gentle comments.

mdn_logo-wordmark-full_colorAs a new member of the MDN team, I taxed my colleagues in pursuit of answers to such questions as…

  • What is MDN?
  • Whom is MDN for?
  • What are their problems?
  • How does MDN solve those problems?
  • What does solving those problems accomplish for Mozilla?

I posed such questions to almost everyone I could corner, from members of Mozilla’s steering committee to random web developers I met at kids’ birthday parties. I interrogated historic mailing list threads. I scanned through hundreds of enhancement requests in our bug backlog. I read books about product management. I doodled architectural diagrams and flowcharts. And finally I think I came to an understanding. I hope sharing it is helpful.

So what is MDN? Is it a documentation site? A developer program? A wiki? A network? A suite of products? A single product? A brand? A railway station? It depends on whom you ask and when. Few of the people I cornered could say exactly what MDN is or ought to be. Most had an idea of what MDN ought to accomplish, but their ideas varied wildly.

One thing is clear: MDN is successfully serving a large portion of its potential market and has been doing so in its present form for nearly 10 years. Which is great. But… what is MDN?

For most of MDN’s primary audience — web developers — MDN is a documentation wiki (i.e. a user-generated content site or UGC) serving trustworthy information about open web technologies (primarily HTML, JavaScript and CSS). And of course the audience is correct.

But MDN is also a brand that resonates with its audience and fans. And MDN is also a community of contributors who care about MDN. And MDN is also a platform where all these things mingle and mix.

All told, MDN includes (at least) 6 product offerings in operation or development and (at least) 8 significant enhancement projects underway, as well as numerous activities and projects that sustain the documentation wiki. The interplay between these activities is complex.

OK, great; but what is MDN?!? Considering its scope — the variety of its critical stakeholders, the complexity of its value chain, the number of supporting activities underway — I think MDN can only be considered a product ecosystem.

MDN_product_ecosystem

  • MDN is a strong brand supported a number of products and activities.
  • Chief among these is a platform, the documentation wiki, which is also called MDN.
  • Within the platform content is huge: MDN’s primary audience visits solely for the content, because the content is valuable. The MDN brand’s authority and the MDN platform’s scale both depend on the MDN content’s quality.
  • As an open-source web application serving user-generated content about open standards, contribution overlaps almost every aspect MDN — especially content creation. The MDN content’s quality depends in large part on contribution.
  • Various marketing efforts support MDN, strengthening its brand, attracting new visitors, and activating contributors. MDN marketing efforts among developers also support Mozilla’s brand.
  • In response to a clear market need, the MDN team is experimenting with some developer-facing services that will be partly supported by the content and platform.

That’s a lot of moving pieces — and we haven’t even begun talking about whom MDN serves and what problems MDN solves for them! Look for answers to those questions and much more in coming posts.

As we go I’ll use the above diagram to help contextualize things. More to come!

:wq

Report: Web Compatibility Summit

Last week I spoke at Mozilla’s Compatibility Summit. I spoke about compatibility data. Here are my slides.

Compatibility data…

  • is information curated by web developers about the cross-browser compatibility of the web’s features.
  • documents browser implementation of standards, browser anomalies (both bugs and features), and workarounds for common cross-browser bugs. It theoretically covers hundreds of browser/version combinations, but naturally tends to focus on browsers/versions with the most use.
  • is partly structured (numbers and booleans can answer the question, “does Internet Explorer 10 support input type=email?”) and partly unstructured (numbers and booleans cannot say, “Safari Mobile for iOS applies a default style of opacity: 0.4 to disabled textual <input> elements.”).

Compatibility data changes all the time. As a colleague pointed out last week, “Every six weeks we have all new browsers” — each with an imperfect implementation of web standards, each introducing new incompatibilities into the web.

Web developers are often the first to discover and document cross-browser incompatibilities since their work product is immediately impacted. And they do a pretty good job of sharing compatibility data. But as I said in my talk: Compatibility data is an oral tradition. Web developers gather at the town pump and share secrets for making boxes with borders float in Browser X. Web developers sit at the feet of venerated elders and hear how to make cross-browser compatible CSS transitions. We post our discoveries and solutions in blogs; in answers on StackOverflow; in GitHub repositories. We find answers on old blogs; in countless abandoned PHP forums; on the third page of search results.

There are a small number of truly canonical sources for compatibility data. We surveyed MDN visitors in January and learned that they refer to two sources far more than any others: MDN and caniuse.com. MDN has more comprehensive information — more detailed, for more browser versions, accompanied by encyclopedic reference materials. caniuse has a much better interface and integrates with browser market share data. Both have good communities of contributors. Together, they represent the canon of compatibility data.

Respondents to our recent survey said they use the two sites differently: They use caniuse for planning new sites and debugging existing issues, and use MDN for exploring new features and when answering questions that come up when writing code.

On MDN, we’re working on a new database of compatibility data with a read/write API. This project solves some maintenance issues for us, and promises to create more opportunities for web developers to build automation around web compatibility data (for an example of this, see doiuse.com, which scans your CSS for features covered by caniuse and returns a browser coverage report).

Of course the information in MDN and caniuse is only one tool for improving web compatibility, which is why the different perspectives at the Compat Summit were so valuable.

concentric_compatibility

If we think of web compatibility as a set of concentric circles, MDN and caniuse (and the entire, sprawling web compatibility data corpus) occupy a middle ring. In the illustration above, the rings get more diffuse as they get larger, representing the increasing challenge of finding and solving incompatibility as it moves from vendor to web developer to site.

  • By the time most developers encounter cross-browser compatibility issues, those issues have been deployed in browser versions. So browser vendors have a lot of responsibility to make web standards possible; to deploy as few standards-breaking features and bugs as possible. Jacob Rossi from Microsoft invited Compat Summit participants to collaborate on a framework that would allow browser vendors to innovate and push the web forward without creating durable incompatibility issues in deployed websites.
  • When incompatibilities land in browser releases, web developers find them, blog about them, and build their websites around them. At the Compat Summit, Alex McPherson from Quickleft presented his clever work quantifying some of these issues, and I invited all present to start treating compatibility data like an important public resource (as described above).
  • Once cross-browser incompatibilities are discussed in blog posts and deployed on the web, the only way to address incompatibilities is to politely ask web developers to fix them. Mike Taylor and Colleen Williams talked about Mozilla’s and Microsoft’s developer outreach activities — efforts like Webcompat.com, “bug reporting for the internet”.

At the end of the Compat Summit, Mike Taylor asked the participants whether we should have another. My answer takes the form of two questions:

  1. Should someone work to keep the importance of cross-browser compatibility visible among browser vendors and web developers?
  2. If we do not, who will?

I think the answer is clear.

Special thanks to Jérémie Patonnier for helping me get up to speed on web compatibility data.

Learning Experiments on MDN

At the bottom of this post, I ask: Who should I connect with to learn more about the state of the art in professional web developer education? Read on to see why, and answer if you can.

Mark Surman, Executive Director of the Mozilla Foundation, wrote on his blog recently about the Foundation’s ambitious plans to make Mozilla “a global classroom and lab for the citizens of the web”. He briefly mentioned MDN, the product I manage:

Given what we’re already doing, being bold doesn’t need to involve huge new investments. In fact, it can start simply with being more clear and assertive the work we already do. Not just with Webmaker, Hive and Maker Party, but also with user education in Firefox, Mozilla Developer Network, ReMo program and our research and fellowships programs. What I’m talking about starts with making these things stronger — and then telling a clear story to ourselves and the world about how they add up to a coherent whole. That’s what I want us to start doing in 2015.

He’s right: Mozilla has been teaching the web for years through numerous channels. Along with our explicit efforts, Mozilla’s policy, community development, content, and product features all help people learn how the web works and how to use it effectively. We can confidently state our intent to do more of that.

MDN has always – explicitly – been a learning resource. When the MDN wiki launched in 2005 it was billed as “a Mozilla project dedicated to providing documentation, education, and community for developers of all types.” Now MDN helps millions of developers every month to understand the core technologies used for building web sites.

Mozilla’s other efforts in education to date have focused on building local networks, teaching web literacy and creating enthusiasm for web technology among young people and non-developers. MDN complements this work because it provides similar (but distinct) opportunities to an audience of intermediate and advanced web developers. A significant majority of MDN visitors – 70% in recent surveys – are professionals in the field.

Along with the Foundation group, MDN will spend much of 2015 making our educational role explicit. For example, last week the MDN content team quietly launched a new learning area on MDN. This learning content represents a large and ongoing effort by many volunteers and staff contributors to create new pathways into the advanced web topics MDN  covers. Like most wiki content, it is a work in progress; in 2015 the learning content will make great leaps forward. (Also like most wiki content, you can contribute your expertise to make it better.)

We recognize that learners learn in very different ways. Some easily absorb the technical documentation MDN has always provided; others need a different format, or different materials, to help them grasp these complicated subjects. But what additional formats and materials can MDN contribute to these learning experiences? Like the  learning area, this is new territory for MDN. So in 2015 we’ll undertake a variety of experiments to help understand how MDN can best help people grow their web development skills and become professionals and adepts at making the web the world needs.

Here are some naive examples to show what I mean by “experiments”:

  • Videos are a common medium among sites teaching things. Are they effective? Would MDN’s audience appreciate them? Should we experiment with integrating or linking to more video content on MDN?
  • There are lots of online schools teaching web development. Are any of them doing an incredible job of it? Should we talk to that school about collaborating to give MDN users access to its programs?
  • MDN can facilitate local learning groups. Would that be valuable? How could we do that? How would we know it was working?
  • etc.

I will solicit and explore such experiments here, on this blog, and will recommend the most compelling opportunities for more work in 2015. I encourage anyone with feedback or questions to discuss in comments, reach out to me directly, or respond in kind on their own blog (and let me know about it).

Here is my first question for all the learners and teachers out there: Who should I connect with to learn more about the state of the art in professional web developer education? Twitter handles, blog URLs, and introductions welcome.

You should learn to code.

A proliferation of online courses promising to teach you how to write computer code have attracted some big celebrity names recently, and some celebrities have even launched things. But even if you’re not a billionaire mayor, you probably should learn some coding skills. Below I offer six good reasons to try.

First, let’s be clear about terminology:

  • For the purpose of this article, I mean the same thing when I say “coder”, “developer”, “hacker”, or “programmer”.
  • When I say “code”, “develop”, “hack” or “program”, I really just mean, “create coded instructions that a computer can interpret to produce some result.” Computers are machines that implement logical instructions. Coders write the instructions in code.
  • When I say “coders write the instructions,” I mean they use a keyboard, not a mouse. Coders don’t drag & drop code. Coders do write drag & drop code, though.

Now that we’re talking about the same thing, here are six reasons you should learn to code.

REASON 1: If you learn to code, you will be a better communicator in the future.

Some autumn day in 2020, you will find yourself feeling a little chilly despite the silver bodysuit you’re wearing. So you will say something out loud like, “Hey house, please turn up the heat three degrees.” Then a computer will make the thermostat in your house rise by three degrees. But if, instead of that, you said, “Dang, it’s cold enough in here to freeze the fuzz off a snow weasel,” your house would definitely pretend it didn’t hear you.

The point is, we will soon interact with computers using a variety of inputs besides mice and keyboards, including the spoken word. But in the very near future when we speak to computers, we will have to speak to them in a dialect they can understand, just as we speak to dogs using special, limited vocabularies. And learning to code will make you much more fluent in this dialect.

cheddar-drone-03

Now: A day will come when computers also understand the part about the snow weasels; heck, in the distant future you will be able to pilot a cheddar drone using only your mind! But the road to that bright horizon is paved with a lot of zany mishaps. Meanwhile, learning to talk and think like a computer will immediately make you more confident and capable in a world full of helpful machines that don’t understand human language very well.

REASON 2: If you learn to code, you will make cool new friends!

A whole lot of people on the internet are coders and many of them spend a lot of time helping each other learn stuff. They’re usually smart and nice. And despite stereotypes to the contrary, most coders are also pretty hip.

Imagine a group of people who are so passionate about their work that they do it on the weekends, too, and then give the fruit of their efforts away for free to anyone in the world. Many coders consider this standard procedure. They do it because they love it and the community expects it of them. It is their way of influencing history. Like artists.

Now, imagine you are trying to learn to code and you run into a problem. If you diligently attempt to resolve it through reading and experimenting and you still can’t solve it, and then you ask for assistance in an online forum of coders, you will almost always get a friendly, helpful, and downright generous response from someone you’ve never met whose time is worth a lot of money. If you participate and contribute to that same community, you may even befriend or become such a person. You will thereby join a global fellowship of coders, and you can expect to receive a mysterious book of rites in the mail.

LIR: The Mysterious Maya Civilization: Pre-Columbian Era to 1825

REASON 3: Adventure, fortune and freedom await you!

There is no question that computer programming is a lucrative occupation for many people who are good at it and also for many who are not. As of this writing, a senior Ruby on Rails coder can make about fifty thousand dollars per hour. So if you like money or the things money can buy, you might want to get a job as a coder.

On the other hand, you may not care about money, in which case would you mind buying me a beer? Thanks.

That link you just clicked goes to InspirePay, a payment startup founded by Mark Fischer. Mark charges nothing for the service — so, since you’re buying, do you mind getting him a pint too?

Like many software entrepreneurs, Mark seems to be motivated in part by the sheer adventure of it. The world is stacked a mile deep in problems that software can solve. These problems will occupy software innovators for decades to come. Entrepreneurs like Mark are like early pioneers crossing the tall grass prairie, like legendary cattlemen on the high desert, like the first gold miners in the Sierras. They see the promise of adventure and they accept. They go first.

Learning to code gives you a gleaming toolkit to carry into this vast new frontier, a frontier where you will find countless opportunities to make a fortune and take wild risks. Sounds exciting, doesn’t it? I’ll drink to that.

REASON 4: If you learn to code, you can kill a lot of birds with one stone. More than two birds, anyway.

I have a friend who runs a software development firm. His firm specializes in PHP coding. (He doesn’t pronounce PHP as “fup”, but I do.)

Most software development firms get a lot of inquiries, and only a fraction of these inquiries turn into contracts. Along the way a firm often produces a proposal describing the work contemplated. This is a challenge: Proposal writing is repetitive, time consuming, and often fruitless.

So my friend wants to automate his ideal proposal generation process with a web application. He’s hacking on it nights and weekends using the laravel framework. Plenty of technology service companies do this kind of thing; some even make a business out of it it.

When he’s done, my friend will have:

  • A tool that satisfies his own business need, making his sales process more efficient and fun.
  • A software product that he can either give away to generate goodwill, or sell to generate revenue, or both.
  • Launch experience (which is the best kind) with a new coding framework (laravel) that he’s A) been looking for an excuse to work with and B) would eventually like to offer as a service to his customers.

Intimidating Swans

That is at least three dead birds; it could be more depending on how you count. So if you hate birds or something, now’s your chance to do something about it.

REASON 5: You have everything you need to start coding.

Computer programming is a difficult occupation, no doubt about it. But it does not take any more smarts than being an actuary or an attorney. It is probably less stressful than being a paramedic or a stockbroker. And it involves practically zero large predators, unlike zookeeping. Coding is mathematical and conceptual, abstract and very dynamic, and it is not for everyone. But look, you’re already on REASON #5 of a long and irritating six-reason blog post. You clearly have the most important characteristic of a good coder: speed-reading focus patience interest.

Are you reading this on a computer that is sometimes connected to the internet? (If not — if you’re reading this in print — I’d like to thank you. I’ve always wanted to be published on paper. It’s really, like, flammable, you know? Do you mind lighting a corner of it on fire right now? Wicked.)

If you have a computer that is sometimes connected to the internet and you’re truly interested in coding, then you have everything that most people who code ever had when they started. Most of them didn’t have computer science training. Many of them didn’t have college degrees at all, or even high school diplomas. All good coders are self-taught to some extent. With your computer and your interest, you can do just what they do:

  • Build a development environment — a sandbox where you can fling computer code around without harming other things on your computer that you care about. (You wouldn’t want to damage those blurry photos of enchiladas you took during that road trip to Tucson.) You can even try it out using an online sandbox.
  • Try and make something simple in code, starting from a tutorial online or from a crazy vision in your head.
  • Make lots of mistakes on the way, but who cares? You’re in the sandbox!
  • Read lots of documentation online.
  • Maybe ask some questions online, explaining that you already read the documentation.
  • Repeat these steps for a while, and do it again every time you want to learn something new.

Seriously, you can learn to code no matter who you are. Everybody starts somewhere.

REASON 6: The world needs more people who understand, care about, and can make things with the raw materials of our brave new society.

This cannot be overstated: Humanity has experienced only a few inflection points as important as the one that makes it possible for me to say this to you right now. No matter how you feel about the media, smartphones, blogs, Facebook, the internet or computers, you must understand that they are radically, rapidly transforming culture and society in every direction at once. Your financial transactions and the football scores and your precise location on earth, pictures of your baby and adoring comments from its grandmother, your job and your friends and your secrets, your final conversation with someone you love, groceries on store shelves, missiles in their silos, the stoplights and the cars waiting at them and the people sitting in the cars and the news on the car radios — all that and more every day is connected and controlled through an information network that humans created with code .

When it appeared, the printing press made written material much more accessible to many more people. Still, not everyone immediately learned to read and write. The people who did learn to read and write fully participated in the new world that the printing press made possible. They controlled economic activity. They made the government and its laws. They recorded the histories. They propagated the world’s religions. They owned a portion of the culture, and they fought for their part.

The ones who didn’t learn to read and write? Most of them saw their fair share of sunrises and sunsets, just like most people for most of history always have. But a universe of richness and capability eluded them. Fantastic novels, inflammatory pamphlets, laws and holy books: All were just mysterious symbols to the illiterate. Just like code is to so many people now.

Go to it! by drbexl, on Flickr

Today, too many smart people fear or disregard code, and shrug away their disregard as acceptable and normal. But code keeps food on our shelves. Code brings us all we know of world events. Code makes your smartphone possible. Code enables the unfettered personal expression we call a right. Code is the weapon that will win future wars. Code is the medium of future artworks. Code is the conduit of freedom.

Now, since you read this far, you obviously have plenty of time. So c’mon — why don’t you make some code? Here are a few places to start:

(This post was originally published on the dojo4 blog when I was the CEO of dojo4. I copied it here and refreshed it because I like it. It is adapted from a presentation I gave to a lunch meetup of the Boulder Chamber of Commerce’s 2140 group.)

Vouched Improvements on Mozillians.org

Back in October I wrote a few blog posts describing a significant problem with the way we admit new members into the Mozillians.org community platform. Yesterday the Mozillians.org team fixed it!

Before yesterday, everyone with a “vouched” account in Mozillians.org was empowered to vouch others. But we never explained what it meant to vouch someone: What it implied, what it granted. As a result, the standard for being vouched was arbitrary, the social significance of being vouched was diluted, and the privileges granted to vouched users were distributed more widely than they ought to be.

Yesterday the Mozillians.org development team released a major refactor of the vouching system. For the first time we have a shared definition and understanding of vouching: A vouch signals participation and contribution in Mozilla’s community, and grants access to content and systems not available to the general public.

The new vouch system includes features that…

  • ask a “voucher” to explain to the community why they are vouching someone
  • grant the “vouching” privilege only to people who have themselves been vouched multiple times
  • remove “legacy vouches” from accounts that were vouched before we agreed what vouching meant and whose current contributor status can’t be easily verified

It is much clearer now who can access non-public information using Mozillians.org (people who have been vouched because they participate and contribute to Mozilla) and how that list of people can grow (through individual judgments by people who have themselves been vouched numerous times).

When we know the composition of a network and understand how it will grow, we can make better decisions about sharing things with the network. We can confidently choose to share some things because we understand whom we’re sharing with. And we can reasonably choose to withhold some things for the very same reason. Understanding a network simultaneously encourages more sharing and reduces inadvertent disclosure.

Thanks to the Mozillians.org development team for making these excellent improvements!

Site launch: Affiliates 2.0!

Cross-posted from http://blog.mozilla.org/webdev/2014/05/21/site-launch-affiliates-2-0/.

We just launched a redesigned website for Firefox Affiliates — check it out!

New Affiliates web site!

The Affiliates website is a portal for almost 100,000 Mozilla supporters. Affiliates believe in Mozilla’s cause and want to show their support by placing an affiliate link on their website. Here’s mine:

If you use Adblock Plus you probably see nothing here. And that’s a shame.

The original Affiliates website launched in 2011. Its branding recalls an earlier era in Mozilla style. I will miss those fuzzy monsters, but (for now at least) I know I can still find them on Mozilla.org’s 404 page. And seriously, after three years, the site needed more than a brand refresh. As part of this launch we…

Image from the original front page.
The Affiliates 1.0 front page included fuzzy monsters.
  • Upgraded to the latest version of Playdoh
  • Removed lots of old code and subsystems no longer in use
  • Reconsidered and redesigned the entire user experience
  • Updated the pages to a beautiful take on Mozilla’s Sandstone theme
  • Added an affiliate leaderboard
  • Added user profiles and a personalized dashboard
  • Added space for localized news and announcements
  • Much more!

If you’re already a Firefox Affiliate, we* hope you enjoy these improvements. And if you’re not, why not sign up now? Being an affiliate is an easy way to support the efforts of a non-profit that strives every day to build the web the world needs.

We’d like to hear from you. Please file a bug if you find one or reach out in the #affiliates channel on irc.mozilla.org to say “hi”. And keep your eye out for more new features — there’s another batch of Affiliates Awesome just around the corner!

* The Affiliates 2.0 team included dozens of people spanning the globe — too many to list here. This site redesign was a collective effort of Mozilla’s amazing affiliates, volunteers, localizers, designers, copywriters, engineers, quality assurers, contractors,  and many others. Thank you all.

2114-05-15: Happy Bike Month!

The basic elements of subsistence that our grandparents learned in childhood – food, water, shelter – were missing a critical category: travel. People have a basic need to go places, and the way we move profoundly affects almost every system we can imagine: tectonic, atmospheric, metabolic, social, ecological, economic and even metaphysical. At the start of the last century, each of these systems was responding with extreme and hazardous feedback to our poor transportation decisions.

Luckily, around the same time, new tools and networks sparked a renaissance of creative, enlightened endeavor. People energetically sought solutions to many of the world’s greatest challenges. Intractable problems suddenly became addressable and their solutions marketable. Humans developed better models, better designs, and better ways of organizing around important questions, all of which led to rapid and dramatic improvements in human-created systems.

So it came to pass that a dozen new electric vehicles appeared one after another in the market. They came in lots of different shapes and sizes. They steered themselves and ran on sunlight. They never endangered pedestrians, bikes, or animals.

These new vehicles were accompanied by well-organized advocacy and their appearance coincided with several powerful political movements. Legislators and traffic planners and corporate titans had no choice: They had to accommodate a world of better transportation alternatives.

Notwithstanding the remarkable features of these new vehicles, many individuals nowadays don’t bother with the expense and bother of owning one. Moving large metal-and-plastic bodies still requires a lot of energy. Energy is still expensive. Due to shifting geopolitical conditions, first-world economies have mostly stopped hiding the cost of energy from consumers. Consumers have changed their behavior as a result. Individuals these days are much more deliberate about the geographic impacts of their choices.

Walking is so much more pleasant than it used to be when roads were hazardous and filled with noxious smoke. Short trips are also easy to take on a variety of electric conveyances, so people tend to stay closer to home most days. As you would expect, many businesses have come to recognize the value of proximity, too. Now most of us have easy neighborhood access to groceries, hardware and household goods. A robot-driven jitney is always close by if one needs to travel far in the rain.

Compared with a century ago, people today have cleaner air, cleaner water, more cohesive neighborhoods, more aesthetically pleasing public spaces, more resilient cities, more reasons to go outside, more games of kickball in the street, and more time for reflection or creation from the back seat of a self-steering car.

We simply shake our heads when we see old accounts of 20th-century drivers. They seem utterly ridiculous. Their transportation systems promised freedom but delivered economic servitude, ecological travesty, public health crises, social unraveling and a daily dose of helplessness and rage.

Since those times, many elements have combined to make things better. Someone else might argue that another factor was the fulcrum of change – solar cell or battery improvements, say, or the simultaneous rise of local governments and benevolent global institutions. But I believe life is immeasurably better now because we finally reconsidered how to get from here to there.

Motes of Dust

sunbeam

The baby raised her hands and face into a morning gleam
She'd noticed for the first time motes of dust on a sunbeam
Motes of dust on a sunbeam: I've been too old to see them shine
Now the baby's wondering delight, once before, once more is mine