BlogmyQuery – BMQ

If there’s one thing I’ll remember about Alex Mahernia, it’s footer spacing. Here we are at 10pm in the office and we’d be trying to launch a site. The only thing left is an A-OK from the creative director. And without fail, he’d yell at me to come into his office and point at his screen. “The footer spacing is too big on this page.” So I’d go back to battle the CSS until every single page on the site had consistent footer spacing in every browser.

Motherfucking footer spacing.

And what did it matter? Are our clients really going to lose customers because there’s an extra 10 pixels of footer spacing in IE6 on one of the pages? Is the client going to refuse payment because of these pixels? HOW MUCH BLOOD ARE THESE PIXELS WORTH?

But it was never about the footer spacing. It was about quality. It was about cultivating a culture of relentless quality in everything we produced.

Quality versus the Ego

Every time Alex called me into his office and showed me a page with an extra 7 pixels of spacing my blood pressure went through the roof. I took it as a personal insult. But he wasn’t insulting me. It was about producing a quality product.

Quality has no room for egos. Other people will have better solutions. You are going to miss things. You are going to break things. You are going to make mistakes. And people are going to point it out.

And I think it’s okay to get upset. Take that feeling and turn it inwards. Vow to make things better. Make sure you’re always producing the best quality product you can.

Move fast and break things

If you take a look at any of Facebook’s recruiting marketing, you’ll see a phrase repeated over and over:

Move fast and break things

And with good reason — the idea it embodies is fantastic. Unfortunately I see a lot of people interpreting this quote as something like this:

It reminds me of another misinterpretation that’s always bugged me:

Quality isn’t something to be sacrificed. Move fast and break things, then move fast and fix it. Ship early, ship often, sacrificing features, never quality.

Embrace change. Ship. Never cut corners.

Quality is contagious

Which reminds me of the broken windows theory:

Monitoring and maintaining urban environments in a well-ordered condition may prevent further vandalism as well as an escalation into more serious crime.

Broken windows are the reason most large software projects suck to work on. A little technical debt here, a few shortcuts there, and pretty soon you’ve got a codebase so full of broken windows that no one even cares if they throw another pile of broken glass on the heap.

But just as broken windows are contagious, so is a dedication to quality. Carve out a little piece of a messy codebase and clean it up. Sharpen the edges, polish the surface and make it shine.

The caveat here is that you can’t half-ass quality. Dedication to “semi-quality” isn’t dedication at all. High-end design coupled with mediocre engineering can only produce a mediocre result.

And I don’t know about you, but I don’t dream of building mediocre. I dream of building the best. So I’m thankful to Alex for instilling this idea of relentless quality in me, even if I still have footer spacing related nightmares from time to time.

A couple months ago I got up on stage during lightening talks at CodeConf 2011 to talk about our friendly robot, Hubot.

Inside of five minutes I logged into our Campfire room with spotty WiFi, asked Hubot a favor, and he deployed a major new feature to our site — Issues 2.0. A deploy spanning around 30 servers that changed a major feature for 800,000 users. It was pretty awesome and kind of a ridiculous thing to do.

Rewind the clock 7 years ago and I had just landed my first steady job in the tech industry — a front end developer for a big interactive agency.

I remember one of our clients had a static HTML website that I was in charge of maintaining. We had a 45 minute window occurring once a week where we could deploy their site.

Once a week, I generated a list of files I’d changed since the last week so a System Administrator could FTP the files over to production. Any changes to production I needed that occurred outside that 45 minute window required manager intervention.

Recap time.

2004

• System Administrator time required to deploy every website.
• Deploys scheduled by managers once a week.
• Manually generating lists of changed files.
• Simple deploys take 30+ minutes.

2011

• Deploying on stage for the hell of it.
• System Administrator probably drinking whiskey.

2011 is pretty fucking awesome.

Deployment is an art. And the style in which you deploy impacts your company culture more than you think. Deploy with style.

