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

The Big Rewrite, revisited

David
David wrote this on 15 comments

Of the many axioms in the world of software, few rise to the occasion of Thou Shall Not Rewrite Your Application. Spolsky called it the “single worst strategic mistake that any software company can make” in his seminal 2000 essay Things You Should Never Do.

The Big Rewrite has been likened to all sorts of terrible things, but perhaps the most damning is its association with declaring technical bankruptcy. Basically, the only time it’s reasonable to embark on the terribleness of the rewrite, is when you’ve been profligate cowboy coder. When your mountain of technical debt is crashing down upon you.

So it’s the white flag, then. It’s giving up. Capitulation! The error of your inadequacy has finally caught up and will be taking you to the cleaners. Who the hell wants to be that sorry sob of a programmer!?

No wonder programmers are loathe to question the wisdom of NEVER REWRITE. Either they’ll reveal their own morally deficient ways, or they’ll be seen as apologists for others traveling that deviant path.

Now, axioms develop for a reason. Many a rewrite has been started and gone astray for all the wrong reasons. Either it truly was a result of technical bankruptcy, or, perhaps even worse, it was a result of perceived technical bankruptcy by a new team uninterested in learning why things became the way they are. As Spolsky quips, such a rewrite is basically the same software with more and different bugs!

But there are other types of rewrites. The one most dear to me is the “Don’t Try To Turn A Chair Into A Table” rewrite. It’s the one we committed when we launched the new version of Basecamp a couple of years ago. A full, start-over, everything-is-reimplemented rewrite of Basecamp because we wanted it to do different things.

Yes, Basecamp Classic and the new Basecamp both juggle many of the same ingredients of project management and collaboration, but they’re mixed together in very different curations. So while we could have gotten from A to B one carefully tested refactoring and commit at the time, it would have been a fool’s errand.

Starting over allowed us to question the fundamentals of how the application worked and how it was implemented. We were able to make leaps, not just skips.

A chair can indeed be turned into a table with enough effort. Both have four legs, and all you need to do is chop off the back of the chair, and somehow refasten it to the base to extend the surface. Oh, and maybe some new wood to raise the legs up higher. It can be done, but why on earth would you?

So we decided to leave the chair alone. People were using the chair, and still are – years after the new table premiered! And we got to build a beautiful new table that’s been serving us so very well for the last couple of years.

That’s really the bottom line here: We rewrote Basecamp from scratch and it turned out great! Better than great, actually. We got to leave well enough alone for people who had adopted and grown accustomed to Basecamp Classic, we got to offer a brand-new product to new customers that was the very best we knew how to make, and we got a greenfield codebase to enjoy as well. Plus-plus, would do again!

So what am I saying here? Rewrite willy nilly whenever you get blue over seeing a few modes of progress made cumbersome because of poor past decisions? Of course not. Embarking on The Big Rewrite is not a choice to be made lightly, but a choice it remains. It should be one of the options on the table.

If you’ve accumulated enough fresh ideas about how your application can be radically different and better, The Big Rewrite may very well be just what the carpenter ordered.

Why the hell not?

Jason Fried
Jason Fried wrote this on 9 comments

Whenever I dive into something new, I try to find at least one “why the hell not?” moment. And when I can, I try to leave evidence of that moment in whatever it is that I’m building.

When we launched our company (37signals) back in 1999, we launched a black and white, text-only site without a single piece of portfolio work to be found. All the other agencies we were competing with had very flashy pages, loaded with pictures of their work. So why black and white and text only? Because why the hell not lead with ideas rather than compete on pictures? We thought it could be better that way. It worked out well for us.

One of my favorite why the hell not moments was when we were writing REWORK. One of the things that always bugs me about paper books is that you have to leaf through a dozen or so pages before you arrived at page one of the actual text. You’ve got the testimonials, the table of contents, the dedication/acknowledgement page, the copyright page, usually a blank page, a title page, etc… THEN you get to the book. This is also one of the reasons I really like cracking into a new book on the Kindle – you start right at the text.

So when we were talking to our publisher about how we wanted REWORK to be organized and designed, I asked them if we could put the copyright page at the end, rather than the beginning. It would be one fewer page to leaf through up front, and if any page was ignored more than the others, it had to be the copyright page. So why the hell not just put it at the back?

