March 2016 Basecamp 3 updates!

Hey all! Wow the last few months were busy for us. You too?

We’ve got a lot of new stuff to share with everyone. Everything listed below has already shipped and available in your Basecamp.

Here’s what’s new

  • Ever wish you could mark something you already read as unread again? Well now you can! And you can also turn notifications off for almost anything right from the Hey! menu as well.

Mark read as unread, and “stop notifying” right from the Hey! menu
  • The Sample Basecamp now includes a quick tour video in the lower left corner to help everyone get acquainted with the basics.
  • Huge cleanup of the Notifications Settings screen. We’ve grouped the options into three sections: What, How, and When. Now it’s much easier to see the options and understand the controls.

You can get to your Notifications Settings screen by clicking your avatar in the top right corner in Basecamp 3 and clicking the “Change notifications settings” link.
  • We’ve also made it possible to replace the numbers inside the orange unread indicators with a small orange dot. If you’re like me, I don’t like being nagged by numbers. An indication that there’s something new is enough. Now it’s much calmer around here.

You’ll see this option under the “How” heading on the Notifications Settings screen. Check the box if you want numbers, uncheck it if you just want the quieter, more peaceful dots.
  • We’ve made it simpler to turn notifications off on a thread on the iOS app. Now it’s just a single tap at the bottom of any thread. Before you had to go into a menu and deselect yourself.
  • Made composing new messages and documents friendlier on smaller laptop screens and big huge screens. The buttons no longer fall off-screen on the MacBook Air and you get a full-screen experience on a Cinema display.
  • Replaced stars with pins on Basecamps and Campfires. This update rolled out across the desktop apps and the native mobile apps as well.
  • Added two new wonderful email reports to keep you up to date every morning and once a week: 1. You can subscribe to the Daily Activity report and have all of yesterday’s activity emailed to you in a single email the next morning at 9am (to subscribe, click Latest Activity in the menu bar and look for the button top right), and 2. You can subscribe to the “What’s on my plate?” report and get all your assignments emailed to you every Monday morning at 9am (to subscribe, click the avatar menu top right, select “My assignments” in the menu, and then look for the button top right).


Summaries delivered to your inbox. In this example I’ve turned both on.
  • Made it possible to view your to-do assignments sorted by due date. Big improvement here. On the My Assignments screen you’ll see two tabs if you have any dated to-dos.

To-dos with dates are neatly grouped together, with the ones due soonest at the top.
  • Added an “applause report” that show you who’s clapped for you. You can access that from your avatar menu, then by selecting the “Who’s clapped for me?” option in the menu.
  • Shipped native apps for Mac and Windows. You can find them linked up here.
  • Shipped a brand new marketing site at Basecamp.com which does a better job explaining what Basecamp is all about.
  • And a variety of bug fixes and performance enhancements as well. Thanks for everyone who’s helped us track down issues — Basecamp gets better every day because of your help.

April’s just around the corner. More updates to share in about a month! Thanks again for using Basecamp 3!


Not a Basecamp 3 customer yet? We forgive you. But come on — it’s time to make it easier to keep everyone on the same page about whatever it is you’re working on together. It’s entirely free to try with no time limit, too.

To Smile Again

Recovering from the paralysis of burnout

Take a moment and imagine: what if you could only smile with half of your face?

In fact, give it a try. Relax the left side of your face, and smile — really, really smile — with the right side. Imagine you’ve just heard something hilarious, or wonderful. Show some teeth! But only on the right side. You might want to put a hand on your left cheek to make sure you’re not moving any muscles there.

Feels kind of goofy, doesn’t it? Awkward, and unnatural.

Now. Imagine that this was your actual smile. How would it affect your interactions with people? How would it affect your self-image?

How would it affect you?


For a few days leading up to January 19th, my tongue tasted like wintergreen.

This was odd. I’d never experienced anything like this before, and while I actually really like wintergreen, having it perpetually on one’s tongue is a bit of a turn-off. I tried brushing my tongue with my toothbrush. I tried mouthwash. I tried everything I could think of, but nothing would remove the odd taste.

I wasn’t too worried. I figured it would wear off eventually, and I’d probably never even remember the episode.

Turns out, I was half right. It would wear off, but I would certainly never forget the experience.


The morning of January 19th, I got up and went about my morning routine, but while I was shaving I noticed something odd. The left side of my face felt like I’d just been to the dentist. Numb, I thought.

Only, that wasn’t right. I could feel it just fine. It was more the loss of control that you feel after being shot full of dental anesthetic. My left cheek, and the lips on the left side of my mouth, were slow. I couldn’t think how else to describe it.

Unlike my wintergreen tongue, this freaked me out. My thoughts immediately went to worst case scenarios. Tumor? Stroke? I visited my doctor as soon as I could, that very morning.

He nodded as I explained the situation to him, listening as I described the facial symptoms as “not a numbness, but more like I can’t move it.”

He nodded once more when I finished, and smiled reassuringly.

Bell’s palsy!” he told me.


Bell’s palsy…? “Tell me more about that,” I said.

