You’re reading Signal v. Noise, a publication about the web by Basecamp since 1999. Happy !

Disruption is better when it's other people’s jobs

David
David wrote this on 14 comments

Many writers and publishers are freaking out after Apple opened Safari to ad blockers in iOS9. Ad blockers have been around for a long time, but the fear is that this is the move that will take the concept mainstream.

That fear appears well justified. The App Store’s charts have been dominated by ad blockers since the release of iOS9 last week. Currently, the #1 paid app is Crystal, an ad blocker, and so is #3, Purify. Clearly some pent up demand.

Another data point is the following poll from The Verge. It was setup with an almost satirically over-the-top slant, and yet readers pummeled them:

Continued…

Work in Progress

Nathan Kontny
Nathan Kontny wrote this on 7 comments

Jason and I have now done 18 live chats we've published on YouTube and SoundCloud and we still like each other! :) Just to be transparent, it hasn't been a piece of cake. It's a whole new environment for us to figure out. Not just how to get subscribers. But things like picking topics. Staying interesting. Even things like lighting. Barking dogs. Poor internet connections. Sleeping in-laws. But it's a constant reminder how much work goes into any product. There's always a new challenge or opportunity to learn to get better. It's never done. It's a "Work in Progress". And waiting for perfect is a sure way to fail to get anywhere. Here are some of my favorites of the episodes we've done so far:

Continued…

Introducing Mercedes De Luca, Basecamp's first COO

Jason Fried
Jason Fried wrote this on 13 comments

Today we’re feeling really good because we get to announce that Mercedes De Luca will be joining Basecamp as our first-ever COO.

Over the last few years, David and I have come to realize that high-level strategy and hands-on product development is what we enjoy doing most. But of course there’s so much more to running a company than just that stuff.

Products are products, but companies are products too. Your company should be your best product, since it’s the product that produces all the others. We should operate the company with as much love and attention and care as we put into building our products. We want Basecamp the company to be outstanding at every level.

Mercedes is going to help us be all we can be. She’s been a CEO, a CTO, a CIO, and a GM. She’s run big groups and small groups – local and remote. She has the right mix of a structured analytical mind and an insightful creative spirit.

Continued…

Farm Wisdom

Wailin Wong
Wailin Wong wrote this on Discuss

The latest episode of The Distance features the Jones family, which has been farming in Iowa for generations. They have weathered tough winters, the consolidation of small family farms and the farm crisis of the 1980s. Today, 29-year-old Will Jones is in charge, and he’s melding his own vision for the family business with the collective wisdom of predecessors like his father.

If you’re hankering for more stories about old businesses and professions after listening to the episode, sign up for The Distance newsletter at the bottom of the home page. Every two weeks, when we release a new episode, I share three recent stories that have caught my attention. Recent favorites have included the re-release of an incredible radio documentary about the Sunshine Hotel, one of New York’s legendary flophouses; an episode of the podcast Death, Sex & Money that interviews a sixth-generation funeral director; and a Miami Herald story about some of Florida’s last remaining tollbooth collectors. Sign up to get these goodies in your inbox!

A Love for Legacy

Eileen Uchitelle
Eileen Uchitelle wrote this on 5 comments

Here at Basecamp it’s no secret that we’re in it for the long haul. From investing in employee benefits to holding off on tossing out old apps to replace them with new ones. Everything is set up so that staying in it for a long time gets you the best results.

One of the things that’s most interesting to me at Basecamp is that we wear our legacy applications as a badge of honor. The very first Rails application ever built still exists as Basecamp Classic. That is the application Ruby on Rails was both created for and born from. It’s easy to forget the weight of that sometimes.

There is something very special about getting to work on the first Rails application. You can see how the Rails framework was built out of necessity and how it has since evolved over time. The Rails framework will continue to be guided by the real-world needs of our applications and now scores of others.

Continued…

Optimizing Site Performance via Anycast Routing

Eron
Eron wrote this on 4 comments

As you may have noticed, we’re working on an all new version of Basecamp called Basecamp 3. We want to build the fastest version of Basecamp yet, so we’ve been hard at work on optimizing performance. One of the things we’ll be doing to improve both performance and reliability is to serve Basecamp 3 from two datacenters: one in Chicago, IL, where our other applications are all located, and our second site in Ashburn, VA that we’ve brought online over the past couple of years. We recently optimized how traffic reaches these datacenters by using Anycast BGP.

