In practice, I’ve discovered, it’s another story entirely. After spending the better part of ten days, recently, integrating Facebook into another website, I have new rules for how I use Facebook. I realize they sound a little tin-foil-hat-style crazy, so after the rules I’ll explain a bit about why I adopted them.

Image by CycleDog

Rule 0: I’m not closing my Facebook account. I know a few people who have gotten off Facebook entirely, recently, but Facebook is the only place I’m in touch with my cousins who live out of state, my best friends from elementary school who are scattered to the wind, and my husband’s family who live on the east coast. These people aren’t going to get on Twitter, and I do want to hear about their lives.

Rule 1: I always browse Facebook in a separate browser. If I’m doing my random web browsing in Firefox, then I open Facebook in Chrome (or less frequently, Safari). It’s not sufficient to open Facebook in a different window of the same browser, or a different tab of the same browser. It has to be a different browser. (If you only have one browser right now, you can install Firefox here, or Chrome over here.)

Rule 2: I make sure my non-Facebook browser has no residual FB cookies. I used to just leave a Facebook tab open while I browsed random web sites in other tabs, but that’s incredibly dangerous. If I am logged in to FB, any of those third-party sites could be silently collecting my Facebook information without notifying me. Once I decided to separate my browsing, I deleted all cookies in my non-Facebook browser. As long as I don’t log in to FB again in that browser, other sites won’t be able to access my Facebook information.

Rule 3: I never browse anywhere else in the Facebook browser. I use Chrome for Facebook, so I don’t use Chrome for anything else. Any external links I want to click on from Facebook, I open in Firefox. This can be a pain in the ass because links on FB usually redirect you through another FB page. So in FB, I right click the link, select “Copy link location”, switch to Firefox, paste the link in, edit it to remove the Facebook prefix, and then hit return to go there.

In practice, I do use Chrome for other stuff, but I log out of Facebook and clear all my cookies first. Which leads to…

Rule 4: I always log out of Facebook. They’ve hidden the log out option; it’s at the top right, the last option under “Account.” It’s not sufficient to close the Facebook window, or even to quit the browser you’re using for Facebook. In either case you leave behind a set of “logged in” FB cookies that other sites can read. I always explicitly log out of FB when I’m done.

Rule 5: There is no rule 5.

Rule 6: I never use Facebook to log in to another web site. Any web site can use Facebook as their log in system, instead of (or in addition to) letting visitors create accounts. Most of these sites are not officially affiliated with Facebook. It’s convenient to use FB for this, sometimes, instead of creating yet another username and password to remember.

But it’s also dangerous. When I authorize a site to use Facebook to log me in, that site can then access my name, my email address, all the schools I went to, all my employers past and present, my interests and hobbies, my pictures, my wall, my messages, and my friends. Among other things. And the site may hold on to that data, so even if I change it or hide it in Facebook, it’ll be in their database in perpetuity. Since the site isn’t affiliated with Facebook, it’s not bound by their privacy policy, so who knows what it will do with the information? It’s way better to just set up another account with a throw-away username and password.

Feeling crazy yet?

I am. Or maybe “paranoid” is a better word. Before I started working with the Facebook API, I had no idea how much information was available to third-party web sites. Things I don’t think of as public – including my email address – are available by default.

There are, of course, terms of service that those sites have agreed to, but nobody checks or audits them. It’s trivially easy to sign up for a developer account, create a Facebook application, stick some Javascript on a site, and start collecting the data of unwary FB members who visit you.

The public/private dilemma

Honestly, most of the information I have on Facebook is public knowledge anyway, including my email address. But it doesn’t sit well with me that FB lets third-party sites access information that non-friends can’t see. What else might they decide to share someday – the links I’ve clicked on? The groups I’ve visited but not joined? The exes I’ve searched for?

By keeping Facebook quarantined, I hope to contain the fallout of any future “experience enhancements.”

And now, if you’ll excuse me, I need to go use my hat to make dinner.