So he did. Apparently there is this thing called the seventh cranial nerve. It starts in the back of the head, and then branches in two. One branch passes through the left inner ear, the other through the right, and from there they run to each side of the face. This nerve controls facial expressions, taste, and the closing (but not opening) of the corresponding eyelid.

All it takes is for something to happen to one of those branches — some kind of trauma, or infection — and those nerve impulses can no longer propagate. Your face stops moving. Your eyelid can’t close. Your sense of taste goes away.

But just on one side.

The doctor assured me it was (almost always!) temporary, and that it would go away in a couple of weeks. He told me to expect it to get worse before it got better, and prescribed some medication which, he said, would speed its recovery.

I swear, this was the weirdest thing to happen to me since puberty.


As promised, it got worse over the next few days, until the left side of my face was completely paralyzed. I would look in the mirror and strain for any motion at all — a twitch, anything! — but it was no use. My face would not move.

What is more, because my left eye wouldn’t close all the way, it watered constantly. I carried tissues with me everywhere and used them to help hold my eye shut. Driving was difficult, because the world looked distinctly moist with an eye full of tears. And at night, I had to sleep with my eye taped shut to keep it from drying out and being damaged.

(Let me tell you, sleeping with one eye taped shut is about as much fun as it sounds.)

I was constantly surprised by all the things I couldn’t do. Eating was difficult, because food kept wanting to dribble out of the paralyzed half of my mouth. I couldn’t whistle at all, which was a significant hardship for a compulsive whistler like myself.

I couldn’t scrunch my eyebrows — trying to felt distinctly odd. I couldn’t roll my tongue, since the left half wouldn’t cooperate. I couldn’t puff my cheeks when the left side of my mouth wouldn’t hold shut. I couldn’t wiggle my left ear, or flex my left nostril. I couldn’t make my “Skeptical Mr. Spock” look, with one eyebrow raised. All the stupid human tricks I knew were utterly useless.

I couldn’t say my “P’s” and “F’s”, either. Try it: put the tip of one finger in the left corner of your mouth, and try to say something like “fluffy puppy.” This was especially problematic as I was currently reading “The Lord of the Rings” to my eight-year-old. Just you try saying “Frodo” and “Pippin” with half your mouth misbehaving!

And most devastating of all, I couldn’t smile. Leastwise, I couldn’t smile fully. My most sincere smile felt unnatural, forced, and ugly.

I tried to make the most of it. I tried to laugh at the weirdness of it all. My kids loved it when I would say it was my “SUPER FACE!” (Remember, my “P’s” and “F’s” were ridiculously plosive.) I tried to joke, and be patient with the entire experience.

But I was profoundly affected by being unable to smile. I felt trapped behind my eyes, unable to really express what I was feeling. I was brought face-to-face with depression, something I’d never really battled before.


On January 30th — eleven days after my initial diagnosis — I discovered that I could twitch the muscles at the corner of my mouth. Just the tiniest bit, but it felt like a marvelous victory! By the 4th of February, I could produce an airy whistle, and immediately began putting it to good use. By the 7th, my face was at about 50% of its original function.

And by the 14th, I was ready to declare myself officially healed.

The experience had passed, but I had been deeply affected. It had touched me far more profoundly than I would ever have expected. I was a different person than I had been just four weeks before.

And I could smile again.


In 2005 I was hired by 37signals, and one of my first tasks was to devise a way to deploy Basecamp. Would you believe, it now ran on two servers, instead of one? (The horror! Oh, the complexity!) The “log in and svn up” deployment method no longer sufficed — at least, it was no longer sufficiently convenient.

So, in August of that year, I released “Switchtower”, a tool for automating deployment to multiple servers simultaneously. (Some months later, a trademark dispute caused me to rename the tool to “Capistrano”.) In an amazingly generous gesture, DHH and Jason Fried gave this tool to me. (Amazing, right?) It was mine, they said, to do with as I pleased.

For three years, Capistrano was my baby. I worked — mostly alone — to maintain it, to extend it, to enhance it. I loved it, and I loved the community of amazing developers and sysadmins that grew up around it. I loved helping to ease the pains that people were feeling with deployment and server administration. And I loved showing people how Capistrano could improve their lives.

It was a lot of fun.

And then, in August of 2008, Mark Imbriaco (37signals’ sysadmin at the time) and I had the opportunity to teach a series of seminars about Capistrano, showing people how to make the best use of the tool in a variety of situations. We were really excited. We signed contracts and started planning our curriculum, dollar signs in our eyes and heads full of dreams of teaching.

And then I mentioned the plan to DHH. His reaction was not what I had expected, at all. Instead of being excited for us, he expressed concern. How much time would this take away from our responsibilities at work? What were our priorities? Where I saw an opportunity to do what I love — teach! — he saw a conflict of interest.

He was right. He was absolutely right. In hindsight, this was something I should have thought to talk to him about from the start. But it never occurred to me, and David’s insistence that we not teach the seminars was like a bucket of ice water over my head. I felt like I had been punched in the gut. The metaphorical rug had been pulled out from under me.