Initially our publisher didn’t know how to respond. No one had ever asked that before and they’d never seen an example of a copyright page in the back. But ultimately they said yes, so today if you pick up a copy of REWORK, and go to the last page, you’ll find the copyright page right there in the back of the book on page 280:

You’ll also find the acknowledgement page on page 279, rather than right up front:

Whenever I’m struggling with a decision that seems “unusual”, I’ll look back at these two pages in REWORK and remind myself that just because everyone else does something one way doesn’t mean you have to do it that way. Sometimes it’s just worth saying why the hell not and going for it.

Deploying to production is stressful for 12-14 year olds!

Nathan
Nathan wrote this on 3 comments

I watched in disbelief as the robot crashed into the mission model. It had run the exact same mission hundreds of times during practice. We never worried about this step; it was always successful. It was “dial-tone” reliable. We had practiced on multiple tables, under different lighting conditions, trying to chase out any strange bugs that might be lurking in our assumptions.


The Jet Team member in charge of the table grabbed the robot and put it back in base; extremely frustrated. With the clock running and the parents and other teams cheering; they had little choice but to try it again. Unfortunately, the previously rock solid mission was now failing as often as it was previously succeeding. It crashed into the mission model again. Once more, they incurred a 10 point touch penalty and brought the wayward robot home. Hands quickly and deftly replaced the attachment on the robot with the one for the next mission while the other team members yelled, “Skip it! Go to the next mission!” from the sidelines. 8 seconds later, the robot trundled out of base again, leaving 125 points unclaimed forever in the past, on its way to the next mission.


After the timer expired and the buzzer sounded, the team members collected the robot attachments and we made our way off the arena floor, mingling with the 7 other teams leaving the other tables, having experienced their own trials or triumphs over the last 150 seconds. Some kids looked to me for answers, utter confusion plain on their faces. “Mr. Anderson, what happened? Why did we miss the black line?!” Others looked at their teammates, “It never missed there before, did you load the right program?”


We were at the 2014 Kentucky State FLL Tournament. 47 teams had fought their way here through various regional competitions and we were all competing for a chance to go to the FLL World Festival in St. Louis.

JET Team at 2014 Kentucky State First Lego League Tournament


My mind raced back over the program they had written; I could see exactly where the program had been when it failed, but even if I knew the answer, I couldn’t tell them. Coaches don’t program in First Lego League; they shouldn’t even touch the computer or the robot. The temptation is too great to just “fix that that one thing”. So as we walked back to the pits, I fell back to my favorite activity; asking them to describe what they saw, not what they thought the robot did. Slowly, they talked each other through what happened, and the kids started to zero in on the problem.


The kids had written a line following program that would stop when the robot detected a certain reflected light intensity. It was pretty complicated, but they were very proud of it; and it worked very well. Without getting too technical, the robot measures a light intensity between zero and 100, zero being black, and 100 being white. Their program was instructing the robot to stop when it saw zero. There was no margin for error, and when the robot saw black as 1 (or more), it happily continued on its way, waiting for the magical zero measurement that would tell it to stop.


“Bump it up to five!” “Yeah, tell it to look for 5 or less!” Modifications were made, and the program tested once. We had another run coming up in 10 minutes, and had to get back to the arena. The kids looked hopeful as we walked back, confident they had fixed their issue and were going to put a respectable score on the board at last.


As the robot jerked to a stop at the beginning of the line it was supposed to follow, one of the team members looked at me. “It detected the green line as black, and stopped too early!” Resisting the urge to remind them again that the robot had no concept of “too early” and it just did what it was programmed to do, I nodded. Inside, I was ecstatic. They had seen the behavior of the robot and deduced the problem right away!


The sensor the robot uses to measure reflected light intensity uses a red LED. This leads to interesting effects when measuring the reflected light intensity of different colors. A good analog of this is the spy decoder devices that used red cellophane to reveal the hidden messages. Red shows up as white, and green is almost black. In bumping the value up to 5, they had inadvertently strayed into the “green range”.


This time, as we walked back to the pits, I didn’t have to ask anything as the team member who saw the problem explained what happened to the rest of the team. Various theories flew as to the best way to fix it, ranging from “rewrite the program” to “put it back the way it was”.


