Ode to James Socol


James Socol is moving on from Mozilla. It took me a week or so to digest what this means to me. Today I’m sitting here, in what would have been our weekly 1:1, writing this post because:

  • I’m not letting James leave without a proper tribute
  • I’ll miss working with him (a lot)
  • He is too humble to write a post about how badass he is
  • I couldn’t take him out drinking to dinner last week

What I’ll Miss

At the top

James Socol is a force of good. He can usually be found getting shit done and pushing forward every day. I’ve worked with James for about four years as his manager. He possesses both sound principles and a wicked work ethic. He was reliable and never said, “that’s not my job.” He’s the kind of guy you want on your side.

There are many reasons to miss James but here’s what I will most (in no particular order):

  • Sense of humor: James has a dry sense of humor and has mastered the art of sarcasm (the good kind!). He also understands all internet memes and often corrected me on these. His depth of Penny Arcade and xkcd knowledge are unparalleled. I’ll miss all the laughter we shared during work weeks and meetings.
  • Passion for people: It was great seeing James grow as a manager. James and I first started testing Rypple for managing feedback loops a few years ago here at Mozilla. Neither of us were going to accept a yearly feedback loop as enough for personal development of our teams. He volunteered to experiment with new methods for managing teams and led by example. You could tell he actually cared about people and being a manager was more than just a job to him. I’ll miss working with him on leadership and management because I learned as much from him as he learned from me.
  • Solving problems, not symptoms: Regressions are always something to worry about in software. What made James special is he isn’t happy just fixing regressions faster or reducing them to a reasonable level. He strives to eradicate them and pushed us to move forward with continuous integration and deployment. James approached every problem with soul. His work will persist in what he leaves behind but I will miss how well he matched the work of today with the principles behind tomorrow.
  • Putting his heart into it: All in. That’s what comes to mind when I think about how James approached things. He’d be upset if things weren’t working well, if someone was unhappy with him or if a launch went poorly. He lived and breathed his work for Mozilla and I will miss his passion for the mission because it inspired me and everyone around him.

A Giant Code Impact

James discusses his favorite topic

On top of everything else, James was a code beast. He has quite a few repositories but when it comes to code, here’s what stands out:

An easy, HTML5, whitelisting HTML sanitizer. A powerful and widely used libary; gives webdevs granular control over HTML inputs.
A Python client for the statsd daemon. James pushed for us to use statsd and Graphite. Instead of complaining that we didn’t use them he got his hands dirty and made it work and convinced everyone why it was important.
A feature flipper for Django. It can define the conditions for which a flag should be active, and use it in a number of ways. This helped our first continuous projects focus on shipping features instead of arbitrary versions.
A CSS/JS bundler and minifier for use with Jingo; connector to use Jinja2 templates with Django. This helped us minify assets for deployment.
A collection of small but useful tools for Django. Often used internally by our developers.
James was a key contributor to playdoh, especially in the early days before it became an official library. He wrote a lot of its middleware and built one of our first sites using Django as its foundation. Today, playdoh is a popular choice for new projects at Mozilla (if written in Python).
kitsune and kuma
Last but not least, James was the lead engineer behind Mozilla’s customer support knowledgebase and developer documentation software. If I’m not mistaken he also chose the codenames.

Mad Street Cred

Nice kicks

James leaves behind two solid teams who build and support support.mozilla.org, input.mozilla.org and developer.mozilla.org. It’s important to note that his peers will miss him as much as I will. Here are some things they were thankful for:

On management:

… totally the best manager I’ve ever had. He understood the way that developers work (being a developer himself) and he was also such an awesome person! Also I think as far as my experience goes, he’s the first manager I’ve had that I felt completely comfortable being 100% open with.

broke every stereotype I had about managers. Great to come to Mozilla and have an awesome manager.

encouraged us to think about sane remote working practices

being a very nice interviewer

James always was encouraging and offered a tremendous amount of support to new developers. James was one of my favorite people who interviewed me when I applied to Mozilla. James’ demeanor, personality and attitude put me at ease. James truly displayed the Mozilla attitude that I love about working here.

As an engineering mentor:

continuous deployment/improving webdev’s deployment processes a LOT

He put freakin’ LOLcats in a code review! He’s very serious about quality code but he reminds us not to take ourselves too seriously.

Being Webdev’s security ambassador with the Security team