I don’t fault David at all, and I even agree that he was right to do what he did. But at the time I felt immensely betrayed. Capistrano was supposed to be my baby! Why, then, had I just discovered a limit beyond which I was not allowed to take it?


My passion for Capistrano waned rapidly after that. All of my open source projects suffered. In just six months, I went from being rabidly passionate about my projects, to feeling nothing but exhaustion and frustration when I thought about them. What had once been a joy had become an obligation.

And in February of 2009, I walked away from them. I announced my resignation, effective immediately, from Capistrano, Net::SSH (and related libraries), and the SQLite3 bindings I’d written for Ruby. I just…walked away.

My blog languished as I went many months without posting anything at all. (I rallied briefly at the end of 2010 and wrote a series of posts about maze algorithms, but it was sadly temporary.) By September of 2011 I was done blogging, and walked away from that, too. In 2012 I stopped tweeting.

I was withdrawing, and I didn’t know why. I’m sure I had no idea what was happening to me. By 2013 I was struggling to be motivated for any programming task, including the work I was being paid to do. I began to be frightened by “what if’s”. I had four young kids. What was I supposed to do if I couldn’t work? What would happen to us?

I tried (unsuccessfully) to reach out to a psychiatrist. I even wrote a series of short stories — for myself only — in which I put myself in a psychiatrist’s office and tried to answer the questions I imagined they would put to me. (This was, surprisingly, extremely therapeutic, and I would recommend it to anyone. It was, however, not enough for me.)

Jason and David were hugely sympathetic and supportive. One of the perks of working at Basecamp is a paid month-long sabbatical every three years, and they let me take an extra one, to help me get on my feet. They let me work as the primary on-call programmer for three months straight, an opportunity that let me work at many small problems every day, instead of one or two longer (and potentially overwhelming) tasks.

In the end, though, none of it was enough. My productivity had dropped to a trickle, ten percent or less of what it had been six years before. I felt horrible, guilty every time I thought of the paycheck I was drawing for work I was struggling enormously to do.

To understand what it was like for me, consider this snippet of Ruby code. It contains a simple bug. Can you find it?

class Circle
attr_reader :radius
  def initialize(radius)
@radius = radius
end
  def circumference
2 * radius * Math::PI
end
  def area
radius * radius + Math::PI
end
end

The definition of the area adds pi, instead of multiplying by it. It’s a bug that would take an experienced programmer a minute or less to find. But looking at code like that, I would see nothing but a wall of text. I would grow exhausted just trying to scan it.

“I’ll just check my e-mail, first,” I’d say. Or, “I need fifteen minutes for some Kerbal Space Program, and then I’ll find that bug.”

(Only, anyone who’s ever played KSP knows that you can’t play just fifteen minutes of it. Suffice to say that I guiltily played a lot of KSP in 2013.)


I was paralyzed, emotionally and intellectually. The things I used to love to do, and which I used to do almost effortlessly, had become enormous, Sisyphean tasks. I couldn’t make myself care about work. Nothing could motivate me. I could not force myself to move beyond the mental blocks that sprang into existence at the very mention of computer programming.

My smile, as it were, was crippled. I was working with only half my heart, because the other half was frozen, palsied. My passion felt awkward, forced, and unnatural.

I was burned out.


Burnout is a dark place. Maybe especially in a male-dominated culture like software development, because male culture has this weird thing about showing weakness and sharing feelings. We don’t generally do either one easily.

When you’re burned out, you’re operating at a fraction of your capacity. Things that used to come easily are suddenly almost impossible. This does bad things to your self-image. It makes you feel weak. And it makes you feel ashamed of that weakness. “I should be able to do this!” you say. “I should be able to power through.”

And when you can’t, you feel even worse, and you spiral down, and down. Like someone with Bell’s palsy, embarrassed of their shattered smile, you turn inward. You try to hide your weakness. You put up a front, and conceal your broken self behind it.

The days turn to weeks, and the stress mounts. You hide yourself deeper. Your productivity falls further. People start to notice that something is wrong, but every well-intentioned question only adds to your shame.

“Why can’t I do this? I used to be able to do these things. I used to be strong…”

And so it goes, darker and deeper, until something breaks.

It came to a head at the beginning of April 2014. I spoke with Jason and David, explained my situation, and said goodbye to my friends at Basecamp. It was the hardest thing I’d ever had to do. Basecamp was my dream job. I loved the people. I loved the environment. But I just couldn’t do the work anymore.


Was that the end? Hardly. Burnout never has to be the end, and in my case, it’s really been more of a new beginning.

Ultimately, I took almost a full year off. For the first month, I don’t think I looked at my computer at all. My wife and I experimented with starting a creative arts studio for children. I carefully did some programming to support a novella I wrote about path-finding algorithms. And in September of 2014 I signed with Pragmatic Programmers to write a book about generating mazes.

Through it all, my wife and I talked about what we wanted to do. We tried a lot of different things. We imagined the future and where we wanted to be in it. We took stock of what we had, and what we could do, and tried to imagine creative ways to apply those resources.