A few days ago we lifted the curtains on a project I’ve been deep into for a long time now: GitHub for Mac. This is the first OS X app I’ve designed and thought it might be interesting to share some of the process and things I learned throughout development.

Why should we build it?

For a long time I assumed OS X developers would see the immense market for an awesome Git application. Unfortunately for everyone involved, every OS X application that’s showed up over the years gave up and tried to turn CLI commands into buttons.

Clients claiming to be “simple” choose to redefine “simple” as fewer supported Git commands rather than simplifying the interaction with Git.

It blows my mind that no one tried to do anything special. Git (and its DVCS cousins like Mercurial & Bazaar) provide an amazing platform to build next generation clients — and it’s like the entire OS X ecosystem left their imagination at home.

Eventually, I (well, many of us) decided that better native clients (OSX, Windows, Linux, Eclipse, Visual Studio, etc) was the best way to grow GitHub. And since we all use Macs — we should start off with an OS X application. Build what you know/use, expand from there.

What are we building?

Personally, I had some big goals:

• Death of the SSH key. People should be able to connect to GitHub with their GitHub username and password.

• Make it obvious that there is a distinction between remote and local. Make it clear what commits need to be pushed before others can see them.

• Simplify the git fetch, pull (--rebase), push interaction. Synchronize — don’t make the user figure out what they need to do to get their local commits remote and remote commits local.

• Fix the local/remote branching problem. Get rid of this tracking idea — interact with local or remote branches as if they were no distinction between the two.

I didn’t want to replace the command line. I wanted to build an awesome version control client. As it happens, Git is the perfect backend to do that — and GitHub is the perfect central server to collaborate.

Sketches & early ideas

The first thing we did was to start populating an internal wiki full of ideas. Lots of words, lots of sketches.

Let’s get some designers on this

I’d been using OS X for years, but I didn’t feel comfortable designing a native app. My previous attempts at OS X design weren’t too fantastic…

In the end, we hired Eddie Wilson to come up with some wireframes and some comps while Joe and Josh cranked away at the Cocoa backend. His first comps were a great start, and influenced the end product tremendously.

Unfortunately right about this time is when we learned how much we suck at working with contractors. We’re extremely opinionated, really bad at expressing our opinions, and change our minds all the time. We asked Eddie to hold off while we re-grouped and figured out what we wanted from the app.

We sat down and had a lot of discussions about how we wanted this thing to work. Brandon Walkin helped out quite a bit, and even sketched up some wireframes & notes for us.

Eventually we figured out what we wanted to design — but now we didn’t have anyone to design it. Eddie had since taken up other work and pretty much every Cocoa designer on the planet was inundated with work.

In the end, I decided that GitHub for Mac was the thing I wanted out of GitHub, and if I wanted it to happen I’d have to take the design reins. I picked up Eddie’s comps and ran with it.

A slow process

I tried my best to combine Eddie’s original comps with our internal feedback and match it up with a modern OS X look & feel. All in all I created 45 comps for 1.0 — each with about 5-10 unique states (with layer groups).

After the first round of comps, I started writing down how I imagined everything to work.

My plan was to fully flesh out this styleguide — but as it happened, Josh was able to implement my designs faster than I could explain them. Still, I think it was a good exercise to explain my thinking for the designs — if anything for my own personal benefit.

The aesthetic

Learning the OS X aesthetic wasn’t easy. And it probably didn’t help that I started to get serious about OS X design about the same time Lion screenshots started showing up. Like it or not, OS X app design is changing in drastic ways right now.

Scrollbars are a thing of the past. Titlebars full of clickable areas. Buttons shedding themselves of borders. Custom graphics / buttons for every app. And Helvetica everywhere!

I tried my best to weigh this new direction with a lot of my favorite designed apps — Twitter, Espresso, Sparrow, and Transmit to name a few.

Lessons learned

Designing a native OS X app was definitely full of surprises. I’ve actually done quite a bit of native development before with WPF & Flex — but Cocoa is quite different.