When we got back to our pit, rather than race back to the computer and start coding a fix, I had them talk through the observed behavior and the proposed solutions. Taking the ten minutes to talk about it, and analyze their options and situation proved far more valuable than spending those moments hacking at the code.


In the end, they decided they didn’t have time to rewrite the program, but they also couldn’t put it back the way it was with any confidence. Since they had bumped up to five, they decided to split the difference at two. They all agreed it was their best option under their time constraints.

3rd Table Run


The last run, due to their perseverance in tracking down this new bug and their acceptance of the time constraints they were operating under, turned out to be their best. Was it bug free? Nope. Did they get all of the points they hoped for? Nope.


Did they complete their problem mission? Yes!


Did they learn a little bit more about engineering, software development, hard deadlines, and deploying hot-fixes to production? Yes! After their last run, I had the opportunity to draw parallels between everything they had gone through during the last few hours and what we, as software engineers, do on a daily basis.


“I’m so exhausted!” exclaimed one of the team members, “I’m just mentally exhausted!”


“Congratulations on your first production deployment!”, I said. “They get better. Testing and practice are the best way to make them less exhausting, but they’re always exciting!”


In the end, we scored third place overall. No trip to the World Festival, but I got something better; I got to see the team become engineers.

Easy Listening

Wailin Wong
Wailin Wong wrote this on 15 comments

Yesterday we launched The Distance podcast and our show is now in iTunes. Be sure to subscribe!

In honor of The Distance podcast’s debut, I asked Basecampers what podcasts they’re currently enjoying and collected the responses. In some cases, you’ll see a recommendation for a particularly good episode to check out. (Basecamp is also sponsoring several podcasts, including Nerdette and Bullseye, which are mentioned below.) As I was compiling this list, I felt like I was naming every podcast in the world. But it’s just a sign of what a long and interesting tail there is in the world of audio. Here’s to discovering new things! And as a bonus, you’ll find recommendations for podcast apps at the end. Be sure to add your suggestions for any great podcasts (or apps) we’ve missed in the comments.
Business/Tech/Design/Productivity

  • 99% Invisible: Shaun calls it “probably the best podcast about design out there.”
  • Accidental Tech Podcast: Marco Arment, maker of the iOS podcast app Overcast (and many other things), is one of the co-hosts.
  • All About Android: News, hardware, apps, how-tos.
  • Back to Work: Merlin Mann and Dan Benjamin talk about productivity.
  • The Broad Experience: A show about women in the workplace. Joan recommends this episode about women engineers in Silicon Valley.
  • The Critical Path: Analysis of Apple and mobile technology.
  • Debug: A “conversational interview show” about software, with a focus on Apple.
  • Freakonomics Radio: From the authors of the best-selling book.
  • Jobs-to-be-done Radio: Listen to this 2013 episode featuring our very own Ryan Singer.
  • Marketplace: This well-known business news show is 25 years old!
  • Planet Money: NPR’s lively show about the economy.
  • Reply All: Stories about Internet culture from the duo that founded TLDR on WNYC.
  • StartUp: Public radio veteran Alex Blumberg documents his journey starting a podcast company.
  • Support Ops: Basecamper Chase co-hosts this weekly show about what makes a great customer support pro.
  • This Week in Google: Hosted by Leo Laporte and Jeff Jarvis.
  • The Tim Ferriss Show: From the author of “The 4 -Hour Workweek.”
  • TLDR: A show about Internet culture hosted by Meredith Haggerty, who took over when the show’s founders decamped for Reply All (see above).

Comedy