How do you start, and how do you know you’re finished? What do you test, and where? These questions can be answered hundreds of different ways, but here’s my way.

The first code I write: a feature

As a developer, rather than a designer, I’m always tempted to start with unit tests and work out towards a cucumber feature (“inside-out” testing). But that approach gets me into no end of trouble. I usually end up writing and testing stuff on the model that I don’t ultimately need. Plus once I’m down in the weeds coding, I lose track of the big picture.

So I like to do outside-in testing instead. I start each story I get from tracker with a cucumber feature that expresses how the PM will be able to accept it when I’m done. The feature helps me frame the problem properly, and focus on doing exactly what I need to make it work. Since I come back to it periodically while I’m coding, I keep focused on the higher-level goal. And finally – if I write it first, I can’t skip writing it once I’m done.

Before we get going…

There are certain types of tests I don’t write in this example (and in some cases, at all). Let’s get those out of the way so you don’t have to come up with a scathing comment at the bottom of the post.

• Model tests. In this example, my model doesn’t do anything other than default ActiveRecord behavior, so it doesn’t need any tests. Don’t test rails internals. Once my model has custom behavior, it will have specs, too.
• View tests. I have no tests that verify that my markup is what I expect. That’s because they’re a waste of time. Yes, even with complex views. Verify behavior with cucumber tests, unit-test Javascript with jasmine, and leave the rest to the humans. You’ll waste more developer time maintaining them than it would take humans to verify them. Verifiers are a whole lot cheaper than developers.
• Error case tests. In this example, there are no error cases. The model has no validations, and the table has no constraints. Once there are error cases, I generally put those in the model if I can, in the controller when I have to, and never in the cucumber tests. The latter is mostly a suite-speed consideration – cucumber tests run much more slowly than rspec. Cucumber’s great for for happy path tests; I leave the rest to rspec.

Let’s get going!

The first feature

Say I’m doing a library app and the first story is “User can enter a new book into the system.” Before I write any other code, I write this feature:

Feature: User manages books
  Scenario: User adds a new book
    Given I go to the new book page
    And I fill in "Name" with "War & Peace"
    And I fill in "Description" with "Long Russian novel"
    When I press "Create"
    Then I should be on the book list page
    And I should see "War & Peace"

Starting the fail-fix cycle

I run it using cucumber features, and it fails on the first line – Given I go to the new book page – because cucumber doesn’t know where the “new book page” is. So I add that to the cucumber paths helper.

    when /the new book page/
      new_book_path

Now when I run cucumber, it fails because it can’t find new_book_path. So I add that to routes.rb:

  map.resources :books, :only => [:new]

Now when I run cucumber, it complains that it can’t find the BooksController. That means it’s time to dive down to rspec controller tests.

My first spec experience

I create books_controller_spec.rb in spec/controllers, and add a test for the new method:

require File.expand_path(File.join(File.dirname(__FILE__), '..', 'spec_helper.rb'))
describe BooksController do
  describe "#new" do
    it "should be successful" do
      get :new
      response.should be_success
    end
  end
end

When I run this spec, it complains that there is no BooksController. Fixed:

class BooksController < ApplicationController 
end

I re-run the spec and get "no action responded to new." So I add the new method.

class BooksController < ApplicationController
  def new
  end
end

Now the spec passes! Time to check back with cucumber.

Getting past the first line

I read through my cucumber feature again:

Feature: User manages books
  Scenario: User adds a new book
    Given I go to the new book page
    And I fill in "Name" with "War & Peace"
    And I fill in "Description" with "Long Russian novel"
    When I press "Create"
    Then I should be on the book list page
    And I should see "War & Peace"

Last time I ran it, it failed on the first line because it couldn't find the BooksController. This time, same location, but it says it can't find the view. So whiny! To placate it, I create an empty view called new.html.erb and run it again.

Now cucumber gets past line 1 (huzzah!!) and fails on line 2 (And I fill in "Name" with "War & Peace") with the message that it can't find a field called Name to fill in. So I add a standard rails form to the view.

