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

Growing our audience for The Distance

Wailin Wong
Wailin Wong wrote this on 4 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 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.

Can old world be more modern than new school?

Jason Fried
Jason Fried wrote this on 16 comments

I’ve got two machines on me.

One’s strapped to my left wrist. The other lives in my pocket.

The one on my wrist can tell me the time (precisely in 12 hour format, roughly in 24), the day of the week, the month of the year, which year of the leap year cycle we’re in, and the current moon phase. But that’s its limit. There’s no software, only hardware. It’s programmed in springs and gears and levers and jewels.

The one in my pocket can tell me anything and do just about everything. It knows my voice, it responds to my touch, and it even instantly recognizes my fingerprint out of fourteen billion fingers. This machine even knows the angle, velocity, and distance it travels when I swing it around. And it always knows exactly where it is anywhere on the planet.

But sometimes I wonder which one is more modern.

The one in my pocket can do more, but only for a limited time. And then it can’t do anything. It dies unless it can drink electrons from a wall through a cable straw for some hours every day. And in a few years it’ll be outdated. In ten years it might as well be 100 years old. Is something that ages so fast ever actually modern?

And then there’s the machine on my wrist. It’s powered entirely by human movement. No batteries, no cables, no daily dependency on the outside world. As long as I’m running, it’s running. And as long as one person checks it out once a decade, it’ll be working as well in 100 years as it works today. It’s better than modern. It’s timeless – yet it keeps time.

As time goes by, my pocket will meet many machines. My wrist might too. But when I look down at the machine on my wrist today, and know that in 50 years my son will be able to look down at his wrist at the same machine ticking away the same way it ticks today. That’s a special kind of modern reserved for a special kind of machine: the wonderful mechanical wristwatch.

Extra Drawings for The Distance

Nate Otto
Nate Otto wrote this on 1 comment

Last year I shared some extra drawings I made for the Basecamp marketing site that for a variety of reasons never went live or were seen by anyone outside of Basecamp. There have also been many drawings for The Distance that have never seen the light of day until now.

For just over a year, The Distance was dedicated to longform articles about long standing businesses. Under the editorship of Wailin and the art direction of Mig, I made a header illustration for each article and a building drawing that served as the footer. In recent months, The Distance has morphed into a podcast. I still illustrate the cover for each issue, but the header illustration is no longer needed. I like to tell people that I illustrate a podcast, and then I wait to see their reaction. There were a few issues that were both a podcast and a longform article. Here are some of the extra drawings made for those articles and then a link to each corresponding podcast. I’m also hoping to show some of the collaborative process and how we use Basecamp together as a team.

World’s Largest Laundromat

The finished header looked like this. I got a creative brief from Mig with some of the concepts of the story that he wanted to see in the header, and he also shared some visual inspiration, including some anthropomorphic washers and an animated gif of spiraling bubbles. The theme that I latched onto was that this is the world’s largest laundromat, so I knew I wanted to draw a big washing machine. The first image I drew was of a washer amidst a field of bubbles, but that didn’t read well and it didn’t really say anything.

I tried another one with a washing machine looming large on a street with residential buildings. Drawing buildings is my jam so I was playing to my strengths here, and I thought it worked conceptually. I shared it on Basecamp and…

I was ecstatic that they liked the drawing, and that the header came together so quickly. As you will see, it doesn’t always happen that way. I colored in the drawing and that became the final image. I had some time and I was still thinking about washing machine people, so I made the additional drawing of a washer with a top hat!

Ideal Box Company

The final header looks like this.

This article is about a box company that makes a lot of point of purchase displays. I kicked off the to-do with a drawing.

Wailin shared a copy of the story then and she broke down some of the key points and themes. She also shared a few ideas for me to try. I did this drawing but I knew that it didn’t hit on many of the themes (even though I initially tried to champion it).

Mig then chipped in with a winning idea followed by some other points, but I latched on to his origami concept.

Even though I’m relatively inexperienced in editorial illustration, that doesn’t always stop me from being overly opinionated about their purpose. I ranted about that on the thread a little bit. Artists are the worst. In the end Mig is usually right.

Victory Auto Wreckers

The final header looks like this.

