We are looking for two more people to join our operations team. We would prefer individuals interested in both application development and systems engineering. We’ve got 100’s of servers running Ubuntu, 400+ terabytes of Isilon storage, and we’re building out a second site. We use lots of “bare metal” in addition to VMware virtualization and some of the Amazon and Rackspace Cloud services.

Come work with us at 37signals and do the best work of your career.

Want more information? Check out this post on the Job Board.

Fast Company just put out a list of the 50 most influential designers in America. The eight-category list includes interactive, fashion, architecture, etc.

10 of the 50 are in the interactive category. Out of Fast Company’s 10 most influential interactive designers in the world, eight of them are on the east coast, and seven of them are based in New York.

1. Ji Lee lives in New York
2. Joe Rospars is based in New York and DC
3. Robert Wong lives in New York
4. Khoi Vinh lives in New York
5. John Maeda lives in Providence
6. Nicholas Felton lives in New York
7. Jake Barton lives in New York
8. Lisa Strausfeld lives in New York

Fast Company is based in New York. This east-coast bias feels a little echo chamber-y and lazy. There are influential designers all over the country.

Christmas 2010 I had the idea to make a video of the 37signals homepage. I’d recently gained access to the relevant source code repositories and It seemed like a fun thing to do over a weekend.

The result is the video below. It’s a timelapse of the 37signals.com homepage between March 2009 and January 2011. Enjoy!

Thanks to Piarango for the use of “La Asombrosa” found on Ramen Music Issue #02.

One of the best things about CSS is the cascade, itself. It can also be one of the worst things about CSS. Styles applied to an HTML element are automatically inherited by their children. Cascading is what allows web designers to set styles and keep them consistent throughout a website without repeating themselves. With a single line of CSS you can, for example, set the typeface that will be applied to every element on every page of your website:

body {
    font-family: Helvetica;
}

Because every element is a child of the body, those elements will inherit the font style unless that property is otherwise overridden with a more specific rule. That’s where things get tricky. We might want to use Helvetica throughout the website except in the sidebar, where we’ll use Georgia. To reset the font-family rule for the sidebar element we must write something like this:

body aside {
    font-family: Georgia;
}

This is how we write CSS. We set styles at the top level and then proceed to override the inherited rules with increasingly specific selectors. There are esoteric rules of inheritance built into the CSS cascade that let designers target elements by id, class, or by relative position in the document. Each time you reset a style using specificity, overriding that style on a subsequent child element requires an even more specific selector.

Within complex website designs this can begin to feel like an arms race. You add classes and containers to your mark-up and more elements to your selectors. As you add increasingly specific (and increasingly long) selectors it becomes equally difficult to override them later. This problem is compounded after the initial composition of the CSS is completed and you begin to edit, maintain, or add new styles later in the life of the website. Even in the most carefully composed stylesheet it can be difficult to completely grasp the overall scheme – especially if you’re coming in behind the original developer to make changes. The safe thing – we’ve all done it – is to write a very specific selector for any new styles so you’re certain yours take precedence. Each round a salvo in the specificity arms race.

So what can be done? We’ve been experimenting with a few techniques that we think make a big difference. There are three parts to this formula: compiled CSS, structured mark-up, and a neglected CSS selector.

I’m going to give away all of my secret sauce, and tell you the three things that are required to be successful at business analytics (or data science, or whatever you want to call it):

1) Know at least a little bit about what you’re talking about.

At its foundation, business analytics is about converting a rather broad question (like “why do people cancel?”) into a set of specific questions that you can answer with data. This takes a bit of knowledge of what you’re talking about—you need the ability to construct hypotheses (e.g., people might cancel because they left the company, or because their corporate IT department rejected it, or…), and you need to know where you can get the answers. The best statistician in the world will be useless if they don’t get the context of the business.

A theoretician might call this “domain knowledge”, but all this is is the ability to know what you’re looking for and where to find it. There are no real shortcuts here – it takes exposure to your content matter to pick this up. Just open up the firehose—read as much as you can about your business and industry, stay involved in every conversation that’s even tangentially related, and be patient. Domain expertise will follow.

2) Make it easy.

There’s actually very little about data science that’s technically or intellectually challenging – it’s mostly about execution. Sure, machine learning uses advanced concepts that are worth understanding before you build a predictive model, and a passing understanding of statistics is a big deal, but most business questions can be answered with little more than simple arithmetic—what portion of customers do X? How long does it take people to do Y?

What then differentiates good data analysts from the rest? The ability to do this simple analysis quickly and easily, with minimal “friction”, so you can do more analysis faster. A few things help with this:

• Set up “one click” access to data. Shell scripts to drop you directly as a read-only user in your database, libraries to get your data from your database into a clean format in your prefered analysis environment, robots, and data exploration / dashboard type tools all help with this. These aren’t rocket science, but being able to get to your data in under ten seconds means you’ll be able to do it more.
• Have common definitions. Know what “active” means for each of users, accounts, etc. Try to pick consistent time periods for how far back you look at data. If you can skip the figuring out what someone means, data analysis becomes easier.
• Keep a calculator handy. Seriously, the friction difference between a calculator that you’re familiar with at arms reach and having to find one in a drawer, or opening Calculator.app, makes an impact in how easily you can do the simple arithmetic.
• Memorize your database schema. This isn’t a joke. You’ll know what you’re able to be able to find from a database alone and you’ll save a ton of time by not doing SHOW TABLES and DESCRIBE TABLE X all the time. At the very least, know what tables are named and generally what the relationship between them is. I’d hazard a guess that if you surveyed the business analytics people at a handful of brand-name internet companies, they could all write out the schemas for their main databases by memory.