<%- form_for @book do |f| -%>
    <%= f.label :name %>
    <%= f.text_field :name %>
    <%= f.label :description %>
    <%= f.text_area :description %>
    <%= f.submit "Create" %>
<%- end -%>

Uh oh. Cucumber is mad at me because there is no @book object. Back to rspec for me!

rspec: The Return

In my controller's new method, I need to create a book object that the form will use. I first add a test for that in the controller spec:

require File.expand_path(File.join(File.dirname(__FILE__), '..', 'spec_helper.rb'))
describe BooksController do
  describe "#new" do
    before do
      get :new
    end
    it "should be successful" do
      response.should be_success
    end
    it "should create a book object" do
      assigns(:book).should_not be_nil
    end
  end
end

This fails the right way - it says assigns(:book) is nil. So then I add the creation of the book object to the controller.

class BooksController < ApplicationController
  def new
    @book = Book.new
  end
end

Now the spec fails, saying it can't find the Book class. It has a point - I haven't created the model yet. Fixed:

class Book < ActiveRecord::Base
end

Now it fails saying it can't find the books table. So I write a migration that creates that.

class CreateBooksTable < ActiveRecord::Migration
  def self.up
    create_table :books do |t|
      t.string :name
      t.text :description
    end
  end
  def self.down
    drop_table :books
  end
end

Once I do rake db:migrate and rake db:test:prepare, I re-run my controller spec....and it passes! Back to the cucumber feature!

Cucumber...again.

In our last episode, cucumber was visibly annoyed because there was no @book object for the form to operate on. I run it again to see if it's still sulking.

Yep. This time it tells me that it can't find books_path. form_for tries to submit to the create path by default, which I haven't added yet. I add it to the routes.

  map.resources :books, :only => [:new, :create]

This time, when I run cucumber, it gets through the first three lines (woo hoo!) and fails on the 4th, saying no action responded to create. Back to the rspec-cave, batman!

rspec: The Sequel to The Return

I add a controller spec for the create method.

  describe "#create" do
    it "should create a new book" do
      post :create, "book" => {"name" => "Jane Eyre", "description" => "Something Victorian"}
      assigns(:book).should_not be_nil
      assigns(:book).name.should == "Jane Eyre"
    end
  end

When I run it, I get the same message as in cucumber: no action responded to create. So I create the create:

class BooksController < ApplicationController
  def new
    @book = Book.new
  end
  def create
  end
end

Now when I re-run the spec, it fails saying that assigns(:book) is nil, which makes sense. I put in the guts of create to make that pass.

  def create
    @book = Book.new(params[:book])
    @book.save
  end

Now rspec passes! Back to cucumber.

So...cucumber. We meet again.

When I re-run the feature, it says I'm missing a template for create, which is correct. However, in this case, I don't want to make a template for create - I want to redirect to the book list page. So once again, I'm back with rspec.

rspec: Back so soon?

I add that expectation to the controller spec for create.

    it "should redirect to the book list page" do
      response.should redirect_to books_path
    end

It fails saying there's no redirect. So to make it pass, I add a redirect to the controller code.

  def create
    @book = Book.new(params[:book])
    if @book.save
      redirect_to books_path
    end
  end

Now my controller specs pass. Cucumber, I'm coming for you!

Oh, you again.

Last time, we got through the first 3 lines of the feature and failed on line 4 (When I press "Create"). When I run it this time, it gets through the same 3 lines and then fails in the same place again, saying that no action responded to index. I add index to the routes.

  map.resources :books, :only => [:new, :create, :index]

I re-run the feature and get the same error message. WTF, cucumber?! It turns out that rails' implementation of REST uses the same path helper for create and index, so the path helper for index already exists, even though the method does not. A little strange, I know. But we need an index method, so it's back to rspec.

rspec: For the first time, for the last time...