Being Guardian of Code Cleanliness on all his projects

James was humble and helped webdev grow through through various scaling points.

As a person:

letting me crash on his couch twice in one summer with random people he’d never met

Starting the “Better Know A Webdev” blog series


James leaves Mozila with solid teams, solid code and better practices. He takes with him acquired wisdom and lasting friendships.

I think James will continue to build amazing things and be successful wherever he goes. If anybody out there doubts him, hopefully they can read this post.

James – I’ll miss you but this isn’t goodbye. I will still troll you on twitter and expect you to keep your libraries up to date!

See you soon. Cheers. ❤

James approves!

Aggression doesn’t solve problems


I’m a bit worried about energy. There’s a karmic quality to what’s going on around us, and I want folks to think about it.

Conan, in his farewell off of NBC, said:

“All I ask of you, especially young people…is one thing. Please don’t be cynical. I hate cynicism — it’s my least favorite quality and it doesn’t lead anywhere. Nobody in life gets exactly what they thought they were going to get. But if you work really hard and you’re kind, amazing things will happen. I’m telling you, amazing things will happen.”

When my grandfather passed away, I clung to this. He was a quiet, unassuming, hardworking Chinese man brought up through some tough times. But he was never a cynic.

I think he had a lot of reasons to lose faith in people in the world around him. World War II, internment camps, segregation, great depression, Vietnam war… the list goes on. I believe we have pretty good lives compared to what he went through. Relatively, we have a lot of positives out there to write about.

So when it comes to net energy exchange, I don’t want to see what amounts to a few assholes trying to push people’s buttons and troll turn us into cynics. To live that way — to perpetuate that mindset — is counter-productive at best, self destructive at worst.

Because of karma, entropy, net energy, whatever — I personally don’t believe in aggression against aggression as a winning strategy. I find a lot of the language online to be rather aggressive, particularly toward competing viewpoints. This does everyone a disservice and drains energy from you, the other person, and people who reads this content.

And to what end? Do people become so drained that they quit? Is it about catharsis? Are people so shocked and awed at someone’s outrage that they change their mentality? When is the last time you yelled so loud that everyone just up and changed?


I think there are positive aspects to participation, and I agree with embracing what we feel and speaking up — but I don’t think the angry, rage-against-the-machine approach works for the disaffected. I liken this dichotomy to positive reinforcement vs. punishment.

The key there is it’s not either-or. You need both. In this give and take of energy I don’t believe you can have all the punitive language, the call-to-arms and outrage without the positives getting equal airtime. It’s totally out of balance.

Likewise, as people, I think the material and behavior we contribute to our communities needs balance. If all we’re doing is smacking down people who make mistakes and repeatedly punishing them, well, that has been proven to fail time and again in just about every facet of human society: drugs, prison, childhood development, racism, etc.

Pressure, positivity and time are what changes people. Things like learning, understanding, forgiveness, training and awareness. And not just in small doses – in large, consistent doses. I believe this. So did MLK:

“Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that.”

And here’s the thing: it sucks. People can be assholes; they don’t like to change and they cling to their beliefs. I have a lot of pity for any person who hinges their happiness on how well they can change the people around them.

But remember: not everyone is impossible. Not everyone is against you. Being a cynic is not going to move us ahead.

Codes of conduct, honor, etc. — they have their place and a balance in net energy is what they strive to achieve. A landslide of negativity and churn does not march us towards that vision — it sends us in the opposite direction towards something nobody wants to be a part of.

I’m walking the other way.

“Victory attained by violence is tantamount to a defeat, for it is momentary.” – Mahatma Gandhi

Simple is Better: How to Write for the Web


I often tweet about a favorite article of mine explaining how people read on the web. More and more I see this as a common problem all over the world.

It opens simply enough:

How Users Read on the Web
They don’t.

Instead of just tweeting the article (which is ironically so long that people don’t read it) I’d like to instead study some examples from our site and show how it could improve our own site content.

Often, I find that some of our site content is:

  • Difficult to scan
  • Verbose
  • Passive
  • Unclear
  • Likely to be ignored — users won’t read it

So what should we do about it? Well, we should tackle it from different directions:

  • We should educate ourselves and become familiar with best practices
  • Those who do understand the basics should do their best to teach others
  • We could also conduct user research, eye tracking studies or run a/b tests to verify theories

