We’re hiring Rails programmers

We have two rare openings on our Core Product team for Rails programmers. We’ll be accepting applications for the next two weeks, aiming for a flexible start date in October.

We strongly encourage candidates of all different backgrounds and identities to apply. This is an opportunity for us to bring in a different perspective and we’re eager to further diversify our company. Basecamp is committed to building an inclusive, supportive place for you to do the best work of your career. We aren’t looking for ideological clones, but for people who share our beliefs about writing software well.

Keep reading “We’re hiring Rails programmers”

Remote work is a platform

Back in the mid-90s, just as Netscape Navigator was giving us our first look at what the visual internet could be, web design came in two flavors.

There was the ultra basic stuff. Text on a page, maybe a masthead graphic of some sort. Nothing sophisticated. It often looked like traditional letterhead, or a printed newsletter, but now on the screen. Interactions were few, if any, but perhaps a couple links tied a nascent site together.

And there was the other extreme. Highly stylized, lots of textures, 3D-style buttons, page curls, aggressive shadows, monolithic graphics cut up with image maps to allow you to click on different parts of a single graphic, etc. This style was aped from interactive CD/DVD interfaces that came before it.

Both of these styles — the masthead with text, and the heavily graphical — were ports. Not adaptations, but ports. Designs ported from one medium to another. No one knew what to make of the web at that time, so we pulled over things we were familiar with and sunk them in place. At that time, Web design wasn’t web design – it was print design, multimedia/interactive design, and graphic design. It took years for native web design to come into its own.

The web became great when designers started designing for the web, not bringing other designs to the web.

Porting things between platforms is common, especially when the new thing is truly brand new (or trying to gain traction). As the Mac gained steam in the late 80s and early 90s, and Windows 3 came out in 1990, a large numbers of Windows/PC developers began to port their software to the Mac. They didn’t write Mac software, they ported Windows software. And you could tell – it was pretty shit. It was nice to have at a time when the Mac wasn’t widely developed, but, it was clearly ported.

When something’s ported, it’s obvious.

Stuff that’s ported lacks the native sensibilities of the receiving platform. It doesn’t celebrate the advantages, it only meets the lowest possible bar. Everyone knows it. Sometimes we’re simply glad to have it because it’s either that or nothing, but there’s rarely a ringing endorsement of something that’s so obviously moved from A to B without consideration for what makes B, B.

What we’re seeing today is history repeat itself. This time we’re not talking about porting software or technology, we’re talking about porting a way to work.

In-person office work is a platform. It has its own advantages and disadvantages. Some things are easier in person (meetings, if you’re into those), and some things are harder (getting a few hours to yourself so you can focus, if you’re into that).

Remote work is another platform. It has its own unique flavor, advantages, and disadvantages. Its own efficiencies, its own quirks, its own interface. Upsides, downsides, insides, and outsides. It’s as different from in-office work as the Mac is from Windows. Yes, they’re both operating systems, and methods of computing, but they’re miles apart where it matters. The same is true for the difference between in-office work and remote work. Yup, it’s all still the same work, but it’s a different way to work.

In-office and remote work are different platforms of work. And right now, what we’re seeing a lot of companies attempt to port local work methods to working remotely. Normally have four meetings a day in person? Then let’s have those same four meetings, with those same participants, over Zoom instead. It’s a way, but it’s the wrong way.

Simulating in-person office work remotely does both approaches a disservice.

This is often what happens when change is abrupt. We bring what we know from one to the other. We apply what we’re familiar with to the unfamiliar. But, in time, we recognize that doesn’t work.

The enlightened companies coming out of this pandemic will be the ones that figured out the right way to work remotely. They’ll have stopped trying to make remote look like local. They’ll have discovered that remote work means more autonomy, more trust, more uninterrupted stretches of time, smaller teams, more independent, concurrent work (and less dependent, sequenced work).

They won’t be the ones that just have their waste-of-time meetings online, they’ll be the ones that lay waste to the meetings. They won’t be the ones that depend on checking in on people constantly throughout the day, they’ll be the ones that give their employees time and space to do their best work. They won’t be the ones that can’t wait to pull everyone back to the office, they’ll be the ones that spot the advantages of optionality, and recognize a wonderful resilience in being able to work from anywhere.

