September 2011

Dave Winer: Facebook is scaring me.

Me too. The thing about sharing-just-by-reading makes me sick.

Of all our freedoms, I value intellectual freedoms the most: the freedom to read whatever the hell I want, for whatever reason, without having to tell anyone else what I’m reading. (Or the freedom to tell everyone who’ll listen — but only if I want to.)

I’m suddenly curious to read a history of the East German Stasi. My theory about it is that people found it fun to report on other people. And I bet that at least some people found it thrilling that they were the ones being watched. (Those being watched probably watched other people in some cases. It’s a social graph.)

It satisfied part of the same thing that makes Facebook fun for people. And so I think of Facebook as a descendant — automated, corporate, shinier, fizzier, with no agenda but the pure collection of information on you, me, and everybody else.

Despite having no explicit political agenda, that agenda is still a totalitarian agenda, because it wants to know everything.

I wrote about Core Data last year, about how I was switching away from it for one of my apps. The post achieved some notoriety, and to this day people reference it as if I wrote a scathing takedown of Core Data.

Which is not true at all. Here’s what I wrote:

I bet Core Data is the right way to go 95% of the time. Or more. It’s easy to work with. It’s fast (in most cases). It has schema upgrade tools.

Since that post I’ve used Core Data in other projects. NetNewsWire Lite 4.0 for Macintosh is a pretty big example of a Core Data app.

At the moment I’m finishing switching my current app over to Core Data. (It will still use FMDB + SQLite for a few things, but the main storage will be Core Data.)

This may come as a surprise to people who have it in their head that I’m the guy who doesn’t like Core Data. So I’ll say this — on top of all the other good reasons to use Core Data, here’s another: Core Data is the standard Cocoa object persistence system.

When it gets better, our apps get better. (And it does keep getting better.)

And, more importantly, as the standard it means that any Cocoa developer — a teammate or someone who acquires the app — can jump in and quickly understand how it works.

Yes, your custom thing may be better for your app. But will it stay better? And if you bring someone on to help you, how quickly will they learn your custom thing?

Use Core Data.

For years I wrote software with the absolute certain knowledge that nobody would ever see my code. I was a solo developer. Who besides me would ever see the code?

That certain knowledge turned out to be completely wrong, as I discovered when we sold MarsEdit to Daniel Jalkut back in 2007.

But still, even with that, I was dead sure that nobody would ever see the NetNewsWire code. But even that turned out to be wrong, once we sold it to Black Pixel. And we also sold TapLynx to push.io.

In other words, all of my code (except for my current app) has ended up in other people’s hands.

Like (hopefully) every developer, I work hard to get better every day. (For good developers, I think there’s a kind-of Moore’s Law: your code quality doubles every 18 months. Not that I would know how to measure that, but it feels about right.)

But now I write code with the absolute certain knowledge that it will end up in somebody else’s hands. I could be wrong, yes, but I’ve learned that it helps me write better and more-maintainable code if I just assume from the start that somebody else, most likely a friend, will end up working on that code base.

In theory, I shouldn’t have to think that way: I should do the same good job no matter what. But I don’t care about theory: if it helps me to think that way, if it helps remind me to go the extra mile to make it good, then it’s a useful way to think.

You’ve heard it before, that future-you is also a different person. While that’s true, it doesn’t have the emotional weight of an actual different person working on your code.

So the lesson I’ve learned is this: that other person is out there, and there’s a good chance I already know him or her. I want that person to be happy when they go to work on my code. I want them to not curse my name and the horse I rode in on.

I use Xcode 4 mostly, but I still use Xcode 3 sometimes for a project that needs it (because it needs the OS X 10.4 SDK).

I started using Xcode 4 in March, and I’ve written a brand-new app using it, so I’m not new to it or just now getting used to it.

There are a ton of things I like about Xcode 4. It’s more rational and better-organized in a bunch of ways. The team did a great job thinking things out. There are new features that I appreciate and use. Xcode 4 is a fantastic upgrade.

And yet it makes me feel tired, as if I’m doing the same things over and over. Xcode 3 doesn’t make me feel this way.

I decided to pay attention to this feeling — what makes me feel that way? It turns out it’s pane management.

One big window

Xcode 4 uses one big window for the source list, editor, info panes, debugger, text snippets, interface builder, etc. It’s much like Eclipse and Visual Studio in that sense.

I imagine there are two reasons for this (but I’m just speculating):

1. Lots of developers are coming from Eclipse and Visual Studio, and they’ll find this layout more familiar.

2. This saves the developer from the trouble of managing multiple windows.

I can’t argue with the first reason. I could say it doesn’t matter, that the App Store is full of apps even without an Eclipse-like or Visual-Studio-like Xcode, but I don’t know what the Xcode team knows and I don’t know what’s been asked of them.

But I can argue with the second reason. Here’s why: the only thing worse than managing multiple windows is managing multiple panes.

Why pane management is worse

The best part about multiple windows is that I can make them any size I want and put them anywhere I want. I can have different windows for different tasks that need different layouts and sizes. A single window with panes doesn’t bring that flexibility.

Example: debugging

With Xcode 4 the debugger appears in the main window. When I’m finished I usually (but not always) want it to disappear, so I can get the pixels back for source code editing. Which means I have to hit the hide-the-debugger key command. Again. For the nth time that day (where n is beyond a comfortable number).

Another issue: if the best window size for editing is 1500 pixels wide, but the best window size for running the debugger is 2500 pixels wide (I’m making up these numbers), then I’m in a pickle. Do I resize the main window? Or pick a size that’s less-than-good for at least one of my common tasks?

Another example: interface builder

I often like to have the counterpart pane open. But then I open a .xib file — and I can’t see the whole thing because the counterpart pane is open. So now I have to close the counterpart pane, and possibly open the Utilities pane if it was closed before.

How much better if I had a separate window that was already the right size and set-up the way I want it?

Wishes

I get it that Xcode 4 probably needs one-big-window as its suggested and primary interface. And I also realize that it’s possible to open multiple windows.

But I do wish I could make it work more like Xcode 3. A separate window for debugging, for build results, for laying-out UI. These tasks are all different enough that using a single window becomes an exercise in pane (I’m tempted to write “pain”) management. And my time and yours is too valuable for that.

And I just don’t want to hit shift-cmd-Y one more time.

It’s a big step forward for The Loop. The crazy ads and clutter are gone. It’s readable and handsome. Jim and Peter should be proud.