RSS
 

Author Archive

That’s What He… is Sorry For

20 Apr

Two recent blog posts have called me on my bullshit and I owe everyone an apology.

First, Jessamyn Smith wrote about Fighting Sexist Jokes the Geeky Way, and then Katie Cunningham—whom, though we’ve never met in person, I consider a friend from the Django community and Twitter—wrote about being told to Lighten Up.

Neither of these were, as far as I know, directed at me, but I feel like they still effectively called me out on contributing to our culture the wrong way, with scottbot.

Reading Jessamyn’s post (go read it, I’ll wait) I couldn’t help but wonder if the original bot had been scottbot. And—selfish as this reaction may be—that didn’t make me feel good.

I’m not usually proactive about helping make open source more diverse and more friendly to diverse groups. I could make excuses but ultimately, even though it’s important to me, it’s never something I’ve put time into. But I’m not going to be proactive in making it worse, either.

Scottbot was an interesting programming question. “Can we make a bot that learns to make these jokes better?” I didn’t think about the broader implications. Not thinking about it is a big part of the privilege hegemonic groups have. I can’t go back in time and stop myself from writing it but I can recognize it, call it out, and take action.

  • First, I’m sorry.
  • Second, I’ve removed the scottbot repository from GitHub. I can’t, and wouldn’t, do anything about the existing forks, but I don’t have to keep distributing it. The code is so simple as to be really boring, and while the bot could be edited to say something else, why? There’s a limited set of use cases for a Bayesian response bot.
  • Third, I removed the scottbot package from the npm registry. With the recent password reset stuff on the registry, it took me a little while to figure out how to log in again. But it’s gone now.

Scottbot was my copyright under the WTFPL, so people who have it can still distribute it, but I’d ask them to think about it, first, and think if they’re contributing to the right kind of culture but using or distributing the code.

 
6 Comments

Posted in Articles

 

Developing a Culture of Testing

16 Apr

I say this all the time, but Mozilla’s webdev group has grown a lot over the past few years, and I don’t just mean in size. We’ve become better engineers, a better team, too.

One key aspect of that growth, and a dramatic shift from three years ago, is developing a Culture of Testing.

It’s nearly impossible to find a developer who will flat-out disagree with the statement, “Testing is good.” But it’s easy to find developers who don’t write tests. There are lots of ways to rationalize not writing tests, like…

  • We have tests but they’re slow and old and not worth updating.
  • We’re trying to move quickly here!
  • Management won’t give me the time.
  • QA should write tests.
  • And many others.

Back around when I started, we were guilty of this. When projects had test suites at all, they were too slow to run frequently, often filled with broken or out of date tests, and generally not very valuable. Most projects had some form of automated Selenium test suite, but that was about it. Nothing in the project code itself.

Now all major projects, especially new ones, have automated test suites. We look at something like 90-95% line coverage in those suites. How did we make that change?

We took a few specific steps. We didn’t necessarily plan these, but in retrospect they are pretty clear, repeatable actions that other teams should be able to adapt and use.

  • We started with the premise that tests are good. This isn’t always trivial, and you may need to convince people. Tests are an investment, because they do take more time up front than not testing, but they will pay off in the long run in faster development and fewer regressions.
  • We required tests for new code. We were in a fortunate position, beginning to move two web apps to a new language and framework, but with a little investment in bootstrapping the test suite, this should work anywhere. The lead developers of those two apps simply required tests as part of code reviews. It’s important to be consistent and firm, especially at the beginning, to establish expectations.
  • We set up Jenkins. Any CI service will work. It doesn’t need to be perfect, either. At first, we had Jenkins polling our Git repo for changes every few minutes. Later, we got it to run tests on push instead of pull. The important things were that we were running tests soon after commits and results were reported in IRC. Getting feedback immediately is critical.
  • And we set up the CI Game plugin. It doesn’t matter so much now, but gamifying tests helped motivate people to write them and fix them (and fix code standard violations) early on.
  • We made broken tests priority zero. If someone pushes code and breaks tests, they are expected to drop everything else and fix the tests. This is a big part of keeping master/trunk shippable. If you deploy continuously, it’s even more critical.
  • We tease people who break tests. Not cruel mockery, but light social pressure is a powerful tool. Peer pressure: it works!

Over time, the team internalized these expectations, shifting our development culture in real ways.

  • A feature isn’t done unless it’s tested, so the time to write the tests is not counted separately from the time to write any other code.
  • Everyone is responsible for tests, not just QA. We’ve freed up a bunch of our web QA engineers’ time to do more exploratory testing of new features and improve both automation tools and old, crufty test suites.
  • Tests are first class code, and improving methodology or performance in tests is as valid a use of time as anywhere else.

Because these changes have happened across the entire group, new team members are surrounded by this culture, adopt the practices, and internalize it very quickly.

This was a very successful shift, and has helped the team grow in a number of ways. The specific actions might not work for every team, but they worked for us and are definitely worth trying, if you’ve been struggling—or are just starting—to adopt great testing practices.

 
1 Comment

Posted in Articles

 

Better

19 Feb

A week or so ago, I needed to say that I wasn’t OK. Thanks to everyone who offered support and kind words, and especially my cousin Jono who drank beer and talked about Star Wars and other things that don’t matter at all. That all helped.

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.

Edit: Thanks for the kind comments on this post. I took them to heart, but decided to keep them private.

 
Comments Off

Posted in Articles

 

Not OK

06 Feb

I’m not doing OK right now.

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.

 
Comments Off

Posted in Articles

 

Performance is a Feature

30 Jan

What do I mean when I say “performance  is a feature?”

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.

 
Comments Off

Posted in Articles