And they’ll be the ones that finally realize that there’s nothing magical about the office. It’s just a space where work can happen, but not where it must happen. Anytime a myth is busted is a good time.

Work remotely, don’t port the office.

Spy pixels are evolving like malware, so HEY’s adapting

We knew that spy-pixel pushers might go down the rabbit hole of escalation once we gave HEY users the power to defend themselves. Just like virus and malware makers are constantly trying to defeat anti-virus and other security protections. But I guess we didn’t realize just how quickly it would happen!

Enter GMass, a plugin for Gmail that adds spy-pixel tracking, amongst a grab bag of other stuff. They hadn’t been on our original list of 50+ services we name’n’shame, but thanks to a new blog post where they brag about defeating protections that recipients might take to defend themselves, they came onto our radar.

This lead to an in-depth investigation into how their latest techniques work, and we spent the whole day coming up with a new process of detecting GMass’ spy pixels. It just shipped! And now HEY will name’n’shame GMass, just like we do the other fifty-odd pushers of this kind of surveillance.

Of course, like those virus and malware makers, GMass may try to defeat our protections again. And we’ll then have to adapt once more, and so we will. Internet security is a constantly moving target. But we can hope that Google will soon stop being a conduit for this kind of privacy abuse on the Gmail platform. Just like they don’t tolerate being used for spamming or phishing.

In the mean time, we’ll continue to do the work both on a general level to protect against all forms of privacy attacks against HEY users, but also specifically to identity bad actors, and to call out the users who employ their software for spying.

Have a surveillance-free Friday!

On Apple’s monopoly power to destroy HEY

This statement was delivered to the democratic side of the House Antitrust Subcommittee upon invitation on July 17, 2020 in the committee’s preparation for the forthcoming July 27, 2020 showdown with the Big Tech CEOs.

Two years ago, we got the audacious idea to take on Google, Microsoft, and Verizon to provide a new, fresh alternative to their email services. It’s been about 16 years since people were last excited about getting a new email address – Gmail was introduced in 2004 – and frankly, it shows. These legacy services have been virtually devoid of innovation for over a decade.

And why wouldn’t they be! They’ve already captured the market. Between Gmail, owned by Google, Hotmail/Outlook, owned by Microsoft, and AOL Mail/Yahoo Mail, owned by Verizon, you have about 85% of the US email market captured by three players. And out of that, Gmail alone is about 55 percentage points.

But! Despite this near-total capture by big tech, the underlying protocol of email is still just barely free and open. You don’t have to ask anyone’s permission to make a new email service. (Or so we thought.)

Fast forward millions of dollars in investment to June 15, 2020, which was the day we opened the doors to our new email service, and were met by every entrepreneur’s dream: amazing reviews and customers tripping over themselves to signup and pay for our product.

Keep reading “On Apple’s monopoly power to destroy HEY”

Basecamp’s Ops Team is Hiring

Basecamp is hiring three new System Administrators for our Operations team to help us deliver fast and reliable applications, like Basecamp and our new email service HEY. Our infrastructure exists both in colocated data centers and in the cloud, and you’ll be working alongside our existing team of Blake, Eron, John, Matt, Matthew, Nathan, and Troy.

As you might gather from the names, our operations team today is not nearly as diverse as we’d like it to be, or as the rest of the company. We therefore strongly encourage candidates of all different backgrounds to apply. Basecamp is committed to building an inclusive, supportive place for you to do the best and most rewarding work of your career. We are an equal-opportunity employer and are committed to building a company that embraces and celebrates diversity and inclusion.

Keep reading “Basecamp’s Ops Team is Hiring”

How we achieve “simple design” for Basecamp and HEY

Yesterday I got an email asking how we achieve simple designs for Basecamp and HEY, so I hastily tweeted a screenshot of my answer, and a lot of people responded to it. A few folks pointed out that my screenshot was illegible for blind users, so I’m reposting it here in full text, with a bit of additional commentary below.