I got a copy of the story and some thematic ideas from Wailin: the afterlife of a car; use every part of the animal; from junkyard to recycling center; and new commercial. That gave me enough to sketch out some ideas.

Mig liked that idea but he wanted to see it more dense with car parts.

Mig wasn’t sure about the car in 3D space, so he wanted me to try one flat but with more parts.

I drew up this, and it evolved into the final image.


A chart a day keeps the data in play

Noah wrote this on 1 comment

Every working day for the last month or so I’ve posted a single “chart of the day” to our Basecamp account. They’re posted internally without much commentary—just enough to explain what the chart is about. The topics are wide ranging: in the last month, we’ve covered browser uptake, search terms, The Distance, database performance, phone support, Nagios alert trends, demographics, classes, timezones, and even home energy usage and BMW torque curves.

The charts don’t fit into a big picture narrative, and there’s no agenda behind them: I simply take one chart from something I’m currently working on, have worked on recently, or someone has been curious about. Most are literally pulled from an open workbook or browser tab, so it’s not a big time investment. The chart of the day takes about a minute to post when it’s pulled from something I’m already working on, or up to fifteen minutes on the rare occasions that I create something completely from scratch for one. Sometimes they’re great visualizations; sometimes they’re not the most stunning displays of data. The key thing is that there’s a new one every day.

Why am I doing this? In part for fun and as a personal challenge: it takes a certain amount of thought and a different approach to making a chart that can tell a story on its own.

The bigger and more strategic reason for posting a chart a day is that I want to make data easier for people to digest and make a part of their daily work. I’m guilty of occasionally dropping 5,000 word reports with a couple dozen figures included into a Basecamp project when writing up a topic. I’ve gradually moved more and more content into appendices, methodological supplements, or self-service Tableau workbooks, but a full in-depth analysis of a topic is still long. I understand that it’s a real commitment of time and attention to read something of that length and digest it fully.

One chart a day, on the other hand, is easy — it’s not a big commitment to look at one chart and a couple sentences of context on a different topic each day. I don’t track readership of either longer reports or charts-of-the-day religiously, but based on general feedback, I think it’s fair to say more people are reading – and benefiting from – the daily charts.

I’ve talked to people in other organizations who do similar things, whether it’s a weekly internal blog post or data show-and-tell at a meeting, and the reaction has been uniformly positive: more people engaging with more data and having a bigger impact on organizations. If you do something like this, I’d love to hear about what you do and the impact that it has. If you don’t, maybe it’s time to give it a try.

Grit is for cowboys

David wrote this on 5 comments

The cattle has to be round up. Complaining about the weather or going without sleep for 16 hours isn’t going to do it. So clench your teeth and get the work done. That’s the grit needed to be a cowboy.

But I’m a lot less sure that grit is such a positive trait in other professions, particularly creative endeavors like programming, design, or writing.

If I had more grit, I would probably just have clenched my teeth and dug into that J2EE architectural hole with greater perseverance, rather than giving up and building Ruby on Rails. I would probably have spent more time finishing my math classes as a senior in high school, rather than just plagiarizing my friend, and spending the time running gaming websites in the late ‘90s.

Grit is a convenient trait for enticing others to comply with the uncomfortable or the uninteresting. It elevates the perseverance of such adversity to a virtue in and of itself. Just dangle that long-term goal in front of them, accuse them of lack of grit, and compliance will oft follow.

But far more important than to be capable of suffering for your cause is to ask “what cause”? Am I the beneficiary here, or is someone else? Being high on grit may well mean sticking with a faulty cause for far longer.

Grit is an optimization for local maxima. If you’re able to change the function, drop the grit.

Less than perfect

Nathan Kontny
Nathan Kontny wrote this on 6 comments
I want to create something out of nothing but nothing isn’t a great place to draw from.

Mitch Hedberg

On February 21, 2006 a guy launches a video blog. The results, even by 2006 standards, were far less than perfect. The lighting is terrible. The camera unsteady. There’s a use of zoom and text effects that remind me of my mom’s VHS videos of my sister and I figure skating in 1990.

Later episodes have funny text effects where the title of the blog swims into view like a novice PowerPoint presentation. There’s a glass picture frame behind him reflecting whatever light fixture is in the room, and that’s all your eyes want to look at.