I write a spec for the index method.

  describe "#index" do
    it "should be successful" do
      get :index
      response.should be_success
    end
  end

I still get no action responded to index. So l add the method in BooksController, empty to start.

  def index
  end

Specs pass, back to cucumber!

How can I miss you if you won't go away?

Cucumber tells me there's no template for index. So I create an empty one, and re-run. This run, for the first time, I pass line 4 (yaaaaay) but then it fails on line 5 (Then I should be on the book list page) because it can't figure out what I mean by "the book list page." That goes in the cucumber path helper.

    when /the book list page/
      books_path

OMG five out of six steps pass! Now cucumber says it can't find "War & Peace" on the page, so let's make the index view list the existing books. Back to rspec...

Don't go away mad...just go away.

I add the following it block to the spec for index.

    it "should assign a list of existing books" do
      Book.create!(:name => "Endymion", :description => "weird")
      get :index
      assigns(:books).should_not be_nil
      assigns(:books).length.should == 1
    end

It fails because I'm not creating @books in the controller, so I fix that.

  def index
    @books = Book.all
  end

Now the specs pass - back to cucumber.

We really have to stop seeing each other like this.

Cucumber still says it can't find War & Peace, because I haven't added printing out the books to the index view. I'll fix that.

<%- @books.each do |book| -%>
    <strong><%= h book.name %></strong>
    <%= h book.description %>
<%- end -%>

Re-run cucumber and ... ta-da! The feature passes! I've done everything I need to call the story done. I have the minimum amount of code I need, because all the code I wrote was driven by the feature. Story: delivered!

You’re welcome to bring any sort of Ruby-related project! The theme for the evening is Javascript testing, following on this month’s monthly meetup. But I won’t make you write any Javascript if you don’t want to.

The peninsula has all kinds of neat hack events like SuperHappyDevHouse and various Hacker Dojo events. But I hate driving all the way down there just to hang out with hackers and get something done on a project. There are plenty of hackers in San Francisco. There might even be more of the type of hackers I want to hang out with.

So I’ve decided to host a monthly hack night, to be held on the Tuesday following the monthly SF Ruby meetup. My employer, Pivotal Labs, has graciously volunteered their space. Since tonight is the SF Ruby meetup, the next hack night is next Tuesday, April 27th, from 7-9:30 (ish).

RSVP now! See you next Tuesday.

It’s not enough.

On Being Smart

Google likes to hire engineers based on how smart they are. Their interviews are full of interesting algorithmic questions and puzzles. If you’re into that stuff, it’s actually kind of fun. They and Microsoft in particular are famous for interviewing this way, but smaller companies do it too. I get several recruiter emails each week for startups where I could work with “a really smart team!!! engineers with ivy league degrees!!!”

I’ve always been “smart” (instead of athletic or popular), and I grew up reassured by adults that in their world, “smart” was the crucial component of success. Imagine my shock when I discovered that it was not, in fact, sufficient.

It isn’t sufficient for software development, either.

What’s Missing Here?

My first job out of college was at Microsoft. The people I worked with were, individually, very, very bright. As a team, though, we could never get traction. The effect was subtle. At the time, it felt like we were making progress. We had a lot of really detailed discussions about different implementation options, and everyone had interesting input. We wrote a good bit of code.

But we never actually finished anything, and eventually, it turned incredibly frustrating. I had been programming for maybe four years total at that point, and never at a real company before, but I already knew I hated writing software no one used.

For a long time after I left that team, I couldn’t put my finger on what went wrong. Clearly, we were all smart. Somehow as a group, though, we were dumb.

“Gets Shit Done”

There were a lot of factors in my frustrating experience – Microsoft’s waterfall process, the ongoing antitrust litigation, and political machinations around the project, just for starters. But I think the same group of engineers in a perfect modern environment would still flounder. There were too many people on the team who, individually, couldn’t finish anything. There was always a good reason why – some new requirement that necessitated a rewrite, or some piece that turned out to be more complex than anyone thought.