At a high level it boils down to a handful of foundational principles that affect the decisions we make:

  1. Always choosing clarity over being slick or fancy. Internally we call this “Fisher Price” design. We aim to make the UI totally obvious and self explanatory, by keeping individual screens simple, showing only one focused thing at a time, and so on. Good product design eliminates the need for an instruction manual!
  2. Preferring good copywriting, and taking the time and space to explain things with words, instead of making minimalist UIs with lots of unlabeled buttons, etc. (Although we’re still guilty of having a few of those.)
  3. Prioritizing respectful interfaces that don’t overwhelm or try to nag the user into certain behaviors. We intentionally don’t include things like notification counts/badges, 3-column designs, and such unless we absolutely can’t avoid them. We don’t like the idea of having “sticky” interfaces—we want our customers to use our products to get the job done, and then go do something else. That makes the whole design approach more peaceful in general.
  4. Having a strong editorial sensibility, and knowing when to split complex concepts into simpler individual parts. This one is more of an art than a science, but we have a good instinct for breaking down problems until they can be easily understood in simple UI flows.

There’s one other thing that’s important for simple design. It’s not merely a matter of having clear or basic-looking interfaces. (It’s easy to make a simple UI that doesn’t really do much.)

The magic combo is having simple interfaces paired with powerful capabilities below the surface. HEY looks simple, and it’s straightforward to use, but it’s backed by some deeply considered opinions, logic, and machinery that empowers people who use it to be better at email than they were before—and with less effort! The interface itself is simple, but the thinking and the system behind it is extremely complex. The product is valuable because it saves people time and anxiety dealing with the terrible email mess that they had just learned to live with.

For more on this line of thinking, we highly recommend Kathy Sierra’s Badass: Making Users Awesome.

(P.S. many thanks to @waynedixon and @redcrew for calling me out on the inaccessible screenshot tweet. Appreciate that.)

The evolution of HEY: from humble beginnings to a multi-platform email service

Two weeks ago we released HEY into the world, the culmination of 2+ years of explorations and intensely focused work.

It goes without saying, but I’ll say it anyway: inventing a new product from scratch is one hell of a challenge. It’s the toughest thing you’ll ever do as a product team. There are a million reasons why it won’t work, and zero guarantees that it will, so the whole project is a massive gamble. You just have to buckle up and trust that you’ll figure things out.

Since HEY made a big splash on arrival, I thought it’d be fun to share the backstory of how we ended up reinventing email. Because we certainly didn’t start by wanting to reinvent email. (That sounds hard and intractable!)

Keep reading “The evolution of HEY: from humble beginnings to a multi-platform email service”

Towards carbon negativity

Humans have been pumping greenhouse gases into Earth’s atmosphere at an unsustainable rate. It’s on us to reverse course as quickly as possible to stay below the tipping point of 1.5℃ global warming. Without action, the future is beyond bleak.

At Basecamp, we’re committing to becoming carbon negative for our cumulative history and moving forward.

The first step of that commitment is understanding the size of our carbon footprint. We’ve just completed our first carbon footprinting exercise as a company and are publishing our results. By sharing our approach, we hope to make it easier for other companies to also join the collective mission to carbon negativity. 

Keep reading “Towards carbon negativity”

Running spot instances effectively with Amazon EKS

Since we started working on HEY, one of the things that I’ve been a big proponent of was keeping as much of the app-side compute infrastructure on spot instances as possible (front-end and async job processing; excluding the database, Redis, and Elasticsearch). Coming out of our first two weeks running the app with a real production traffic load, we’re sitting at ~90% of our compute running on spot instances.

Especially around the launch of a new product, you typically don’t know what traffic and load levels are going to look like, making purchases of reserved instances or savings plans a risky proposition. Spot instances give us the ability to get the compute we need at an even deeper discount than a 1-year RI or savings plan rate would, without the same commitment. Combine the price with seamless integration with auto-scaling groups and it makes them a no-brainer for most of our workloads.

The big catch with spot instances? AWS can take them back from you with a two-minute notice.

Keep reading “Running spot instances effectively with Amazon EKS”