The first episode has 14 comments made in its entire first year. This definitely didn’t take off like a rocket ship.

People who’ve been fans of my blog and the writing I’ve done on places like SvN have messaged me that they’ve missed my writing. I haven’t done as much lately. Why? The answer is pretty simple. As Jason Fried might say, I just don’t have the attention. It’s easy for me to spend an entire day writing and researching an article. But, running Highrise is a big job. There’s so much to do. Building a brand new team, managing the current product and its support, and reinvigorating product development on an old product, takes all of my attention.

And there’s a hesitation now in publishing my work.

Success breeds hesitation. Even the modicum of success I’ve had writing has created a hesitation to publish something that isn’t perfect. I want each article to be even better than the last one. But that just makes it impossible to publish thoughts and ideas and observations when I don’t have the attention to make them perfect.

Hesitation becomes this empty void where we stop producing good ideas, because we no longer have that bucket of just fair ideas to draw from.

How do I fix it?

That video blogger kept at it. In episode 1000 the intro graphics are now this fancy professional animation that reminds me of the quality of the Mad Men intro. And he’s definitely found an audience.

Today you know him as Gary Vaynerchuk and this was his Wine Library TV video blog. Today, with over a million Twitter followers, he hosts another video podcast called the #AskGaryVee show. The production quality is light years past that first episode of Wine Library TV. There’s perfect lighting, multiple cameras, fancy editing and effects that all come off as interesting and professional. And there’s thousands and thousands of people watching. He’s clearly made something many of us aspire to after publishing and publishing and publishing stuff that was less than perfect.

One thing that’s helped recently reinvigorate my writing was to give myself channels where I don’t feel the pressure for perfect. Comments on forums are great for this. Most people have very low expectations of the quality of “comments” online.

I use Reddit to practice. I’ll find someone asking something I think I could riff on, and I’ll just go. I’ll try to work in some personal anecdotes or something I’ve observed and see if I can make it interesting. If I like the result I might polish it a little and put it in more places. Here’s an example of a question on Reddit that I answered.. Seemed like it got some folks interested, so I polished it some, and posted a different version to this blog which sparked a great conversation.

If I didn’t have that first mediocre attempt at an answer, I wouldn’t have ever gotten to publishing the better one. I needed a far less than perfect place to start.

A few weeks ago Jason Fried pinged me with:

We got together to hammer out a few details of what it would look like. Soon after, we filmed a pilot episode that we recorded but didn’t tell anyone about. We wanted to see if it had any kinks. It had kinks.

It took us 15 minutes just to figure out places with good internet connectivity and lighting – so you could actually see my face. After that, we finally got to chatting. The results were still terrible. We had a fun time talking, but it was unlistenable. There’s an echo of my voice in the video. We later figured out from chatting with people who’ve already done this a ton like Chase Clemons and Shaun Hildner, it’s probably from Jason’s laptop mic picking up the audio from his speakers – problem would be resolved if we both used headsets.

Ok, let’s do another. So we discuss, how often can we sustain doing this? What’s the name? Do we need better cameras and mics? What about lighting? Maybe we can get Shaun to help us? Should we use Hangouts or a different app or technology. So many unanswered questions and so much room to keep making low quality attempts at this podcast.

This Monday came and we didn’t have answers to any of our outstanding questions. I debated if we should do another “off air” episode, just so we can practice more. I hesitated. Jason’s reply? “Let’s do it live”

And so we did. Our second “pilot” episode went live yesterday, August 24 at 3pm. And it was as you’d expect, less than perfect. I somehow accidentally turned off the voice detection Google Hangouts uses to automatically decide which face to show in the video, so you see Jason’s face throughout the beginning until Shaun comes in and tries to fix our setup. Then you can see I’m distracted by the monitor and manually switching who is seen in the video.

People still enjoyed it.

This is how life works. This is how most things we enjoy and call successful start. They aren’t as good as we want them. They need a ton of practice. And even when we get something to the place where it is good, now we have a new challenge: our hesitation at being bad again.

Just keep publishing. Keep putting out the stuff that’s not perfect. When you find yourself in a spot where the expectations are too high, just find another spot. We need that place to draw from.