As a junior member of the team, I took these explanations at face value. With the benefit of ten more years of experience, though, I know that while it’s important to write quality software, it’s equally important to just fucking finish it.

There are a lot of smart engineers who understand this, and, sadly, a lot of smart engineers who don’t. Microsoft’s hiring process didn’t distinguish, and neither does Google’s. If I were to take a job there, I might be on a team where everyone is smart and can get shit done. There are certainly plenty of those at Google, as their products attest. But I might be on my Microsoft team again, only this time with free food and scooters.

That’s about as appealing as another winter in Redmond.

Hoo boy.

It’s been a little over two months since I started, and the number of hours I’ve spent solo programming since then would all fit in one workday. I’ve had some surprising realizations – about myself, my style, and my abilities – and more than a few DUH moments. This post is more a collection of anecdotes than a coherent essay, but if you’ve wondered what full-time pairing is like, I hope it gives you a few insights.

It does contain some profanity. I blame my co-workers for that.

On Constraints

Pivotal works a strict 8-hour day, in keeping with the agile principle of sustainable pace. But because all projects are paired (you cannot buy the services of a single Pivot – we only come in pairs) everyone has to be in the office at the same times every day. So everyone arrives at 9, everyone takes lunch from 12:30-1:30, and by 6:15 the office is a ghost town.

I knew I’d love the work – and I do – but I thought I’d be fighting the schedule. Nine to six would have been fantastic 10 years ago, but now that I have a husband and two kids…not so much. There isn’t a daycare in the city that stays open past 6, and it’s much harder for me to go to doctor appointments, school events, and all the other kidly activities that are, without fail, held between 9 and 6.

The Punchline

Now that I’m doing it, I love the fixed schedule. At other jobs, around 4pm every day, I’d start wondering about when I needed to leave. I’d try to remember who I was picking up, and when, and then I’d look it up on my calendar, and then I’d text Peter and ask whether there was anything I needed to ask or tell the daycare folks, and then I’d stress about getting enough work done before I had to take off.

There’s none of that anymore. I know exactly when I’m leaving, and since my pair is leaving at the same time there’s no pressure to stay longer to finish something off. When I’m working, I can be completely present. When I’m done, I don’t have to drag a laptop home and check email or fix the build once I get there. I don’t even know how to get into Pivotal’s VPN from home. I walk out of the building at 6:05 with a clear mind and a clear schedule for the rest of the night.

It’s fucking exhilarating.

On Getting Shit Done

Fundamentally, what I love about software development is writing code that people actually use. I love to finish things. So anything that makes me feel like I’m really GSD makes me incredibly happy.

When people talk about pairing, you hear a lot about how it “amplifies” their productivity. I am going to go on record with the truth, however. Pairing does not amplify my productivity. Instead, it erases all the bad habits I have that keep me from being a superstar on my own.

When I’m pairing, I can really get shit done.

By myself, I have a lot of roadblocks:

Rabbit Holes. When trying to figure out some thorny bug by myself, I often follow the wrong line of inquiry too far. I follow it sometimes for the sake of completeness – of knowing with 100% certainty that some factor is not what’s causing the problem – when 90% or even 50% certainty would do. Something in my brain craves completeness, occasionally to the detriment of productivity, and particularly when I am tired (hello, parenthood). I usually don’t notice it when it’s happening. However, if I have to explain to someone else what I am doing, the ridiculousness of it all suddenly becomes obvious and I’m able to break out.

Distractions. If I’m working by myself, I’m on email, I’m on IM, I’m on twitter, oh my tests are running so I’ll check hacker news…and on and on. That time adds up over the day. And of course once I look at my email I’ve switched contexts so going back to my code is another context switch, and even though it may only take a few minutes, that also adds up. It feels amazing to work solidly for four hours at a time on a problem. But somehow when it’s just me, I can’t always keep that focus. I think it’s the addition of the social input and output that lets my frontal cortex actually attend to the problem at hand, without going ooh-shiny all the time.

