So did saying I wasn’t OK. I still think that needs to be acceptable. People need to know it’s OK to feel bad and need help or a hug or whatever.

I was reading about the online disinhibition effect (the polite name for the Greater Internet Fuckwad Theory) and two things struck me.

• “Solipsistic introjection” may win the title for scientific-term-furthest-from-lay-term, which would be “It’s all in my head.”
• Many of the same things that enable GIFT behavior (in particular solipsistic introjection and asynchronicity) give writing on a blog a great opportunity for emotional catharsis.

If I write in a diary or journal, I know exactly who my audience is: no one, ever. Text goes in and even I don’t read it again.

But if I write on this blog, the audience is entirely unknown. It might be just me, or a hundred people, or whatever, in my head, I really need it to be. Since it’s asynchronous, there’s no expectation of a response, anyway, so it’s easy to unconsciously make everything work out.

And saying I wasn’t OK helped. So I hope that saying things are better will also help.

Not fantastic, rainbow and sparkle wonderful, but better. This is a challenging quarter, but a few things on my plate have sorted themselves—I sorted some of them, and I should take credit for and pride in that—one way or another. I’m taking this upcoming week off to decompress, relax, and charge my batteries for the rest of it. This will be a “take care of myself” week.

The past few weeks has made me realize that my anxiety is back, and has been for a while. I mentioned panic attacks: they were bad, near daily, toward the end of college. It’s not nearly that bad right now, but I’d like to change direction before it gets there. It puts an unpleasant edge, a tenseness on everything.

I got a recommendation for a shrink, making that appointment is part of take-care-of-myself-week.

The trajectory is good. Things are settling down and I feel way better than the other day—that was a particularly tough day and a real nadir. Not as good as I think I’d like to, though, so it’s time to be proactive about staying on a path toward better.

Why is that so hard to admit?

It’s nothing big, it’s just a hundred small things and they all happened at the same time and it feels like I can’t win right now. It feels like if 12 hours could go by without something getting a wrench stuck in it, that would count as a victory right now. It feels like I’m losing Tetris: there’s just not enough time to figure out what to do and the wrong piece is on deck.

I had a panic attack this morning. I haven’t had one of those in years.

But you can’t just say, “I’m not doing OK.” On Twitter it’s an emotweet. On Facebook it’s the sort of thing that gets posted to reddit as being ridiculous. It’s First World Problems. It’s whining. Everyone else has problems, too. Men don’t whine about it, they just get it done.

I don’t need advice, and I don’t even necessarily need help. I think if I had an emotional reset button I could start over and handle everything.

I really just want a hug and someone to listen and tell me it will be OK.

There aren’t a lot of places you can say “I’m not doing OK.” But this is my blog, and I can say whatever I damn well please.

For a long time, I got this wrong. When I explained myself, I’d say that performance was as important as any other feature and worth spending as much time on as any other feature, and you shouldn’t trade it lightly, like you wouldn’t trade any other feature lightly.

The thing is, especially on a small team, you might not come back to any particular feature for a few months. So, would this mean you only come back to performance every few months?

Thanks to Mike Brittain at Etsy, I’ve figured out just how wrong I was.

Performance is a feature, and just like any other feature, it must be continuously monitored and tested. What happens when a test breaks or a regression is found in any other feature? Regressions are usually considered top-priority bugs. The same must be true for performance regressions. Just because your small development team isn’t focusing on a particular feature at the moment doesn’t mean it’s OK to break it.

Performance testing isn’t exactly like most feature testing, but that doesn’t matter. One of my favorite statements from a QA lead boiled down to “don’t get hung up on the tool, focus on what you’re assuring.” Use the tools—like graphs, external and on-site performance monitoring—you need to use to make sure performance doesn’t regress.

I didn’t really realize until today exactly what I owe to Steve Jobs’ vision and dedication. So much of my life and career has been influenced and guided by an interest in screwing about with computers that goes back to the first Mac Plus I had—with its whole 1 megabyte of RAM and 40-megabyte SCSI hard drive—and my dad’s Macintosh II at work.