And bit by bit, my passion for software started to come back. It was like a forest had burnt to ashes, and the little seedlings just needed some time, undisturbed, to start poking up through the blackened char. I could feel the first faint twitches that heralded the end of my paralysis.

By the time January rolled around, I realized that I had a few software projects going on the side. This was a new feeling! I hadn’t done software for fun in a long time. It felt good.

I felt…better. Stronger. Different.

I felt like — maybe — I was ready to try again.

Nervous — terrified! — I put together a pitch, and asked the world to hire me. With some advice from Jason Fried and Jeff Hardy, I eventually settled on a contracting gig, and I have been blissfully self-employed ever since.

Burnout was hard. It was not something I would have chosen for myself, and I wish I had known then the things that I know now. Probably I would still be working at Basecamp. My life would be very different than it is, I’m sure. But burnout happened, and I made it through, and I think I’m a better person for it.

I think I’m more balanced. I have a greater appreciation for what I lost during those darker times. My smiles are a bit wider, and a bit more sincere, and maybe a bit more touched with wonder.

Self-employment? This is not a place I ever imagined I would be. It’s not a place I ever imagined I would want to be.

But it is where I am now. And I’m smiling again.

The Lost Coffee Order

A great experience even when things went wrong.


Last month, I sent a surprise gift to one of our customers. In an unfortunate series of events, the gift package never made it to her.

Here’s the email I received from the coffee company I bought the gift from:

I spoke with your customer and she says that they did not receive the package and has spoken with her neighbors to be sure that the box was not delivered to one of them by accident. On the day of delivery, there was terrible weather all across the area, including tornados. Many businesses and all of the schools closed that day, but she says that their office did not close. It is possible that either the postal delivery person was in too big of a hurry that day because of the weather and chose not to deliver the box or there was a substitute delivery person who did not know where to leave the package.

I am very frustrated that this has happened. I am going to re-flavor the coffee (Hazelnut) today (it has to sit overnight) and deliver the coffee/ tea order to her myself tomorrow. I’ll let you know if I get any more information.

Thanks, again, for the order.

Clarke, Highland Coffees

They really did a great job turning this potentially negative situation into a great one. Instead of blaming the post office or leaving me to figure out where the package went, Clark sent out a brand new order. Clarke even shared in my frustration that the experience wasn’t perfect.

Explanation? Check.

Empathy? Check.

Promise to follow-up? Check.

Even though this order might take an extra little bit to get to the customer, I’d still order with Highland Coffees again in the future. It turned out to be a great experience even when things went wrong.


We work hard to provide the same stellar experience with our customers. If you haven’t yet, go check out Basecamp 3!

You Aren’t Gonna Need to Design It

A short tale of building what matters and skipping the rest.

We just started a new email campaign at Basecamp, and it’s something we’ve never tried before. It’s a sequence of three automated emails that we send to new customers who fit a certain criteria. In these emails, we ask if the customer needs help getting started, and what they were hoping to do with Basecamp.

We originally thought of this project as a marketing exercise, but so far it’s giving us insights that reach way beyond marketing.

One thing that’s special about this campaign is that the messages are sent directly from me (and a couple of other folks), and we’re personally responding to anyone who writes us back. The replies go straight into our real inboxes — not into our company’s support help desk or some no-reply black hole. This is a ton of work to maintain, but we’re learning a lot and developing new relationships with people.

While we were setting up the nuts and bolts for the campaign, we got stuck on a tricky detail. We wanted the automatic sequence of emails to immediately stop if a customer replies, because it would be weird if we sent more canned messages after personally interacting with someone.

Tom asked me how it should work…

There was no obvious way for us to stop the sequence automatically. We probably could have devised some fancy system with an administrative interface to handle it, but would it be worth it? At that point we had no idea what was going to happen with the campaign as a whole.

How many replies would we get? Would this unsubscribe issue be a serious problem or just a minor issue? Was the overall campaign any good, or would we stop it after 3 days because it was performing poorly? There was no way to know.

In cases like this, you can either anticipate all the likely possibilities and build lots of things to insure yourself against potentially bad situations, or you can ship what you’ve got, wing it, and be prepared to make changes as you go.

As is our style, we ran with the latter…and it was completely fine! Most people leave our original email quoted below when they reply. Then we click the Unsubscribe link for them. That’s it. It’s lo-fi and works in 99% of cases. If the quoted email isn’t there, Tom programmatically unsubscribes the person by hand. We have to do that a couple of times per week. No biggie at all.

So this is YAGNI in practice. You might be familiar with YAGNI as a programming-specific concept, but I think it’s just as applicable—if not more so!—on the design side.

Design is often a matter of diving headfirst into an unknown abyss, and preparing to modify your thinking based on what you learn. When you’re doing that, there’s no sense in trying to protect yourself from bumps along the way. The bumps are the whole point of the exercise.

It’s certainly prudent to have an escape button handy so you can shut everything down if your world quickly descends into utter chaos. But otherwise, get ready, strap yourself in, and go for it! That’s the only way to find out what happens next.

The team, the years

48 of the best people I know work at Basecamp.

The Basecamp team as of March 23, 2016