Welcome to 2004 — everything is a sliced image

Remember web development in 2004? When you had to create pixel-perfect comps because every element on screen was an image? That’s what developing for Cocoa is. Drawing in code is slow and painful. Images are easier to work with and result in more performant code.

This meant my Photoshop files had to be a lot more fleshed out than I’ve been accustomed to in recent years. I usually get about 80% complete in Photoshop (using tons of screenshotting & layer flattening), then jump into code and tweak to completion. But with Cocoa, I ended up fleshing out that last 20% in Photoshop.

Change is painful

Want to move an element from the bottom of the screen to the top? A lot of times with Cocoa this involves rewriting your entire view. There is no layout engine for Cocoa. If you want two elements to rest side to side, you’ll need to calculate the pixel size of the text, padding, borders, margins — then manually position the next element.

Want to change the background color of a button? You’re probably going to have to rewrite all of the drawing code for the button. There is no styling engine in Cocoa.

This sucks. And it means that change is insanely painful in code. It’s much easier to prototype with HTML / CSS and see if the design is going to hold up.

This proposed changes redesign is a good example of what I mean. I spent a long time creating a “clickable” prototype with animations. In the end, we decided a lot of the core ideas were wrong and decided not to go down that path. Creating this HTML/CSS/JS prototype took a couple days. Doing the same in code would have taken a lot longer — and been much harder to throw away (due to the way project files work in Xcode, branching is not simple).

Objective-C is easy, Cocoa is hard

This was the first serious Cocoa project I’ve been involved with. I had dozens of little example projects, but never pushed through to ship anything. As I went on and talked to people about my frustrations, they inevitably came up with the same response:

Why don’t you just use MacRuby?

Why? Because Objective-C is really easy. The language was never a problem. You know what was? Cocoa. Learning the differences between layer-backed views, layer-hosted views — understanding that you have to subclass everything — balancing delegates, weak connections, strong connections, KVC, view controllers, and notifications — understanding little intricacies like how AppKit flips .xibs when it load them up or how hard it is to make one word in a sentence bold. I’m not going to lie: Cocoa (that is: AppKit, UIKit, Core Text, Core Animation, etc) is extremely difficult. The gap between simple example apps and a fully functional application is huge.

Projects like Chameleon that give you a purely layer-backed environment to work with using a modern API (UIKit) matter far more than the language you’re using. This isn’t to say MacRuby isn’t awesome — it just means that it doesn’t make AppKit development any easier; you still have to learn Cocoa.

Along those same lines, I think that Cocoa is dying for a framework. Something that weighs on the simple defaults side rather than complex code generation side.

Secrecy is overrated

GitHub for Mac was in development for just under a year and there was never any leaked screenshots or blog posts. In fact, there were dozens of public screenshots of the app on dribbble — but for the most part, people were surprised when we launched.

We didn’t have beta testers sign NDAs or demand first-borns to get access to the early builds. How on earth did we keep something under wraps for so long?

We asked people politely not to share it with the world. It’s really not that hard. Don’t send betas to douchebags. Politely ask people not to blog about it. Done.

Here’s to a bright future

I’m hoping that GitHub for Mac (and supporting projects, like libgit2) spurs a new round of creativity in source control clients. I’ve already seen some progress — like legit — but I’m hoping to see a new generation of source control clients in the future. Git is immensely powerful, and it’s up to us to leverage that power into something awesome.

I was playing around with Twitter’s new Follow Button and I couldn’t help but notice that the embedding markup is some of the best I’ve ever seen.

<a href="http://twitter.com/kneath" class="twitter-follow-button" data-show-count="false">Follow @kneath</a>
<script src="http://platform.twitter.com/widgets.js" type="text/javascript"></script>

I love the idea of using regular HTML with feature-flags in data attributes combined with a common script. Can’t wait to play around with this style on Gist.