Continued…

Putting on the shipping goggles

Jason Fried
Jason Fried wrote this on 5 comments

One of the biggest challenges of shipping a product is knowing when to put on the shipping goggles.

The shipping goggles make you less sensitive to little nits and scrapes and things that might be able to be a little bit better, but really don’t need to be right now. Stuff that we could tweak, but really shouldn’t be grabbing our attention given all the other high value bits we need to hit.

It’s sort of like squinting – you lose the detail, but you can still see the overall big picture shape, form, and function. Your peripheral vision shrinks, but the center is still bright. Knowing when to squint is a good thing to know.

It’s not that the details don’t matter. They do, but details aren’t fixed – they’re relative. And of course any time you talk about details mattering, you’re speaking in very broad generalizations. Some matter, some don’t. Some never matter, some matter later, but not now. And some really matter now and can’t wait for later. Like everything, there are varying degrees.

Part of training yourself to ship is to recognize what details are really worth nitpicking and when. There are no hard and fast rules here – it just takes judgement and experience. These are skills that build over time. Once you’ve been around it for a while you tend to improve your sensitivity to what’s worth doing before you ship and what can wait until later.

And BTW, nitpicking may be construed as a pejorative, but I don’t believe it is. Nitpicking is a valuable skill, as long you deploy it at the right time for the right reasons. One of the penalties of nitpicking at the wrong time is that nitpicking often attracts a crowd. Someone nitpicks this which is an invitation for someone else to nitpick that. And before you know it, half a dozen people are spending time discussing tiny details that really don’t demand that level of attention.

Again, there are no facts around when it’s worth nitpicking and what’s worth nitpicking – I’m only speaking to the awareness how situations unfold.

We can all get better at this. I’ve been shipping stuff for years, but I still have to get better at recognizing the right moments to bring up certain things. I definitely fall into the trap of spending time making changes to things in the 11th hour that are really perfectly fine and can be addressed later if necessary. I absolutely find myself regretting going down a rabbit hole that really didn’t need to be investigated. I still find myself distracting others with change requests or suggestions that really didn’t need to cloud their vision and sap their attention. It’s hard!!

As we close in on a big launch ourselves, I’m reminded of how important it is to keep time and place and impact in mind when bringing small things up. Again, it’s not that they aren’t important, it’s that they may not be important now. Everything has a cost and the cost of breaking attention goes up during crunch time.

Growing our audience for The Distance

Wailin Wong
Wailin Wong wrote this on 5 comments

In late May, Jason and I decided to transition The Distance from monthly longform written stories to a podcast that would come out every two weeks. Jason also set an ambitious target for the podcast: Get to 6,000 listens on any one episode by the end of the summer. At the time, our most listened-to episode had around 2,000 listens.

I’m thrilled to say that our first episode hit 6,000 listens on Friday. (If you missed that story, which is about the World’s Largest Laundromat, we re-released it today with some edits and improvements.) Not only did we reach our goal, but we saw a sustained increase in our audience—our last two episodes have each hit 4,000 listens in their first two weeks. To put this in perspective, when we made the format switch in May, no single episode had cracked 3,000 lifetime listens.