We’ve been working at Basecamp for 5, 6, 5, 1, 5, 4, 2, 3, 15, 1, 2, 1, 5, 2, 3, 8, 17, 7, 5, 1, 8, 9, 4, 5, 6, 5, 1, 5, 4, 1, 5, 7, 4, 3, 5, 6, 6, 13, 11, 8, 5, 2, 6, 3, 2, 3, 6, and 3 years.

Collectively, across just 48 people, that’s 244 years of experience together. As a business owner it makes me feel great seeing longevity, loyalty, and low turnover as a common theme. In return we try to offer the best benefits in the business.

Something I always keep in mind: Behind these people are family trees. Husbands, wives, partners, children. As a business owner I feel a responsibility to these other people too — I don’t want to create tired, anxious, resentful employees who bring those emotions home with them. It’s not just the quantity of hours at work that affect life at home, it’s the quality and impact of those hours spent at work, too. A healthy work-life balance isn’t about separation as much as it’s about how one influences the other.

At Basecamp we’re not just building a different kind of product, we’re building a different kind of company. The kind of company we’d want to do business with if we were in the market for a product to help our company communicate clearly, work together better, and form stronger bonds with each other.

An observation: Looking at the picture at the top of this post, it’s clear need to work harder on diversity. We’d also like to have a roughly 50/50 split male to female to better represent the population at large. It’s tricky for us since we don’t hire often — maybe just a few people a year — so it’ll take some more time to get to the ideal mix, but we’re aware of it, working on it, and have been getting much better at it over the last couple years.

Want to join the crew? We’re currently looking to add two new designers to our team. One focused primarily on product design (Basecamp the apps), and one focused primarily on marketing design (Basecamp.com the site). From time to time we cross over — product designers work on marketing stuff and marketing designers work on product stuff. If you’re interested, email me in a way that demonstrates your skills, your character, and helps you stand out amongst the hundreds who apply whenever we have openings. Looking forward to hearing from you.


Want to see what this team makes together? What we spend our days improving and perfecting? Then check out the all-new Basecamp 3. It’s unlike any Basecamp before it, and a unique product in the industry. In many ways it’s our company operating system, and we’ve seen how it can turn any small business into a better business. Want to find out more about Basecamp 3? Email me and I’ll give you a personal tour. — Jason Fried, CEO, Basecamp

Sleep deprivation is not a badge of honor


Forgoing sleep is like borrowing from a loan shark. Sure you get those extra hours right now to cover for your overly-optimistic estimation, but at what price? The shark will be back, and if you can’t pay, he’ll break your creativity, morale, and good-mannered nature as virtue twigs.

Now we all borrow occasionally, and that’s okay if you fully understand the consequences and don’t make it a habit. I did that the other night. We pushed an update to our single-signon system for Basecamp, which had me working until 1:30 AM. That wouldn’t have been so bad if it wasn’t because I got woken up at 5 AM to help deal with an issue that arose. But the costs the following day were typical, numerable, and high:

  • Stubbornness: When I’m really tired, it always seems easier to plow down whatever bad path I happen to be on instead of reconsidering the route. The finish line is a constant mirage and I’ll be walking in the desert for much longer than is ever a good idea.
  • Lack of creativity: What separates programmers who are 10x more effective than the norm is not that they write 10x as many lines of code. It’s that they use their creativity to solve the problem with a tenth of the effort. The creativity to come up with those 1/10 solutions drops drastically when I’m tired.
  • Diminished morale: When my brain isn’t firing on all cylinders, it loves to feed on less demanding tasks. Like reading my RSS feeds for the 5th time today or reading yet another article about stuff that doesn’t matter. My motivation to attack the problems of real importance is not nearly up to par.
  • Irritability: If you encounter someone who’s acting like an ass, there’s a good chance they’re suffering from sleep deprivation. Your ability to remain patient and tolerant is severely impacted when you’re tired. I know I’m at my worst when sleep deprived.

These are just some of the costs you incur when not getting enough sleep. None of them are desirable. Yet somehow it seems that the tech industry still celebrates a masochistic sense of honor about sleep deprivation. At times it sounds like bragging rights. People trying to top each other. For what? To seem so important, so in need, so desired that humanity requires you to sacrifice? Chances are you’re not that special, not that needed, and the job at hand not that urgent.

Software development is rarely a sprint, but mostly a marathon. Multiple marathons, actually. So trying to extract 110% performance from today when that means having only 70% performance available tomorrow is a bad deal. You end up with just 77% of your available peak. Bad trade.

This is why I’ve always tried to get about 8 1/2 hours of sleep. That seems to be the best way for me to get access to peak mental performance. You might well require less (or more), but to think you can do with 6 hours or less is probably an illusion. Worse, it’s an illusion you’ll have a hard time bursting. Sleep-deprived people often vastly underestimate the impact on their abilities, studies have shown.

So get more sleep. Stop bragging about how little you got. Make your peak mental capacity accessible.


I originally wrote this post back in 2008 (and a version feature in REWORK). But after a couple of kids arrived, I remembered just how silly it is to voluntarily subject yourself to sleep deprivation. When you’re responsible for another little human, you have no choice. When you’re just trying to ship a new feature or a product, you absolutely do. Go The Fuck To Sleep.