Pop Culture/Arts & Entertainment

  • The Adventure Zone: The McElroy brothers of My Brother, My Brother and Me (see above) play Dungeons & Dragons with their dad. Joan recommends Episode 2.
  • The Attitude Era: A look back at the World Wrestling Federation during the late 90s.
  • All Songs Considered: Jason Zimdars calls this show “the best place to hear about new music if you’re no longer 25.”
  • Bullseye: A pop culture show that’s also distributed by NPR.
  • Denzel Washington is Greatest Actor of All Time Period: I told you there was a long tail in podcasts.
  • Filmspotting: Film reviews and interviews.
  • The Goosedown: Two black comedians’ perspective on pop culture.
  • How Did This Get Made?: Comedians take down bad movies.
  • I Was There Too: Interviews with actors who played minor characters in well-known movies, like the woman with the baby carriage in The Untouchables.
  • Maltin On Movies: Longtime film critic Leonard Maltin and his co-host, comedian Baron Vaughn, talk about movies.
  • The Nerdist Podcast: Weekly interviews with entertainers and comedians.
  • OMFG: A show that explains what kids are up to these days.
  • Pop Rocket: A fun panel discusses what’s new and interesting in entertainment. Joan recommends Episode 2.
  • Song Exploder: Musicians take apart their songs and share the stories behind them.
  • Sound Opinions: A talk show hosted by two veteran Chicago music critics.
  • Tiny Desk Concerts: Intimate performances at the NPR offices.
  • U Talkin’ U2 to Me?: Adam Scott of Parks and Rec and Scott Aukerman of Comedy Bang! Bang! talk about U2.
  • We Hate Movies: James says this show is about “entertainingly terrible (but not terribly entertaining) movies torn apart by nerds.” Also, James has his own podcast about life in Berlin!
  • Wham Bam Pow: Movie reviews focused on sci-fi and action films.
  • Who Charted?: The latest in music and movies, featuring Los Angeles comedians.
Continued…

Lend me your ears: Introducing The Distance podcast

Wailin Wong
Wailin Wong wrote this on 3 comments

Since The Distance launched in May, we’ve taken you to a leather tannery, a tiki bar, an art warehouse and many other businesses, all of which have been operating for 25 years without taking outside investment. We’ve shared these companies’ stories through written words, photos and video—and now we’re adding audio.

Today we’re launching The Distance podcast. Starting with this month’s subject, the World’s Largest Laundromat, you can both read and listen to learn about these businesses. You’ll hear the hum of a factory floor and founders telling their stories in their own voices.

You can find The Distance podcast on SoundCloud and our website, with more listening and subscription options on the way. If you like our first episode, please help us spread the word. Thanks for listening!

Are we making it better?

David
David wrote this on 5 comments

A common approach to problem solving is to consider it binary. Either you’ve fixed the issue or you haven’t. Some problems fit that domain well: Either the calculator returns 2 on 1 + 1 or it doesn’t. There really isn’t much of a middle ground.

But many problems in product development aren’t like that. They’re far more hazy. Solving a problem in 100% of the cases for 100% of the people might very well not even be possible. So thinking of such problems as binary flips is not only futile, but harmful.

A better way to think of hazy problems, like “how easy is it to get started with Basecamp?” or “is the query interface for Active Record as readable as can be?”, is to focus on mere progress instead: Are we making it better?

That’s such a disarming question to pose of new initiatives. No longer does an idea have to contend with being The Solution, it simply has to contend with making things better.

It makes it so much easier to find consensus that way. Everyone sits with their own idea of The Solution, but most people can agree whether A is better than B, when both of those states are real.

Compare the concrete, make it better.

Asking why

Jonas Downey
Jonas Downey wrote this on 7 comments

Last week I asked a question on Twitter: If you have a personal website, why do you have it?

Some people used their site as a hub that collects their online identities. Others liked to fiddle with web tech or writing. Several treated it as a showcase for their professional work, to possibly get a job. Everyone else, it seems, didn’t have a reason aside from a general feeling of obligation.

I think that last group indicates a sea change. In the early days of the web, your site was a big part of your identity. It was one of the best places to share information, prove your geek mettle, and make a little network of fellow weirdos. In 2015, we have a million other ways to do that, so a personal site feels left over from a bygone era — a tiny island adrift in a vast ocean of apps, status updates, and clickbait headlines.

And so, its purpose has become even more vague. People don’t know what a personal site is for anymore, so they go through the motions. They put the same things everyone else puts on there. A giant photo of a city. Something that says “Hi, I’m Dave.” Fancy scrolling effects. A bunch of social media icons. An unintelligible skills chart. A quickly neglected blog.

All these choices are based on assumptions. First, the assumption that you even need a website. Second, that a website looks a certain way and has this usual kind of stuff on it. And third, that some anonymous group of users will stumble upon it and be interested in it.