It’s a long, meandering story and probably not terribly interesting, but it really starts in 1993 or so, with Macintosh, and leads inexorably to my entire life now.

Thank you, Steve.

I suspect they matter to a lot of people.

Since I’ve been doing a lot of interviews lately, I’ve been thinking about how candidates can help themselves, the things that I need to know, and how someone starts themselves off on the right foot.

• Have a resume or CV. I know it feels archaic and yes, Github weighs more in my decision-making, but there’s a reason these documents have existed for so long: I need to know where you’ve worked and what your job was. This stuff matters. You don’t even need the fancy PDF (please, no .doc or .docx, though .rtf is fine) just have a thorough, up-to-date LinkedIn account. And put in details! Brag! What were your roles, your responsibilities? What new processes or tools did you introduce and how did they help? How did you kick ass?
• Have a Github account. I will accept BitBucket, but the UI isn’t as nice. (Also, I use git, we use git. Learning git is a good idea.) Put your website on Github. No one is going to steal your personal site and make millions, and it gives me some guaranteed code to browse. But way more importantly…
• Contribute to open source projects! This isn’t just “Mozilla likes Open Source,” though we do (and I do). This is about code samples. Often when we have to ask for code samples, we get contrived projects that don’t solve any real problems. Contributions to real projects show me how you write real code and, at the same time, how you work with others. Open source projects are communities, teams. Do you communicate well in pull requests or bugs? Do you revise patches based on feedback? Or, as a maintainer, how do you treat contributions from others?
• Have a blog. The cool thing is that I don’t even care if you write about code. In fact, I’d love to see that you write about other interests! But because it’s another website (I am looking for web developers, after all) and it’s yet another form of communication for me to think about. This is especially if you know you get nervous and don’t interview well.

And that’s it! Well, OK, that’s not really it, not even close. But these are mechanical things, things that are easy to do, for various values of “easy.” I notice the absence of these things.

Obviously there’s a lot more involved, but this is basic information that helps me, and helps me before we even talk. That’s a great place to start an interview.

They mean “mean time to detect” and “mean time to resolve,” respectively, and they refer to how long it takes to detect an issue in production, and how long it takes to resolve that issue once it’s detected.

As we move toward continuous deployment, these are two of the metrics we’ll be using to gauge the effectiveness of our tools and processes.

For major production issues, our MTTR is actually fairly good right now—if it’s something that cannot wait until the next scheduled release, it takes us 60-90 minutes from becoming aware of an issue to pushing a fix. I think we can do better with better release processes, but we’re starting off pretty good and going to get better, which is great.

Our MTTD, on the other hand, needs work. SUMO 2.8.1 upgraded Django and included a sweeping change to our CSRF protection—this necessarily affected every form on the site. We discovered three related issues that warranted immediate hotfixes, but we didn’t discover two of them for almost two days when our contributors brought them to our attention.

It’s great that our contributors pointed out these issues to us. Our community is a critical part of “detection” and I want to encourage everyone to point out issues in the forums or IRC. It’s extremely helpful!

But there are things we can do, too, to notice things faster. One thing we are working to add is business metric graphs. We have useful data in Ganglia right now, but we will be using Graphite and Etsy‘s StatsD to peer into what our users are doing. If we deploy a change and notice that no one is previewing articles, for example, we know immediately that we have an issue and can start diagnosing and fixing it.

If you follow SUMO development, you’ll hear us start using terms like MTTD, MTTR, “detection,” more, and talking about how to reduce them. We welcome your input and ideas as we start working on these challenges. And of course, keep telling us when things are broken!

It’s built in Node.js on two libraries by the inimitable Harth Vader, more commonly known as Heather Arthur: nomnom, an excellent argparse/optparse implementation for node, and brain, a machine learning library with neural net and Bayesian classifier support. So thanks, Heather!