Simple just isn’t that important

Declaring your love of simplicity has long been a prerequisite pledge for anyone working on products. It’s the perfect placeholder word for everyone to load up with their own personal aspirations, all the while nodding in agreement with someone holding diametrically opposed ideas. Even the most obtusely designed products will have a parent ready to explain “it’s actually quite simple if you just…”

Beyond the trouble of pinning down exactly what simple means is certifying its value. “Simple” is just one of the many qualities we can use to evaluate products, and it is by no means the most important. To use a trite phrase to describe another: Simple is overrated!

Here are but a few qualities I’d take over simple:

  • Useful
  • Clear
  • Fun
  • Satisfying
  • Inspiring
  • Endearing

I wouldn’t just rank “simple” low on my list of priorities for a finished product, but also for the tools we use to take us there. My favorite tool is the programming language Ruby. It is anything but simple. Thousands of methods across the standard library, so many keywords I can’t even tell you the number. Full of subtlety that directly relates to its wonder and delight.

Basecamp is in the same boat. It’s clear, it’s just enough, but it is not “simple”. We literally have hundreds of individual screens spread across 6 major features that could each be individual products (and are!).

The value is derived from solving many of the problems most people face when trying to make progress together. It tries to do so in a clear and playful manner. “Simple” is not high on the list of priorities, and the product is much better for it.

It’s time to knock “simple” down a peg. It’s just not that important.

No Reply Addresses

Go check your inbox right now. I guarantee you’ve got a few emails from a “noreply@myapp.com”. A quick search through mine yielded 28 different no-reply emails from 28 different companies. It’s not limited to only big companies either. Tiny startups use them to send out their newsletters, invites, notifications, etc.

When I get an email from a no-reply address, I know that company doesn’t want to hear from me. They’re telling me that while I need to read this email, they won’t be reading any replies that I want to send them about it. They can consume my time but they won’t spare any of their time for me.

In short, they don’t care.

Sometimes it’s unintentional. A new startup sees that other businesses are doing it so they do. Sometimes it’s intentional because a company doesn’t want to get bombarded by auto-responders about being out of the office. And sometimes it’s justifiable. If your app sends out email notifications for certain actions, like checking off a to-do or sending a message, then I can understand the use of a no-reply email address.

But overall, stay far, far away from them.

You want your customers to be talking to you. You want them sharing ideas and experiences with you. Instead of a no-reply, set it to your support email address. Make sure someone will see any replies that a customer sends. Sure, you’re going to get lots of auto-responders. That’s why your email app has filter and rules you can set up.

Embrace the idea of a yes-reply email address. It’ll keep that communication lane open between you and your customer. It’ll make customers realize that you do value their time and will give them some of yours if they want it.

Your goal should be to talk more with your customers. Switching your no-reply addresses over will be a great first step towards it.

The tool we built to keep everyone in the loop at Basecamp

From teams to individuals, we aimed for a straightforward, consistent system to communicate the occasional, the week-to-week, and the day-to-day to everyone across our company.

No matter the company, once you reach a certain size — and it’s not very big — you begin to have communication challenges.

There are dozens of challenges, but for this article I’d like to focus on this one: Keeping people across the company in the loop about what’s going on in the company. By what’s going on I mean what everyone’s working on at a macro and micro level. What are we making together?

I happen to believe this is one of the most important things for any reasonably-sized company to get right. To me, reasonably sized means fewer than 100 employees (which represents 98% of all companies in the US according to the 2012 business census data). The method I’ll describe below can work with companies of any size, but you’d implement it a bit differently.


The challenge

As companies grow, keeping everyone up-to-date on everything that’s going on gets harder and harder. I’m not referring to statistics, spreadsheets, slide decks, reports, or abstract representations of what’s going on, but the simple way people describe what they’re working on to their friends. Everyone’s own words.

In some cases companies begin to under-communicate internally (people are left wondering what’s going on). To compensate, others begin to over-communicate internally (sharing the wrong level of detail too often, and sharing it in ways that make it difficult to follow or find).

The hard part is striking the right balance. The just-right spot where everyone knows enough, no one feels like they know too little, and no one feels like they’re being over-informed to the point of it being annoying or distracting. And doing it all at a variety of resolutions — big picture, medium-picture, and small picture — without overdoing it.


Our goal

We’ve been thinking a lot about how to do this right. At any one time we have dozens of projects in motion, so there’s a lot going on. We’ve experimented with a variety of methods over the years. We think we’ve finally landed on the perfect fit, the perfect way to do it.

For us the goal was simple: On a regular, ongoing basis, help everyone at the company learn things they didn’t know, discover stuff they might not have known was going on, and develop a better appreciation for their fellow co-workers and the work everyone does every day.

And, tangentially, as a positive side-effect, automatically create a library of progress — a collection of institutional knowledge, with day-by-day documentation by dozens of individual authors in their own words.


The solution

Here’s exactly what we did. It took 2 minutes to set up in Basecamp 3.