Living in San Francisco and working in tech right now is absolutely insane. Employers and recruiters battle for employees while VCs rain down millions of dollars without meeting founders or even knowing what kind of company they’re building. It’s a crazy world to live in and can feel like money is growing on trees and the only spending limit is your imagination. If you have just a little bit of initiative, you can take any idea and start a company with absolutely zero personal risk.

And that’s one of the biggest reasons San Francisco is so special to me. Everyone out here knows they can do anything. Spend a few weeks hanging out in bars and cafes asking what people do and you’ll hear some of the most idiotic business ideas in the world. A lot of journalists use this argument to call San Francisco an echo chamber whose sole purpose is burning money. And you know, they’re right.

This city does burn through money on terrible ideas. But that’s a tradeoff for fostering a city of people who believe they can do anything. And that spawns an incredible number of amazing companies — so it doesn’t bother me. What does bother me is the lack of imagination most startup founders have.

Build something incredible

Most founders I talk to are pretty complacent building something mediocre. They won’t admit if you flat out ask them — but try pressing them to describe what makes their company special. Most cop out and give you an answer like:

We’re building [technology x] because [company y] hasn’t built it and [people z] need it.

Want a more concrete example? How about something like:

We’re building a cloud sync solution for iOS because Apple hasn’t built it and almost every iOS application needs sync.

There are thousands of people building products like this. They’re filling holes. Filling holes is mediocre and boring. Dare to build something incredible – something unique, something lasting, something special.

Ideas are lasting, products are not

The easiest way to build something incredible is to base your business around an idea. Products are just the manifestation of the idea.

This is something I think about at GitHub a lot. We’ve built an amazing product (github.com) — but when you ask us what the company is about we say:

We make it easier to collaborate with others and share your projects with the universe.

There’s a lot of interesting things you don’t see it that description: Git, version control, issue tracking, wikis, or website. We know that our product (a website hosting git repositories with built-in issue tracking & wikis) is great — but if it doesn’t serve a higher purpose, it would be mediocre. So we focus on the idea.

That means looking at version control, wikis, and issue tracking as tools for collaboration. It means that as important as it is for our website to be easy to use — it’s equally important for Git to be easy to use. Or to create tools that let people use Git without even knowing they’re using Git.

If I look into the future, I know that the idea of collaboration is lasting — but Git? That’s a hard bet to make. I know that if we focus our business on collaboration we can build something lasting. If we focus our business on being a Git host we’re doomed.

Ideas are sexy

One of the more awesome things about building your business around an idea is how easy it is to pitch to others. Ideas are sexy and draw people in — they invite passion and commitment. And pitching people is all about displaying passion and commitment. It doesn’t matter if you’re pitching for VC funding, trying to land a new customer, or interviewing a prospective employee — having a good pitch is critical to any successful business.

People want to be part of ideas. Being part of a company who builds a successful product is cool… but being part of an idea is a lot more attractive. If you can build a business where both your employees and your customers think they’re part of an idea, you’ve created something special.

Evolving ideas from products

The trouble is that founding a company around an idea doesn’t actually work. Apple Computer is a great example. They take bleeding edge technology, marry it with exceptional design, and sell it at a premium price. But the company wasn’t always like that. It was founded around a product — the personal computer. Yet in 2011, Apple’s biggest business is mobile phones.

You have to ask… how did a company founded around building personal computers come to generate most of its revenue from mobile phones? They evolved. They found their strengths (design, technology), and evolved the company around those values. This manifested itself into new products — the iPod, iPhone, iPad, TV, MobileMe, Airport Expresses, Cinema Displays, etc. Some successes. Some failures.

The core component of all these products is that they are manifestations of an idea. When the iPod took off in popularity, Apple didn’t rearrange the company around portable music devices. They kept focusing on building exceptionally designed hi-tech gadgets with bleeding edge technology.

So it’s okay to focus on a product at first. But as soon as you find your strengths as a company, abstract it out into an idea and focus on that. Do that and you won’t have your entire business invalidated by a feature that Facebook or Apple rolled out at their last keynote. Because ideas will last, products won’t.