As an industry, we have this problem a lot. We do things because that’s how everyone else does things. We assume that what’s popular must be good, so we don’t ask questions…we just do it! Even if we’re not that into it.

This is also why you see countless corporate websites that look exactly the same and automatically generated hipster logos. It’s much easier to assume an existing pattern works and reapply it than to dig in and find a deeper understanding of the real problem you’re trying to solve.

But shortcuts like this rarely lead anywhere new or interesting. Why replicate what hundreds or thousands of people already did? The best you can achieve is as good as everyone else. That makes you forgettable.

There’s a simple solution: ask why you’re doing something, and don’t bother getting started until you have a clear answer. This applies to any situation, but in this particular example…

Why should this website exist?

That question leads to more specific questions…

  • What am I trying to get out of this?
  • What’s unique about my story?
  • Do I have anything to say?
  • Why would someone look at this?
  • Why do I want them to look at it?
  • What do those visitors really need to know?
  • What should they do next?

When you work outwards from why, you unlock all sorts of revelations that aren’t about obligatory features or popular trends. You might find that those scrolling effects and skills charts have nothing to do with your story and the outcome you want. Maybe you’ll uncover a parade of new ideas dying to see the light of day. Or you’ll decide your site is just for your own experimentation, and that’s OK too.

If you find no strong reasons for a project to exist, all the better! Kick it to the curb and free yourself to spend time on something else.

Lead Android at Basecamp!

Nick
Nick wrote this on 2 comments
Happy Camper

We’re looking for a programmer to lead us on Android and push us further into the platform. This is a unique opportunity: we don’t hire often! We’ve got a serious foothold in the ecosystem, and we want you to take us to the next level.

Here’s a little preview of Basecamp for Android right now:

We’re happy to welcome applicants based anywhere around the world. Our office is based in Chicago, but our team is spread out over multiple countries and time zones. You can work from anywhere! We’re so serious about working remotely that we even wrote a book about it.

Basecamp offers benefits for the long run, including: 4 day work weeks during the summer, an exercise and CSA stipend, a 1 month sabbatical every 3 years, maternity and paternity leave, and health insurance that covers children, marriages, and domestic partnerships.

Who are we looking for?

We’re looking for someone who lives and breathes mobile, and especially on the Android platform. Fluency in Android’s patterns and APIs is a must. (Half-hearted iOS ports drive us crazy too!) We would love to talk to a developer who has experience shipping applications with a team, or independently on your own projects.

Here are some examples of day to day interactions with our mobile team. One day we might be diving through the Material design spec…

Material Design

...and the next day we’ll be tossing around ideas for an Android Wear prototype.

Android Wear

What will you work on?

You’ll work on our mobile team to support and improve Basecamp for Android, side by side with our other programmers, designers, and QA team that enable our customers to get their work done better on the run.

Here are some fun stats from our app’s usage in the wild. Android is our fastest growing mobile application right now:

Android Growth

Like many others with Android apps, we see a lot of older versions of Android, but we’re not afraid to welcome those users in while experimenting with the latest goodies from Google:

Android Distribution

You’ll join the our team of programmers who work on our Rails and iOS apps. Basecamp is the home of Ruby on Rails, and we’ll be happy to introduce you to our infrastructure. Part of being a programmer at Basecamp is our on-call rotation, where we help fix day-to-day issues for our customers using our products.

We also believe strongly in putting everyone on support, which usually happens around once a month. If you have some experience with Rails, that’s a bonus—but not a requirement.

Happy Camper Call

How can you apply?

We love cover letters. They’re a great way to introduce yourself, but don’t be afraid to surprise us in other creative ways too. We want to see what you’ve built and shipped, so any existing applications on the Google Play Store that we could try out would be great to include.

We’ve filled this position. Thanks for your interest!

Effort in the Application: sites that got our attention and got Basecampers their jobs

Mig Reyes
Mig Reyes wrote this on 2 comments

We’re really proud of the small-but-mighty team we’ve built here at Basecamp. Hiring is hard. Likewise, landing a great job is hard. In a sea of resumes, effort rises to the top.