Either way, I’ll save you some time: simple is better.

So let’s go to some examples. Here’s what we’ll cover:

  • Bulleted lists
  • Highlight key points
  • Reduce unnecessary or redundant words (of, the, a, at, to, that, with the, and)
  • Remove passive speech and replace it with active speech

Bulleted lists

Your goal should be to identify common threads or trains of thought. Tie them together with a lead-in. Augment the leading thought with key phrases. Our example has a common entity: Mozilla. So how can we apply a list to this paragraph?


Mozilla is a non-profit. We don’t have shareholders. We’re not trying to get acquired. Our bottom line is to promote openness, innovation and opportunity on the web.


Mozilla is:

  • a non-profit company
  • loyal to you, not shareholders
  • promoting openness, innovation and opportunity on the web

Highlight Key Points

Highlighting helps users quickly scan key points. They don’t have to read word-for-word but can pick up the general concept of a block of text without reading the whole thing. This is typically how users read on the web, and studies show how important writing scannable text is.

In our case, let’s take the first sentence and see what we end up with.


Mozilla is:

  • a non-profit company
  • loyal to you, not shareholders
  • promoting openness, innovation and opportunity on the web


Mozilla is:

  • a non-profit company
  • loyal to you, not shareholders
  • promoting openness, innovation and opportunity on the web

The addition of bulleted lists gets us farther, but highlighting keywords dramatically improves the visibility and likelihood that those concepts will be communicated to a web reader.

Reduce Words

The single most common problem is that people write too much. In technical writing and web writing, the goal should be content over style. Simple, clear, concise text wins; then users can focus on the content, not on deciphering what you’re actually trying to say.

Words that don’t add anything to the message are a huge problem. We can break up or eliminate some sentences in our example:

  • Mozilla is an extensive open-source software development project powered by a small (but growing) staff and a worldwide community of dedicated volunteers. (before: 23 words after: 10 words)
  • Because our products are used for many of the web’s most innovative projects., a job at Mozilla allows you towill develop cool, useful technology that impacts millions of lives. (before: 29 words after: 20 words)

You can say the same things using less effort while benefiting users. All kinds of win.

Fix Passive Speech

Speaking passively increases the length of your sentences while reducing clarity. Here are two examples:


Because our products are used for many of the web’s most innovative projects, a job at Mozilla allows you to develop cool, useful technology that impacts millions of lives.


You could impact millions of lives developing innovative products at Mozilla.

Here by focusing on “you”, you eliminate a ton of words but deliver essentially the same message.


At Mozilla, we encourage creativity and ambition with the goal of revolutionizing how people access the web.


Mozilla’s goal is to revolutionize how people access the web by encouraging creativity and ambition.

By changing our sentence structure to focus on Mozilla, we eliminate the need for words like “at, we, with, the”.

That’s it. Go forth and write great content. Visit the Writing for the Web main page to learn more.

Rally Fighter visits Mozilla


The Rally Fighter is an open source car with a huge community behind it. Jay Rogers, CEO of Local Motors, took time out of his busy schedule to come talk about his experience with the Rally Fighter during lunchtime today.

Jay Rogers

He gave Mozilla a shout out and said we’re an inspiration for other companies trying to do things the right way and focus heavily on what people want and need. He also mentioned he’s an avid Firefox user and tries to install it on every machine he can get his hands on!

Rally Fighter

Another thing worth noting was his comments on crowdsourcing — that’s it’s not at all about getting a group to do a bunch of work for you. In many ways the textbook definition of crowdsourcing betrays the real value in it.

He said it should really be called co-creation because their community as well as potential customers for this car are a huge part of what the car will actually be and how it will evolve over time. It is a good way to look at things, and not very different from what Mozilla strives to do from day to day.

Rally Fighter

Overall, it was a great experience and the car is damn cool. Thanks to Jay and his team for visiting us. See more pictures here.

Doing more with data


Firefox users: Did you know that you have private database that contains all your browsing information?

Well, you do. And here’s the thing:

  • Only you have access to it
  • It’s under-utilized
  • You probably didn’t even know it existed

Browsing could be better. There’s no question about that. We have set conventions and preconceived notions about how browsing should be. That is, until the next big thing comes along and rocks our world.

It feels like using data to improve browsing is a no-brainer, and data-driven browsing is already the next big thing. You see this in search suggests, amazon suggested items, the iTunes store, and other sites. And that’s just all site-specific. Imagine if we used data the right way and made things just click?