That, and the guilt trip from my pair when I do wander.

Cheats. If someone’s watching, I don’t take shortcuts. I write the tests first. I refactor code that needs it. I focus on doing the simplest thing that could possibly work, without being sloppy. I make sure I understand what I’m doing before I do it. I’d like to say that I always do these things when on my own…I really would. But the truth is that sometimes I put logic in my view code, because christ, if I move that then I need to put it in a helper and make a new file and add a new spec, and I said I’d be done by the end of the day and it’s 4:30 and no one’s reviewing my code so…I just do it.

But if someone else is watching what I’m doing…I just don’t. That feels incredible.

Too-Clever Syndrome. On the other side, I get excited by knotty technical complexity. I love to dive in and start changing things to see what happens in situations where it would really be better to write some tests first. And, I like pushing the boundaries of the language, but I don’t work on experimental or research code – someone has to read and maintain it – so all the clever metaprogramming is really not suitable.

But it’s so much fun! And I get to revel in how smart I am! It sounds stupid to say that out loud, though. So I don’t even go there.

The Nine-to-Fiver

I often hear programmers – mostly young, mostly single – talk disparagingly about “commodity programmers.” They usually mean people who program at work but spend their free time on other stuff, and aren’t really interested in tech.

Since I became a parent, I’ve turned into that person – the one who needs to leave at a fixed time and can’t work weekends. So for a lot of my peers, that means I’m not “passionate” enough, and that I can’t really be a good engineer. I got that reaction enough times that I started to believe it. Well, fuck that. I know I am amazing at what I do, and I love it. But it’s not my whole life.

Working at a company that really respects the boundaries of my time AND enables me to kick ass and get shit done all day has seriously been a revelation.

Socialitis

On the spectrum of social awkwardness, I fall somewhere between the engineers and the marketing guys. Like many engineers, I miss social cues, don’t make enough eye contact, forget people’s names, and have a hard time making small talk. However, I can fake these skills decently well when necessary, and I’ve noticed that it’s a muscle that I can exercise – the more I do it, the better I get, and the less I have to think about it.

About a month after I started at Pivotal, I went to a UCSD engineering alumni event. At these events, where I am usually the only person not working in Enterprise with a capital E, the social interaction part of the evening is a lot of guys staring at each other’s shoes. In the past I’ve tried to get conversation out of these people, but between their awkwardness and mine it was like pulling teeth. But this time, for some non-obvious reason…it was easy. The people and the shoes were about the same.

It’s me who had changed.

Short version: it was a lot of work.

A lot of people have asked us about this, though, so it seemed worth distilling. The slides don’t convey everything I talked about. In the next few weeks I’d like to try putting together a blog post that does a better job. But for now, here they are.

Update (3/6/2010): MP3 audio is now available – thanks SCALE folks! Also, I’ve posted a PDF version of the slides for those of you without flash.

• Shoes – a simple way to create desktop applications in Ruby. Cross-platform, pure awesome. (code on github)
• Hackety Hack – built on Shoes, this is a toolkit specifically for learning how to program.
• Small Ruby – learn to program for the smaller set – think turtle drawing. Coming soon.
• PDF version of the slides (exactly the same as slides below)

LEARN ME

…is now open for registration. Last year Sarah Allen and I did three workshops for women and this year we’re going for four. So, if you’d like to learn Rails and can come BOTH Friday, February 26th in the evening AND Saturday, February 27th during the day, go sign up! There are only a few spots left.

And yep, still free.

We’re also seeking Rails developers (of any gender) to assist as TAs. Tell us about that here. Past TAs and teachers have found it quite rewarding. Plus you get a drink ticket for the afterparty.

And finally, some logistics: it’ll be in an office space in downtown San Francisco, near transit. Next week we’ll send out the exact address. We’ll have informal childcare and space for pumping or nursing – please tell us if you think you’ll be using those services when you register.

See you there!