Here are a few of the websites and commissioned challenges that helped these Basecampers score their job here. Note: our company was called 37signals before we became Basecamp in 2014.
Ryan Singer (Designer, Product Manager) was one of a few designer candidates that Jason picked in 2003 for a chance to join 37signals to work on client projects. The design challenge? Redesign the Verizon Wireless homepage. Ryan showed a great sense of clarity despite little to no direction, and he’s been at Basecamp ever since.

Jamie Dihiansan (Designer) met Jason early on in his career. 37signals wanted Jamie to apply for a new design position, but he wasn’t ready for it. Years later, timing finally worked out and Jamie applied for a new design position with a carefully crafted letter and a Backpack redesign.

Jason Zimdars (Designer) was quick to respond to this job posting. Turns out, JZ didn’t get the job, Jamie (above) did. Despite that, JZ still had great work and kept in touch. When 37signals had room for a new designer role, we asked him to apply and he came back with the new gold standard in applying to a job.

Ann Goliak (Support, QA) was a librarian when she first came across a Support position on our blog. Two hours later, she shot us an email and quickly forgot about it—she didn’t think she’d hear back. A month later, she heard back from us and whipped up a meaty page on why she’s a great fit.

Nick Quaranto (Programmer) wanted to move back home. Working remotely seemed like the best way to do that. Nick applied to 37signals out of the blue, thinking it was a longshot. But a descriptive site showcasing his passion convinced us otherwise.

John Williams (Ops) was tipped by his brother that there was an ops opening on the 37signals Job Board. John rose to the top with a personal site that gave him an extra edge over all of the other candidates.

Trevor Turk (Programmer) was working as a contractor during a short stint in London when he came across a programmer job posting on our blog. He worked up a straight-to-the-point page to toss his hat in the ring. Turns out, it was everything he needed to do to join the team.

Jonas Downey (Designer) reached out to Jason after he tweeted about a new design role within 37signals. Jonas interviewed, but ultimately didn’t get the job. A half-year later, another design role opened up. Jonas applied again, knocked his design challenge out of the park, and he’s been a happy Basecamper since.

Joan Stewart (Support) was a librarian, a Backpack user, and a regular Signal v. Noise reader. Knowing that Ann was a librarian, Joan thought “if she could work at 37signals, so could I.” She took the time to whip up her own page, and now Joan is a happy Basecamper, too.

Shaun Hildner (Video Producer) was quick to shoot an email to Jason after seeing him tweet that 37signals was looking for a video producer. His reel got him an interview, and his test got him the job.

Mig Reyes—that’s me!—(Designer) dropped an email to Jason looking for a written recommendation when he was applying for a totally different job in Chicago. Jason offered, “would you be up for working with us at 37signals instead?” A few meetings with the team in Chicago and a design test to boot, Mig became the next Basecamper.

Dan Kim (Programmer) was just about finished taking an advanced HTML and CSS class at The Starter League. He emailed Jason if there were any opportunities, but there weren’t at the time. When we started to work on Know Your Company, Jason reached out. Then after a couple of lunches and a test project, Dan became a Basecamper.

Jim Mackenzie (Support, Programmer) noticed he hadn’t seen recent Signal v. Noise posts after updating his RSS reader. Out of curiosity, he visited our blog in his browser and stumbled upon this job post and sent us a strong pitch and some work on why we should hire a stranger from the UK.

Conor Muirhead (Designer) had a coworker mention that Basecamp was hiring a product designer. Considering a job switch himself, Conor pulled the trigger on firing off this email to Jason. Conor’s effort put him into consideration for the job, and he followed it all the way through with his fully thought out design challenge.

James Glazebrook (Support) was tipped by Natalie, already one of Basecamp’s very own Support team members, that we were hiring someone to cover European hours. James had read REWORK before, so he knew we valued applicants going above and beyond. The result? 37 reasons why we should hire him.

Sylvia Chong (Support) planned on starting a food blog with a friend. Knowing they needed a good way to keep track of progress, her friend recommended using Basecamp together. Sylvia loved using Basecamp, so much so that she wondered if there were any jobs here. Luck and timing were in her favor, there was a perfect-sounding spot for her on our Support team. She finished her convincing site a week and a half later, and now we’re glad she’s on the team.

And of course, the original 37signals Manifesto that helped land us plenty of our former clients when we were a web consulting agency.

By the way, we’re hiring a programmer to lead Android and a designer to do brand and marketing. If you’d like to join the team, reach out to us!