So how did we grow our audience for the podcast? Here’s a rundown of what Shaun and I tried this summer. Some of it worked and some of it didn’t. But it was all a learning experience, and one that’s continuing as we keep expanding our subscriber base. If you’re in a similar position as we are, whether it’s with a podcast or a different medium within this terrifyingly uncertain world of content production, I hope you find some of our learnings useful too.
Stuff That Helped

  • We got nice shout-outs from a few high-follower/influential Twitter accounts: Gary Vaynerchuk (thanks to Jason for telling him about the show), StartupWeekend, Rafat Ali of Skift and Jake Nickell of Threadless.
  • I submitted The Distance to The Podcast Digest, a podcast about podcasts, and host Dan Lizette recommended our show on his August 9th episode. It was a really nice segment and especially gratifying because all I did was fill out a Google Form on his website. Dan actually listened to our back episodes and enjoyed them enough to recommend us. A rare slush pile success!
  • Pocket Casts, a podcatcher app, featured The Distance. Below is a screenshot a friend of mine sent me.
  • We got onto Product Hunt.
  • We briefly made it into the Top 10 for Business News podcasts in iTunes. That was thanks to a bunch of new ratings/reviews that came in one afternoon from Basecampers—who, I should mention, had been promoting The Distance on their personal social media accounts and to their friends and family all summer long. Thank you!
  • What really helped build some momentum for The Distance was going to two episodes a month and boosting the show’s production values. So much of the content game is about consistency and regularity, and we got a sustained increase in listeners once we started doing twice-monthly episodes. Shaun added music, taught me how to capture better audio in the field and was a fantastic editor and producer all around.
  • Stuff That Didn’t Work Out (or Hasn’t Yet)
  • I emailed a bunch of podcast newsletters and websites to let them know about The Distance.
  • I very awkwardly donned my publicist hat and pitched a couple national and local media outlets. This was incredibly weird for me, having spent my entire career on the other side of this transaction. I could stand to get better at it.
  • We looked into joining a podcast network. That remains a potential option, but one for the longer term.

I’m really grateful that Basecamp is a company that believes in and underwrites projects like The Distance. I’ve learned a lot from working alongside everyone here. More TK, as they say! In the meantime, if you haven’t yet listened to The Distance or subscribed, please come aboard. We love making the show and have a lot of great episodes planned. Here’s to the next 6,000 listeners!

Go at Basecamp

Noah
Noah wrote this on 8 comments

Basecamp is a Ruby company. All of our customer facing applications are written with Ruby on Rails, we use Ruby for our systems automation via Chef, we deploy via Ruby through Capistrano, and underneath most rocks you’ll find a Ruby script that accomplishes some task.

Increasingly, however, Go has found its way into our backend services and infrastructure in a variety of ways:

  • Our timeseries data acquisition and storage daemon was rewritten from Ruby to Go in January 2013.
  • Our Ruby build scripts build new Ruby packages for our servers via Docker.
  • Our log parsing and storage pipeline writes to Kafka, HDFS, and HBase via an assemblage of Go programs.
  • We backup our DNS records from Dynect with a tool written in Go.
  • We run a multi-master Nagios installation via a Go-based passive check bridge and multi-host notifier.
  • We keep our GitHub post-commit hooks in shape using a Go program.
  • The server side of our real user monitoring and pageview tracking systems are entirely written in Go.
  • We regularly download, decrypt, and test the integrity of our offsite database backups with a Go program.

There are also numerous experiments in Go that haven’t made it into production: keeping multiple memcached instances in sync from packet captures, serving Campfire over websockets, packaging our Rails apps into Docker containers, and more. We’re also heavy users of some third party Go applications (etcd and sentinel) which power our failover process between datacenters.

Our use of Go is entirely organic. We never sat down one day and decided to start using it; people just started writing new things in Go.

Personally, I like Go because the semantics of channels and goroutines are a great fit for building data pipelines, and the innate performance of Go programs means I don’t have to think as much about the load that a parser might be adding to a server. As a language, it’s a pleasure to write in—simple syntax, great standard library, easy to refactor. I asked a few other people why they enjoy working in Go:
Will: “Go feels perfect for Ops work. The error handling seems to fit so naturally into the way I want to write systems software, and on top of that it’s good (and getting better) at using multiple cores effectively. Deployment is really simple too, where I’d have to think about how to package up deps and configure Ruby versions I can now just push an updated binary.”


Taylor: “When you are learning a new programming language sometimes you reach a point where trying to solve a real problem furthers your understanding of the language and it’s strengths. Go’s fantastic documentation, ease of testing and deployment (compile once and run anywhere via a single binary) are enough to help even a novice write a performant and reliable program from the start. Where you might spend hours debugging a threading bug in your Ruby program you can spend minutes implementing go channels that seem to just work. For even the basic script that needs high concurrency this is a huge win.”


It’s unlikely that you’ll ever see a fully Go-powered version of Basecamp, but Go has certainly found its way deep into our infrastructure and isn’t likely to go anywhere soon. If you’ve never tried it out, give it a shot today!

Gopher drawings by Renee French and licensed under the Creative Commons 3.0 Attributions license.