Jason and I are going to keep publishing these “imperfect” chats of ours. You should follow us on Twitter: @jasonfried and @natekontny. We’ll talk about not just the things we see other folks struggling with and asking questions about, but the things still bugging us. Life is far less than perfect for us, and we keep leaning on each other to help us through our current challenges. Hopefully recordings of us hashing them out will prove useful to others going through the same.

If there’s anything you’d like us to ever cover, please hit us up on Twitter or ask in the comments of our SvN posts. We’d love to hear from you.

What kind of company are you?

Claire Lew
Claire Lew wrote this on 12 comments

Last month, we made a huge mistake.

We’d built a new feature in Know Your Company a while back. During that process, we’d accidentally written a bit of code that caused private responses to be revealed to new employees in a company.

This means that for the past six months, when new employees were added to Know Your Company, they were able to view responses that only their CEO was supposed to have access to.


It was a horrible mistake… and we were just finding out about it now. It affected about 80 companies, and hundreds of employees. My stomach still feels sick when I think about it.

One of our customers noticed the error, and was kind enough to tell us. Aside from that, our other customers hadn’t noticed the problem (or, at least hadn’t told us).

Now I was faced with a big decision… Should I tell our other customers about it?

One could argue that, if customers hadn’t noticed, why say anything? Why rustle feathers, especially when the damage had already been done. There wasn’t anything that our customers could do about it.

Saying something could cause our business harm. Customers might be angry. Some of them might even leave.

Or, we could come clean. I could be upfront about what happened, own up to our mistake, and say how terribly sorry we were. Sure, we risk losing business. But what about the risk of losing the trust of our customers?

Trust, after all, is everything. If you don’t have the trust of your customers, what do you have? If your customers don’t trust you, they won’t be your customers for much longer.

I also thought: If I were a customer, wouldn’t I want to know? As a CEO myself, I would want to know that those private responses had been accessible to my new employees. Even if I couldn’t do anything about those private responses going out, I would want to know that it happened in the first place.

To gut-check myself, I called up Jason Fried, the CEO of Basecamp. I wanted to get his two cents, and make sure I was thinking about this right. (Basecamp originally built Know Your Company, and is a co-owner and advisor to our business).

Here’s what Jason said to me: “I like moments like this. Moments like this are an opportunity to show what kind of company you are. You get to show your customers what you stand for.”

Those words were all I needed to hear.

I knew what kind of company we were. I knew what we stood for.

I decided to personally email the eighty-some CEOs affected by our mistake. In a short note, I explained what we messed up, and how sorry we were.

I offered a small credit as a token of how bad we felt, knowing of course that it wouldn’t make up for it. I gave folks my personal cell phone number and told them to call me anytime if they had questions, concerns, etc.

Then I braced myself for the reaction.

I got a flood of replies from customers. Not a single one was negative. A few folks were concerned (as they ought to be!)

But no one was angry. No one left.

In fact, the response from customers was overwhelmingly positive. People said, “Thank you for letting me know” and, “No biggie, these things happen.”

One of our Dutch customers emailed me saying, “We have a saying in Dutch: waar gewerkt wordt, worden fouten gemaakt that translates to ‘mistakes are made if you’re doing work’.”

Another person replied to me, “We all screw up from time to time. Go have a cocktail ;)”

I even had one customer who said he was so impressed with the email I’d sent, he’d forwarded it to his entire company as an example for how to handle a mistake.

Our mistake became a positive moment for our company. It solidified who we were, what we stood for, and showed our customers that too.

We proved that “putting our customers’ best interest first” isn’t just something we say – it’s something we do. We gained our customers’ trust and confidence as a result.

Mistakes are bound to happen. You’ll never entirely avoid them. So your customers aren’t going to judge you on whether or not you’ve made a mistake – they’ll judge you on how you handle it.

Do you come clean immediately? Do you say how sorry you are? Are you genuine about it?

It’s a hard thing to remember when you’re in the middle of a fire. You’re faced with the prospect that admitting a mistake could cost you customers, your reputation, and a lot of money.

When you’re in that moment, simply ask yourself: “What kind of company are you?”

You’ll know what to do.