1. First, we created a new Basecamp in our account called “Heartbeats”. We invited everyone in the company to this Basecamp. We enabled three Basecamp tools: The Message Board, Automatic Check-Ins, and To-dos.

With these three tools turned on, our Heartbeats Basecamp looks like this:

3 simple tools all in one place keep every single person at Basecamp in the loop.

2. Next, in that Basecamp we created two recurring questions using Basecamp 3’s Automatic Check-ins tool. One check-in asks everyone “What did you work on today?” at the end of every weekday, and the other automatically asks “What will you be working on this week?” every Monday morning.

Automatic Check-ins puts Basecamp to work for you — it goes out and asks the questions, gathers the responses, and publishes them back to the Basecamp, and shares them with everyone automatically.

Like clockwork, Basecamp automatically asks Automatic Check-in questions via push on the mobile apps, in-app on the desktop, or via email depending on how people set up their notification settings. It then gathers up all the responses and then posts them back to the Basecamp as individual organized threads for everyone to see. And since they’re individual threads, people can attach follow-up questions, comments, or thoughts to anyone’s answer.

3. Next, we created a single To-do list called “Heartbeat requests” where anyone in the company can post a request for an update. Curious to know something that hasn’t been shared in a while? Add a to-do and request it! If you know who should write it, just assign it to them and Basecamp will let them know. If you don’t, just add the to-do with no assignment and someone will pick it up. You’ll see there’s a request for me to update the company on the progress of our designer search (we’re hiring!). I’ll write up that heartbeat shortly.

What do you want to know? Just say so!

4. And last, we posted a message to the Message Board letting everyone know that someone from their team should post a detailed update (which we call a “Heartbeat”) about what their team is working on every few weeks or so. There’s no exact time requirement, just every so often. A natural rhythm evolves. There’s also no specific guideline about how to write a heartbeat. People write in their own style, some follow other people’s leads. It’s just natural.

Here’s what our Heartbeat message board looks like:

Messages are automatically sent out to everyone in the company. People can then comment, ask detailed follow-up questions, and the discussions are kept nice and neat as separate threads so they’re easy to read now and easy to refer back to later. They are especially useful for bringing employees up to speed on how we work and how we share our work.

In the example above, you’ll see on February 26 Kristin updated everyone on a couple of new hires (welcome Carrie and Elizabeth!) for the support team, on March 8 Shaun updated everyone on the latest listener numbers on The Distance, on March 8 Ryan updated everyone on a new add-people-to-Basecamp UI he’s working on with George, on the 14th Conor filled everyone in on the progress on some major updates they’re making to the sign-in process, and on the 16th Taylor updated everyone on an important project the ops team has been working on. Note: Heartbeats are long messages and complete thoughts — usually a few hundred words each. I’ve shared an example down below later in this article.


The three amigos

With just three simple tools — a Message Board, Automatic Check-ins, and a To-do list, everyone in the company can now:

  1. Stay up to date every few weeks on major updates from every group across the company. People can also request an update if they feel like they’re missing something.
  2. Share what they’re planning on working on this week. This helps everyone have a general sense of what specific projects are happening, and what sort of progress we might all expect by Friday.
  3. Share what they did today. This isn’t about holding any accountable or for tracking performance — it’s simply used as a way for everyone to celebrate what actually happened in the company today. It’s a wonderful way to discover new work, see creative solutions to problems we’re trying to tackle, ask follow-up questions or offer an idea on something that’s being explored, and gain an appreciation for everyone’s day-to-day.

And because it’s all in a single Basecamp, everything is neatly organized and easily accessible all from one place that everyone in the company has access to all the time. And since every answer, every heartbeat, every to-do is its own unique self-contained thread, people can post follow-ups questions, request more detail, and discuss things in context without the conversation spilling over into other conversations.

It’s all right here in the “Heartbeats” Basecamp for everyone in the company to see.

The Director’s cut

Want to go deeper behind the scenes? Ok, let’s look at some actual examples of stuff that was written in our Heartbeats Basecamp.

A Heartbeat on the Message Board:

Conor shares some updates on a major rejiggering of the sign-in process. This was sent to everyone in the company so now everyone knows what that team will be working on over the next few weeks.

A “What did you work on today?” answer:

Sam shares what he worked on today.

And here’s another what did you work on today answer. This time from Ryan, with some sketches as well.

Ryan had a busy day. And he shared some rough cuts of an idea he’s working on.

Here’s a “What will you be working on this week?” answer by Wailin:

Andrea chimed in with her support.

A “What did you work on today?” by Jason Zimdars with some embedded product shots plus a few comments:

Nice work on that revised notification settings screen, JZ!

And one for those who really love behind the scenes stuff… Dylan wrote up a short “What did you work on today?” answer. A couple hours after he posted, I happened to notice he said “Discussion around whether we should allow file uploading to Basecamps that don’t have the Docs tool currently enabled.” I was curious what the team decided, so I posted a comment and asked a question. And a long and awesome, deep, well considered discussion ensued over the next few hours (not in-a-row, but spread out asynchronously). Check it out!