On a limited scale, it’s all more than possible today. You have complete control over your own browsing history:

  • Sites visited
  • Bookmarks
  • Awesome bar history
  • Media viewed
  • Favorite sites
  • Search keywords
  • Trending of all the above

Simple fact is that you’re not using as much as you could.

The Firefox awesome bar was heralded as a great step in browsing innovation. And it’s true, it really was. And that’s because a lot of browsing is really repeat browsing. How many times do you go back and view what you just looked at the other day?

But that’s the tip of the iceberg. There are a lot of things we can learn about the web and about how we use the web to make it better. And don’t think about person -> corporation -> other corporations. For starters, think about what you could do with just your own browsing data, or your family’s browsing data:

  • Easy access to repeat searches – movies, facebook, maps, you name it
  • An automated media catalog of images, videos and news articles you read over time
  • A list of phone numbers you have looked up and who they belong to
  • A list of all map directions you’ve ever done
  • A list of people you read about over the last week

The awesome bar in Firefox already uses this, and it’s great to see some Firefox extensions are already tapping into the possibilities:

  • about:me lets you read about your own browsing statistics
  • Voyage is a very cool way to not only view the sites you’ve used but see how you got there over time and whether or not you Tweeted about it!

Those are just two examples of what we can do and where we can go. I’m pretty excited to see what happens next. Maybe you have the next great idea — go forth!

Optimizing your JS and CSS


My coworker Ryan Doherty loves front-end optimization. A lot.

So much, in fact, that he’s working on bringing it to the masses.

I just wanted to blog quickly to show the difference CSS and JS compression can make on perceived load time. I encountered this when working on a new mozilla.com page for download stats.

First, let’s look at how we were at the beginning:

Document Complete Fully Loaded
Load Time First Byte Start Render Time Requests Bytes In Time Requests Bytes In
First View 16.795s 0.992s 13.086s 16.795s 51 309 KB 16.795s 51 309 KB
Repeat View 2.533s 0.883s 1.622s 2.533s 5 19 KB 2.533s 5 19 KB

Next, let’s look at how we were after we concatenated and minified all our JS using YUI compressor:

Document Complete Fully Loaded
Load Time First Byte Start Render Time Requests Bytes In Time Requests Bytes In
First View 11.546s 0.933s 6.455s 11.546s 38 242 KB 11.546s 38 242 KB
Repeat View 2.679s 0.919s 1.671s 2.679s 5 19 KB 2.679s 5 19 KB

Finally, after some prodding from Ryan, I concatenated and minified all CSS:

Document Complete Fully Loaded
Load Time First Byte Start Render Time Requests Bytes In Time Requests Bytes In
First View 10.892s 0.826s 5.732s 10.892s 35 238 KB 10.892s 35 238 KB
Repeat View 2.285s 0.881s 1.435s 2.285s 5 20 KB 2.285s 5 20 KB

In summary, concatenating JS and CSS can make a huge difference, and I saw it today. Here was the progression:

  • 13.086s – nothing
  • 6.455s – JS minified
  • 5.732s – CSS minified

We saved about 56% of our load times and reduced the overall number of HTTP requests by 31% (38 down from 51).

Took me about 30 minutes to figure it all out and fix some 404s and path issues caused by moving CSS around. 30 minutes for that kind of improvement is worth the investment.

Note, you’re going to want to automate using the compressor. It becomes a pain in the ass to manage over time unless you do. But it’s not hard to write a build script to run every time you make an update. It’s also not difficult to have production vs. development flags in your site config to flip which css and js files it uses so you don’t spend time trying to debug a minified bumble of JS or CSS. Even with minor maintenance and deployment hurdles, it’s still very worth the trouble.

And don’t forget, less HTTP requests and bytes transferred means a happier planet.

Update: after pushing to production, performance was even better:

Document Complete Fully Loaded
Load Time First Byte Start Render Time Requests Bytes In Time Requests Bytes In
First View 3.707s 0.906s 3.365s 3.707s 40 301 KB 4.933s 48 313 KB
Repeat View 0.129s 0.601s 0.496s 0.129s 2 1 KB 0.781s 4 2 KB

So yes, it does help to have fast servers, good hardware load balancing, and a quick proxy cache too. 🙂