I’m also using a slightly hacked node-irc from Martyn Smith.

Right now it’s a pretty simple Bayesian method. It’s been learning all day on Moznet and has made one or two pretty-good jokes, and a couple of stinkers. I think it’s already better than our other TWSS bot.

There’s plenty of things to do to improve it. I don’t know a whole lot about machine learning or anything Bayesian beyond what I can recollect from my old stats-for-math-majors class, so if you’ve got any suggestions, I’d love to hear them (especially in the form of pull requests)! I want to learn, too.

If you’ve got node and Redis, you, too, can have your very own scottbot.

Scottbot, and it’s default IRC nick, “mscott,” is named affectionately after Michael Scott.

I feel many things today. I’m deeply proud and humbled to be a part of the Mozilla community and contribute in my own small way to what I honestly believe is a fantastic product and the best choice in web browsers right now.

I’m filled with joy at seeing a product so many people have worked so hard on finally get released to everyone.

And I’m a little bit sad that I’m not in Mountain View for the release.

Finally, I’m excited, because just in the time I’ve been at Mozilla, the web has gotten so much better.

• All the modern browsers are fast.
• Browsers quickly getting more secure.
• Modern browsers are so much more capable.

The future of the web is bright. There are challenges—not just for Firefox but for the web itself—but I’m confident we have the ingenuity and passion to overcome them.

So if you haven’t tried it yet, go get Firefox 4, and experience a better web!

Here are my favorite parts:

• App tabs.
• Panorama.
• WebGL.
• Developer console.
• Fast, fast, fast!
• Tabs on top.
• Switch to Tab.
• Sync.
• Restartless Add-ons.

• Hashtags.
• Retweets.
• Location.
• Search.
• Lists.
• Conversation view.
• Inline images and links.
• Short URLs.
• The entire mobile user experience.

All of these appeared in user behavior or other clients or other apps first, and Twitter picked them up into their clients, or bought the client outright.

I’m for picking up features from clients. I think it’s fantastic: a feature can be effectively tested among a small group via a niche client and if it’s compelling and popular, well, you may want to steal it for the whole userbase—or not, of course.

The comparison that sprang to mind was the Firefox add-ons ecosystem. Something can start as an add-on (say, Tab Candy or Personas) and if it’s popular and a compelling feature, sometimes it gets picked up into the product (Panorama, Personas). Other times (Firebug, Adblock Plus) it is incredibly compelling but not for everyone, and it doesn’t. (Or, in the case of Firebug, some of the ideas, if not the implementation, were picked up.)

The point of all that, to borrow a phrase from Jeff Chausse, is that thinking you will “inevitably make better apps [is] epic hubris.”

If 90% of user access to Twitter is through official clients, like they claim, then they are overstating the threat of “fragmentation” of the user experience, and doing so in a way which discourages anyone else from trying to do better, or simply different. (Unless, of course, they aren’t putting any technical teeth behind it, but in that case why say anything at all?)

Considering how much of the current Twitter experience was invented outside the company, it seems like this is indeed epic hubris.

NB: As all content on this blog, this post is my personal opinion and should in no way be construed as representing my employer.

Well, we landed two things:

• Initial JavaScript tests. (And for showfor.)
• Stuck a crontab in git.

I said these two things would bring us up to an A, so, way to go team!

We entered this quarter with 5 goals around Continuous Deployment. We’ve hit three. The other two were stretch goals, and it looks like we’ll miss them. It’s been a particularly busy quarter for IT, and there’s just a bunch of work left to get the JS tests into CI. We’ll carry those forward into Q2 along with our goals of releasing every week and dropping the ‘next’ branch.

I’m really proud of my team and the work we’ve done this quarter. We’ve not only done great work improving the user experience across the site—especially for mobile users—we’ve also made significant progress toward simplifying and streamlining our releases, which will be crucial to CD.