Ok… I know it was a lot, but I hope it was useful. Really it’s very simple. Spin up a Basecamp, flip on a few tools, set up a couple questions, and make an announcement. It just takes a couple minutes. And that same exact day everyone in your company will begin learning things they didn’t know, hearing about stuff they’ll be excited to hear, and overall having a better appreciation for the work everyone does every day.


Not a Basecamp 3 customer yet? What are you, crazy? Jump on! It’s entirely free to try (you can even just make a free Heartbeats Basecamp like the one I shared above). Just last week another 10,786 companies signed up to get started using Basecamp 3! We’d love to have you as a customer too. Any questions? Want a personal tour? Need help setting something up? Just let me know, I’m happy to help any way I can. Thanks. -Jason Fried, CEO, Basecamp

Snapback Cache — What we use to make our infinite scrolling feeds at Highrise awesome.

Many apps today have some concept of an infinite scrolling feed: Facebook, Twitter, LinkedIn and many more. Almost all of them suffer from the same problem. If you click on something in the feed that brings you to a new page, when you hit the back button or try to return to that original feed, your place is lost. All the scrolling is gone.

At Highrise we had that same problem. So this is the library we use to fix that. We call it our Snapback Cache, and it’s made a big improvement to how people can use infinite scroll in our app and still get a lot of work done without losing their place.


Another great thing about this is it operates on the URL, so you can have multiple infinite scrolling feeds to cache. At Highrise we have a “main activity” and then activities for a Contact, etc. They each get their separate cache. To keep a manageable memory footprint for your browser, we keep 10 caches as a maximum.

The basics of how it works

Using this small javascript library, you hook it up to the click events on things in your infinite scrolling feed. For example:

https://gist.github.com/n8/96475a20b36e87973671

Now when people click the links inside our “recordings” container, the stuff inside the current recordings container is cached locally using the browser’s session storage.

Then the javascript library watches the load event of any pages being browsed. If the library sees that that browser’s URL is a url we’ve already cached, and it’s not “too old” (15 minutes), we replace the contents of our container (#recordings in our example) with the cached version, and scroll the browser to the place where it had been cached.

This sounds easy, but there are certain things we bumped into that the library also helps with. Things like disabling autofocus events that mess up scrolling and making sure things in the cache can actually be more granularly ignored or even refreshed.

Syntax and how to use it

var snapbackCache = SnapbackCache({ options });

Here are some example options:

https://gist.github.com/n8/b7036e96761a98709ca7

bodySelector is mandatory. It tells us what on the page you want to cache.

finish is a function of things that you’d like to happen before the page is cached to get the page to get cleaned up. For example, we already try to get jQuery animations to finish, but if there’s anything else on the page that might be animated or dynamically changing when someone is trying to navigate your site, you probably don’t want those “transitional” things cached. In our case we have a search bar that we want cleared up before things are cached.

removeAutofocus is a function that removes any auto focus behavior from your page. autoFocus events can mess with the browsers ability to scroll to the right place. So we want to nip that in this function. In our case we have multiple autofocus things going on, so we clear all that up.

refreshItems is a function to help refresh anything that might have gone stale from the cache. You can use that in conjunction with a method available on snpachbackCache called markDirty.

So in our case, we cache a note or comment or email in our feed. But if someone at some point edits/deletes one of those notes, comments or emails, we have javascript call

snapbackCache.markDirty(id_of_dirty_thing);

Then when the snapbackCache replaces the cached contents it’s saving for us, it makes sure to call the refreshItems function you specify along with an array of “dirty items” you can do something with. In our case, we take all those dirty ids, and issue an ajax call that does all the work to refresh bits of the cached page.

nextPageOffset is a function that the Snapback cache can use to figure out what “page” your user is on. We take that page and store it along the cached contents of the page. That way when the cached page is restored you have the page number the user was on and get pick up infinite paging at the appropriate place. See the page-cache:loaded event below to do that.

Events

There are a couple of events we send out that are useful.

snapback-cache:cached is an event emitted as soon as the contents of the page have been cached into session storage

snapback-cache:loaded is an event emitted as soon as the contents of the page have been replaced. We use this at Highrise to set the appropriate offset for our infinite scrolling:

https://gist.github.com/n8/625c218e7ac8b79fdacb

nextPageOffset was calculated because we had setup a “nextPageOffset” function on the page cache.

Installation

1) Add the snapback_cache.js to your javascript stack.

2) Add a cache variable with the options set:

var snapbackCache = SnapbackCache({ bodySelector: "#recordings", });

3) Call snapbackCache.cacheCurrentPage() whenever you need to, and magically when people return to that url, the cache will do the rest.

Feedback

Source code available on Github. Feedback and pull requests are greatly appreciated. Let me know how we can improve this.

A ton of thanks to everyone at Highrise for helping get this into our stack. Especially Jon Phenow, Grant Blakeman and Michael Dwan for the edits and help getting it open sourced.

P.S.

You should follow us on Twitter: here, or see how we can help you with contact management using Highrise — a handy tool to help you remove anxiety around tracking who to follow up with and what to do next.