3) Look at lots of data.

The only way to know what “normal” is when it comes to your data is to look at it, a lot. Look at graphs of different things over different time periods, review log files, read customer emails—be the most voracious consumer of new information and data that you can. Keep finding that next source of information.

Try to spend an hour a day consuming new data – just reading it in, absorbing it, maybe making some notes. It doesn’t need to be for any specific investigation of the moment, but it will pay dividends down the line. This is very similar to the “Rule of 10,000 hours” and other notions of “Just do, a lot”.

I used to think time was the most limited resource. It’s so limited that you can’t even save it for later. Every day you spend more time, and tomorrow you have less than you had yesterday. You can’t make more, and you can’t really buy more, so it’s limited and fleeting and those are the rules.

But there’s something even more limited than time. It’s your attention. Attention is a subset of time, therefore it’s more limited. How you spend your attention is more important than how you spend your time.

Attention is about focus and careful, thoughtful consideration. Unlike time – which can be broken into convenient chunks of 15 minutes – attention doesn’t divide quite so neatly or easily.

You hear a lot about “quality time” being valuable, but I think quality attention is invaluable. Giving someone your attention is giving more than just giving your time.

The greatest things you make and do are the ones that get your full attention. It’s helpful to take an inventory of what you’re doing and then ask yourself where you’re spending your best attention. You can fill your time, but you have to spend your attention. How you spend it is probably a better measure of priority than anything else.

Next time you say yes to something, ask yourself if yes means “yes, I can do that” or “yes, I can spend my attention on that.” If you’re not willing to spend your attention on it, is it worth doing? Maybe, maybe not, but it’s a good thing to think about the next time you take something on.

On October 10th we’ll be welcoming Jonas Downey as the fifth full-time designer at 37signals. Jonas comes to us by way of the Argonne National Laboratory where he was one of the principal designers of their web sites/apps. Jonas will join Craig, Jamie, Scott, and Jason Z in crafting the visual design of our apps and marketing sites.

Jonas, who applied once before but didn’t make the cut, came back strong and determined the next time we posted a designer position. He stuck with it, took our feedback, got better, showed us what he’s been up to since we last talked, and made a strong case for reconsideration. Here’s his second-time-around job application site.

Besides solid design chops, Jonas impressed us with his intelligence, his curiosity, his writing ability, his experience wearing a lot of hats, and his interest in exploring ideas and building stuff.

We’re excited to have him on the team.

Nobody has covered the beauty pageant of startup contestants and venture judges better than TechCrunch. They not only cheered on a generation of Silicon Valley dolls to dress their finest for the pump’n’dump cycle, they fucking owned the barn where the show was held.

So it’s hard to summon a pittance of pity for the mascara tears they’re now sporting. They knew this day was coming. When sugar daddy AOL, father of the Master Plan, pulled out the big checkbook to buy the prettiest doll of tech rags, did they really think it was true love?

Sure, they were all excited at the trophy wedding. TechCrunch was “delighted about becoming part of the AOL family,” and AOL’s PR department was thrilled that “[TechCrunch’s] reputation for top-class journalism precisely matches AOL’s commitment to delivering the expert content critical to this audience”.

But now it’s been 11 months since the check cleared, AOL daddy is all out of sugar, and the TechCrunch trophy is full of dust. Cue a drama worthy of the Bachelorette.

It used to be a jarring experience to setup a new machine for development, but progress has paved the dirt road into a silky smooth autobahn. These are the tools we use today:

1. Homebrew: Remember how painful it used to be to get imagemagick installed? Now it takes about a minute. “brew install imagemagick”. Same story for git and other Linux dependencies.
2. rbenv/ruby-build: We have some apps running on Ruby 1.8.7, some on 1.9.2, and some on 1.9.3. ruby-build makes it easy to compile all three, rbenv makes it easy to switch between them on a per-project basis. We run rbenv in production as well, so all you need to do to change the Ruby version there is alter .rbenv-version—development and production is always on the same page.
3. Bundler: Not everyone at 37signals loved Bundler at first, but now that it’s stable, they’ve been won over. I now curse whenever I have to use an old application that hasn’t been setup with Bundler. Manually tracing down dependencies?! How prehistoric!
4. rake setup: All our apps has a rake setup task that’ll run bundler, create the databases, import seeds, and install any auxiliary software (little these days) or do any other setup. So when you git clone a new app, you know that “rake setup” will take care of you.
5. Pow: No more messing with Apache or nginx for local development. All it takes for Pow to add another app is a symlink. All the apps are always configured and available at basecamp.dev, highrise.dev, etc without messing with the hosts file either.

Thanks to Max Howell for Homebrew, Sam Stephenson for rbenv/ruby-build and Pow, and Carl Lerche/Yehuda Katz for Bundler. Thanks to them, starting from scratch has never been easier.