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.

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.

I can’t even tell you how thrilled I am. I try to choose jobs based on how much I’ll learn from the people there, and everyone I know from Pivotal is amazing in that respect. Plus, although I’ve enjoyed my last four months of unem^H^H^H^H consulting…I’m ready to go back.

It defines relations (tables), attributes (columns), tuples (rows), and a whole relational algebra that spells out in detail what you can and cannot do to them. It is logically consistent, and in an odd way almost fractal in the way it treats its entities – subtables are tables, subrows are rows, and so forth.

It’s too bad, then, that no modern database implements more than a bastardized version of the relational model, isn’t it? Even SQL, the most standard and common method of accessing databases is a twisted orc to the relational model’s Galadriel.

The most glaring difference is that the SQL standard allows duplicate rows if there’s no unique constraint on the table. Under the relational model, tables are properly sets (as in the mathematical concept) of rows, which means no duplication. Most people who design SQL databases know, of course, that duplicate data is bad (mmmkay) and thus set unique constraints, but it’s really easy to get duplicate rows in a query result (which is also, technically, a table), especially when joining or unioning.

The other major difference between the relational model and its implementation in SQL is that the SQL standard allows null values. In other words, a row doesn’t have to have values in every column. Under the relational model, though, rows are properly tuples, another dusty math concept (for me anyway). Tuples can’t have null values.

One might reasonably ask why these differences matter. Would we be better off if SQL were a full implementation of the relational model, or would we all just be cranky because we had no way to represent lack of data in a row? Come back tomorrow for part 2 to find out.

(You should buy CJ Date’s book. It is all sorts of awesome.)

In 2009, I co-founded a nonprofit, and lost my corporate job.

In 2009, my baby turned one and my preschooler turned four. Life at home was…chaotic. Sometimes work was a haven. Nobody there ever asked me to feed them.

I’m looking forward to 2010. I hope I’ll reach more people with the workshops, find engrossing work, and get more sleep than I did last year. I hope you get more of what you want and need too.

I’m in Hawaii for the Aloha on Rails conference. The last session on Monday was a panel moderated by l4rk that included Obie Fernandez, Pat Maddox, Blake Mizerany, and Tammer Saleh. The topic: “Is Agile Too Slow?”

Ostensibly we were there to talk about whether there were any circumstances under which agile practices actually take too much time. As Obie, Pat, and Tammer talked about their preferred set of agile development practices, and how they’d never take a client who didn’t want to use them, it hit me that the whole premise of the question they were answering was just…wrong.

Agile is not about checking off every entry on a checklist of practices. Agile is about adapting your process to fit the project you’re on. If you think that every project absolutely must have tests, you’re not agile. If you think that every project absolutely must be storycarded, you’re not agile.

If you can’t adapt your process and add or drop practices as appropriate – including dropping down to no process at all when it makes sense – then you might as well be doing waterfall.

Agile is never too slow. Dogmatic adherence to practices, on the other hand, is.

I’d love to find a job where I could write complex, interesting Ruby and/or Rails code four days a week, and work on growing the Ruby community (via the RailsBridge workshops, hackfests, and other new stuff!) one day a week.

I and the rest of the organizers of the Ruby workshops have already made a measurable impact on the SF Ruby community. At the last monthly meetup, we had about 9% women, compared to the 2-3% that was previously typical. We have lots of great ideas for programs that build on these workshops and other stuff we’ve been doing. But since we all squeeze this stuff in on nights, weekends, lunch hours, etc., it’s been hard to find the time to get anything new started while keeping the workshop momentum going.

Is it crazy to ask a company to sponsor me at 20% time to grow and amplify this work? Possibly, and it certainly has to be coupled with something fun and challenging to work on the other 4 days. But I think this job exists, or could exist. There are quite a few companies out there who’ve bet the farm on Ruby. I’m sure they’re interested in making the community stronger. That’s what I’m interested in too. Let’s find some way to work together.

sarah mei at gmail is the place to go.

I wrote an article for the RailsBridge Teaching Kids site about my experience teaching Ruby to high school girls a few weeks ago. Go read it over there!

That site doesn’t have comments, though, so I’m linking back here because I’d like to hear your comments and suggestions for improving the program.

Thanks!

I’ve been going to Women 2.0 events on an off for a couple of years. Most of their events have focused on the business side of startups and entrepreneurship – at a wine & cheese mixer last year, I was the only developer in the room! But they are expanding their charter to include technical women, and particularly technical women as startup co-founders. If you’re interested in the small-company experience, or maybe even in launching your own, this is great opportunity to network with some amazing and energetic people who are out there doing it.

This is W2.0’s first technically-focused event, and their first event in San Jose too. Register here, and if you need a ride from San Francisco, leave a comment – I’m in the South Park area.