Sometimes there really is an easy button

Noah
Noah wrote this on 4 comments

For a long time, I was frankly somewhat dogmatic about the tools I used to analyze data: Give me a SQL connection, R, and my trusty calculator and that’s all I need. If I need to make a report, I’ll just use Rails and HTML. Open source or bust.

For most of my four years here at Basecamp, that was mostly how I worked, and it was fine. I think I was reasonably productive (or at least productive enough to stay gainfully employed). I built a lot of tooling and reporting for the rest of the company, and I did some analyses that I’m proud of. These tools were all I needed, but it turns out they weren’t all that I wanted.

As we’ve grown as a company both in headcount and analytical appetite, I found that I was spending a lot of time working on reporting—dashboards, one-offs, random questions asked in Campfire, etc. This kind of thing is important and vital to a successful company, but it frankly isn’t that much fun to do. Fiddling with the position of charts in an HTML dashboard or typing long incantations to generate a simple histogram just aren’t how I want to spend my day, and I don’t think that’s the most value Basecamp can get from my time either.

So I went shopping, and I bought a license to Tableau. I used it to prepare for a big internal presentation, and then I got the server version to use for all future reporting on features, usage, our support team, even some of our application health and performance work. I’ve used Tableau at least a little every day since then — when talking about mobile OS fragmentation in Campfire, when reviewing the year our support team had, and as a replacement for parts of our Rails-based internal dashboard app.

There’s absolutely nothing that Tableau can do that I couldn’t do before, but that’s exactly the point: it lets me do the exact same stuff much faster, cutting down on the parts of my job that aren’t the most exciting and leaving more time for more valuable work. So far, the things I use Tableau for take less than half as long as doing them with my more familiar toolset, and I end up with the same results.

I still use R, SQL consoles, and my HP-12C every single day, and I commit to our Rails dashboard app almost every day. If you’d polled Basecamp six months ago and asked who was the most likely to be using Windows and endorsing the use of expensive enterprise software, I’m pretty sure I would have been the last person mentioned, but here I am.

Admitting that my dogma was wrong and spending a relatively small amount of money on a great tool means that I get to use those other tools that I know and love on more interesting problems, and ultimately to have more of an impact for Basecamp and our customers.

One of Basecamp's Water Coolers is a chatroom dedicated to pets

Kristin
Kristin wrote this on 8 comments

As you can see from Dan’s post, lots of us are animal lovers. Back when I lived in Chicago, a few of us would take turns hosting a workday that we would call “Bring Your Work to [Pet’s Name] Day.”

When Ann, Sam, and Trevor came to my apartment for “Bring Your Work to Clementine Horsetooth Day,” we worked from my couch and enjoyed the occasional interruption by Clementine, my elderly Siamese cat. She strutted around flirting with the newcomers: stretching and yawning and shaking her tail. At “Bring Your Work to Hector Day,” a bunch of us holed up in Sam’s loft with his sweet tabby and ordered a ton of Indian food. After work, a few of us got drinks at the Skylark before heading home to our own pets.

Online, we got to know everyone else’s pets from our Campfire room, All Pets. All Pets is a place to blow off steam, to take a break from work, and to connect with coworkers who may live on another continent.

And so, when Clementine died last November I knew my coworkers would be supportive, but I didn’t realize how much so. Not only did our office manager, Andrea, send flowers on behalf of the entire company, but I also received a whiplash of IMs from many people expressing their love and support. Ann (who doubles as World’s Best Catsitter for many Basecats) was especially supportive, in part because she had recently gone through the loss of her own Basecats. And then, a week after Clementine’s death, I received a condolence package from Berliner Natalie containing this amazingly succinct mug.

When I think of the average office dynamic, I don’t think of this kind of camaraderie. Maybe it’s because our figurative water cooler is a silent, opt-in chat room filled with adorable animals that we’re able to connect more earnestly than if we were at a literal cooler. Maybe it’s because we’re all abnormally obsessed with animals, but All Pets isn’t our only Water Cooler. There’s All Parents, All Nerds, All Comics & Movies, among others. Nonetheless, there’s nothing at Basecamp, not even an ocean or two, that keeps us isolated from one another.

In Memory of all the pets we lost at Basecamp.