Reiterating our Use Restrictions Policy

The attack on the US Capitol, and subsequent threats of violence surrounding the inauguration of the new US administration, has moved us to reflect and reacquaint ourselves with the reality that however good the maker’s intentions, technology can amplify the ability to cause great harm.

This includes us and our products at Basecamp. Therefore, we feel an ethical obligation to counter such harm. Both in terms of dealing with instances where Basecamp is used (and abused) to further such harm, and to state unequivocally that Basecamp is not a safe haven for people who wish to commit such harm.

Our full Use Restriction Policy outlines several forms of use that are not permitted, including, but not limited to:

  • Violence, or threats thereof: If an activity qualifies as violent crime in the United States or where you live, you may not use Basecamp products to plan, perpetrate, incite, or threaten that activity.
  • Doxing: If you are using Basecamp products to share other peoples’ private personal information for the purposes of harassment, we don’t want anything to do with you.
  • Child exploitation, sexualization, or abuse: We don’t tolerate any activities that create, disseminate, or otherwise cause child abuse.
  • Malware or spyware: Code for good, not evil. If you are using our products to make or distribute anything that qualifies as malware or spyware — including remote user surveillance — begone.
  • Phishing or otherwise attempting fraud: It is not okay to lie about who you are or who you affiliate with to steal from, extort, or otherwise harm others.

Any reports of violations of these highlighted restrictions, or any of the other restrictions present in our terms, will result in an investigation. This investigation will have:

  • Human oversight: Our internal abuse oversight committee includes our executives, David and Jason, and representatives from multiple departments across the company. On rare occasions for particularly sensitive situations, or if legally required, we may also seek counsel from external experts.
  • Balanced responsibilities: We have an obligation to protect the privacy and safety of both our customers, and the people reporting issues to us. We do our best to balance those responsibilities throughout the process.
  • Focus on evidence: We base our decisions on the evidence available to us: what we see and hear account users say and do. We document what we observe, and ask whether that evidence points to a restricted use.

While some violations are flatly obvious, others are subjective, nuanced, and difficult to adjudicate. We give each case adequate time and attention, commensurate with the violation, criticality, and severity of the charge.

If you’re aware of any Basecamp product (Basecamp, HEY, Backpack, Highrise, Ta-da List, Campfire) being used for something that would violate our Use Restrictions Policy, please let us know by emailing report@basecamp.com and we will investigate. If you’re not 100% sure, report it anyway.

Someone on our team will respond within one business day to let you know we’ve begun our investigation. We will also let you know the outcome of our investigation (unless you ask us not to, or we’re not allowed to under law).

While our use restrictions are comprehensive, they can’t be exhaustive — it’s possible an offense could defy categorization, present for the first time, or illuminate a moral quandary we hadn’t yet considered. That said, we hope the overarching spirit is clear: Basecamp is not to be harnessed for harm, whether mental, physical, personal or civic. Different points of view — philosophical, religious, and political — are welcome, but ideologies like white nationalism, or hate-fueled movements anchored by oppression, violence, abuse, extermination, or domination of one group over another, will not be accepted here.

If you, or the activity in your account, is ultimately found in violation of these restrictions, your account may be closed. A permanent ban from our services may also result. Further, as a small, privately owned independent business that puts our values and conscience ahead of growth at all costs, we reserve the right to deny service to anyone we ultimately feel uncomfortable doing business with.

Thank you.

For further reference, our full list of terms are available here: https://basecamp.com/about/policies

HTML over the wire

You can write fast, modern, responsive web applications by generating your HTML on the server, and delivering that (with a little help) directly to the browser. You don’t need JSON as an in-between format. You don’t need client-side MVC frameworks. You don’t need complicated bundling and transpiling pipelines. But you do need to think different.

Because the mainstream story in web development of the past decade or so has been one of JavaScript all the things! Let’s use it on the server! Let’s use it on the client! Let’s have it generate all the HTML dynamically! And, really, it’s pretty amazing that you really can do all that. JavaScript has come an incredibly long way since the dark ages of Internet Explorer’s stagnant monopoly.

But just because you can, doesn’t mean you should.

Keep reading “HTML over the wire”

Validation is a mirage

Spend enough time talking with entrepreneurs, product people, designers, and anyone charged with proving something, and you’ll bump into questions about validation.

“How do you validate if it’s going to work?”
“How do you know if people will buy it to not?”
“How do you validate product market fit?”
“How do you validate if a feature is worth building?”
“How do you validate a design?”

You can’t.
You can’t.
You can’t.
You can’t.
You can’t.

I mean you can, but not in spirit of the questions being asked.

What people are asking about is certainty ahead of time. But time doesn’t start when you start working on something, or when you have a piece of the whole ready. It starts when the whole thing hits the market.

How do you know if what you’re doing is right while you’re doing it? You can’t be. You can only have a hunch, a feeling, a belief. And if the only way to tell if you’ve completely missed the mark is to ask other people and wait for them to tell you, then you’re likely too far lost from the start. If you make products, you better have a sense of where you’re heading without having to ask for directions.

There’s really only one real way to get as close to certain as possible. That’s to build the actual thing and make it actually available for anyone to try, use, and buy. Real usage on real things on real days during the course of real work is the only way to validate anything. And even then, it’s barely validation since there are so many other variables at play. Timing, marketing, pricing, messaging, etc.

Truth is, you don’t know, you won’t know, you’ll never know until you know and reflect back on something real. And the best way to find out, is to believe in it, make it, and put it out there. You do your best, you promote it the best you can, you prepare yourself the best way you know how. And then you literally cross your fingers. I’m not kidding.

You can’t validate something that doesn’t exist. You can’t validate an idea. You can’t validate someone’s guess. You can’t validate an abstraction. You can’t validate a sketch, or a wireframe, or an MVP that isn’t the actual product.

When I hear MVP, I don’t think Minimum Viable Product. I think Minimum Viable Pie. The food kind.

A slice of pie is all you need to evaluate the whole pie. It’s homogenous. But that’s not how products work. Products are a collection of interwoven parts, one dependent on another, one leading to another, one integrating with another. You can’t take a slice a product, ask people how they like it, and deduce they’ll like the rest of the product once you’ve completed it. All you learn is that they like or don’t like the slice you gave them.

If you want to see if something works, make it. The whole thing. The simplest version of the whole thing – that’s what version 1.0 is supposed to be. But make that, put it out there, and learn. If you want answers, you have to ask the question, and the question is: Market, what do you think of this completed version 1.0 of our product?

Don’t mistake an impression of a piece of your product as a proxy for the whole truth. When you give someone a slice of something that isn’t homogenous, you’re asking them to guess. You can’t base certainty on that.

That said, there’s one common way to uncertainty: That’s to ask one more person their opinion. It’s easy to think the more opinions you have, the more certain you’ll be, but in practice it’s quite the opposite. If you ever want to be less sure of yourself, less confident in the outcome, just ask someone else what they think. It works every time.

The Making of a Dumpster Fire

A few weeks ago we launched a new marketing project for HEY.com at dumpsterfire.email. If you haven’t seen it yet, it’s a flaming dumpster with a printer and conveyor. You email dumpsterfire@hey.com, it prints out your email, and drops it into the rolling flames on a livestream. Simple, right?

What follows is far more than you ever want to learn about building an internet-connected dumpster fire.

Keep reading “The Making of a Dumpster Fire”

How to waste half a day by not reading RFC 1034

HEY uses a branch deploy system that I’ve written about here on SvN and talked about frequently on Twitter. Plenty of other companies have implemented their own version of branch deploys (typically under a different name), but this was my own implementation, so I’m proud of it. First, a primer on how it works:

  • Developer makes a code change in a git branch and pushes it to GitHub.
  • An automated build pipeline run is kicked off by a GitHub webhook. It builds some Docker images and kicks off another build that handles the deploy itself.
  • That deploy build, well, it deploys — to AWS EKS, Amazon’s managed Kubernetes offering, via a Helm chart that contains all of the YAML specifications for deployments, services, ingresses, etc.
  • alb-ingress-controller (now aws-load-balancer-controller) creates an ALB for the branch.
  • external-dns creates a DNS record pointing to the new ALB.
  • Dev can access their branch from their browser using a special branch-specific URL

    This process takes 5-10 minutes for a brand new branch from push to being accessible (typically).

Keep reading “How to waste half a day by not reading RFC 1034”

Basecamp has offset our cumulative emissions through 2019

Earlier this year, we announced that Basecamp was committing to getting to carbon negative for our cumulative history and moving forward. Today, I want to share an update on that commitment.

Note: I edited this post on Nov 5, 2020 to include the prices paid for all carbon offsets and explain a little more about the 7,000 tCO₂e cumulative carbon footprint following a question from a reader. Thanks!

Keep reading “Basecamp has offset our cumulative emissions through 2019”

Introducing the Basecamp security bug bounty

We’ve run a private security bug bounty program since 2014. Invited testers reported numerous security vulnerabilities to us, many of them critical. We investigated and fixed the vulnerabilities they reported and thanked them with cash rewards. Before 2014, and concurrently with the private bounty program, we ran a public “Hall of Fame” program where we accepted vulnerability reports via email and thanked reporters with credit on our website.

Since the day we launched it, we’ve aimed to take the security bug bounty program public—to allow anyone, not just a few invited hackers, to report vulnerabilities to us for a cash reward. We want to find and fix as many vulnerabilities in our products as possible, to protect our customers and the data they entrust to us. We also want to learn from and support the broader security community.

We’re happy to announce that we’re doing that today. The Basecamp security bug bounty program is now open to the public on HackerOne. Our security team is ready to take vulnerability reports for Basecamp 3 and HEY. Bounties range from $100 to $10,000. We pay more for more severe vulnerabilities, more creative exploits, and more insightful reports.

Here are some of the high-criticality reports we’ve fielded via the security bug bounty:

  • Jouko Pynnönen reported a stored cross-site scripting (XSS) vulnerability in HEY that lead to account takeover via email. We awarded $5,000 for this report.
  • Hazim Aslam reported HTTP desynchronization vulnerabilities in our on-premises applications that allowed an attacker to intercept customer requests. We awarded  $11,437 in total for these reports.
  • hudmi reported that the AppCache web API (since deprecated and removed from web browsers) could be used to capture direct upload requests in Basecamp 3. We awarded $1,000.
  • gammarex reported an ImageMagick misconfiguration that allowed remote code execution on Basecamp 3’s servers. We awarded $5,000.

Check out the full program policy on HackerOne. For information on what to expect when you report a vulnerability, see our security response policy. If you have any questions, don’t hesitate to reach out to security@basecamp.com.

Don’t take their word for it

A few weeks ago, we needed some hardware fast. After some back and forth with the vendor, they promised “expedited delivery”. That sounded like a good thing, but it meant nothing.

To us, expedited delivery meant overnight delivery. That’s what we had in our head. Our experiences elsewhere equated expedited as overnight, but expedited isn’t overnight – it just means faster, prioritized, enhanced, sooner. But it doesn’t mean overnight. Expedited is relative, not absolute. If standard shipping takes 7 days, expedited could mean 5.

Of course, as you’ve probably guessed, the stuff we thought would come overnight didn’t come overnight. A harsh call the next day to the vendor ultimately got us the hardware overnight the next day, but we lost a day in the exchange.

What we had in front of us was an illusion of agreement. We thought a word meant one thing, the other side thought it meant something else, and neither of us assumed mismatched alignment on the definition. Of course we agreed on what expedited meant, because it was so obvious to each of us. Obviously wrong.

This happens all the time in product development. Someone explains something, you think it means one thing, the other person thinks it means something else, but the disagreement isn’t caught – or even suspected – so all goes as planned. Until it goes wrong and both sides look at each other unable to understand how the other side didn’t get it. “But I thought you…” “Oh? I thought you…” “No I meant this…” “Oh, I thought you meant that…”. That’s an illusion of agreement. We covered the topic in the “There’s Nothing Functional about a Functional Spec” essay in Getting Real.

We knew better, but we didn’t do better.

Next time you’re discussing something with someone — inside or outside your organization — and you find the outcome contingent upon a relative term or phrase, be sure to clarify it.

If they say expedited, you say “we need it tomorrow morning, October 3. Will we have it tomorrow, October 3?”. That forces them into a clear answer too. “Yes, you’ll have it tomorrow, October 3” or “No, we can’t do that” or whatever, but at least you’re funneling towards clarity. If they say “Yes, we’ll expedite it” you repeat “Will we have it tomorrow, October 3?” Set them up to give you a definitive, unambiguous answer.

And remember, while we now know that “expedited” is relative, “overnight” can be too depending on where someone’s shipping something from, what time zone they’re in, their own internal cutoffs for overnight shipping, etc. Get concrete, get it in writing, and get complete clarity. Slam the door shut on interpretation. Get definitive.

Basecamp is hiring a Product Designer

Basecamp’s Core Product team is hiring a Senior Designer! We’ll be accepting applications for the next two weeks, with a flexible start date in December.

It’s been over 4 years since we hired for this role, so this is an exciting and rare opportunity to join our team. You’ll start by working on HEY, our brand new email service. In 2021 we’ll also launch a major new update for Basecamp, so there’s lots of impactful design work ahead where you can make your mark.

About the Job

At most companies, product design is split into many different roles: UX, UI, front-end development, and so on. At Basecamp, it’s all one role. We believe the best designs come from someone who can see it all through, from ideas to visuals to the finished product.

That means all of our designers are generalists—excellent visual stylists, front-end developers, project managers, writers, and more. Our projects are design-led, so you’ll have a lot of influence and impact right away.

As a Core Product designer, you’ll be working on the web interfaces for Basecamp and HEY. You might be improving an existing feature, designing something totally brand new, or rethinking how we do something.

Along with having great visual taste and sensibilities, you must be able to write your own HTML, CSS (BEM), and some JavaScript. You’ll work directly inside our Ruby on Rails apps to make your designs come to life. (But note: we don’t expect you to do all the implementation on your own. You’ll be paired with a programmer on most projects, and you’ll consult with the rest of the Core team and our iOS/Android teams.)

As a manager of one, you’ll drive shaped projects, big and small, over six-week cycles. You’ll set direction, take ownership, make calls, and see things through without a lot of oversight. You’ll be able to communicate clearly with your colleagues, work across teams, and lend a helping hand when needed.

You love to write, too. You understand that copywriting is design. The words matter as much as the pixels. Great visuals with weak words are poor designs. You should care about how things are phrased as much as you care about how they look.

Here are some things we’ve worked on recently to give you a sense of what you’ll be doing day-to-day.

  • Built an interface for our email exporting tech, so people can easily export their HEY email into a downloadable MBOX file.
  • Improved color contrast on buttons in dark mode, after hearing bug reports from customers and our QA team.
  • Created novel multi-step onboarding and training flows to help new customers learn how HEY works.
  • Researched the technical requirements for hosting a custom domain name, and then implemented a step-based workflow to help people migrate their company’s email system over to HEY.
  • Extracted reusable CSS components after noticing repeating patterns in our codebase.
  • Prototyped many different variations on HEY’s Screener UI, to make it as clear and simple as possible.

Basecamp is a fully remote company, and this is a remote job. We’re hiring from anywhere with at least 4 hours of overlap with the US-Central Time zone during a normal work day. This could be a 11:00-19:00 schedule from Europe, but we’re not hiring from locations that require a graveyard shift to make the overlap happen.

About Us

Basecamp has been proudly building opinionated, respectful software for nearly 20 years. As an intentionally small, privately-held company, we don’t answer to anyone but ourselves and our customers. We design our products to solve real-life problems, and we strongly defend our customers’ attention and privacy along the way.

We use the concepts we defined in Getting Real and Shape Up to stay focused, keep projects on track, and ship good work on time.

Benefits & Compensation

Basecamp pays in the top 10% of the industry based on San Francisco rates. Same position, same pay, no matter where you live. The salary for this position is $149,442 (Senior Designer).

Benefits at Basecamp are all about helping you lead a healthy life outside of work. We believe quality time to focus on work starts with quality time to think, exercise, prepare a meal, be with family & friends, and of course, time to yourself.

We offer fully paid parental leave. We work 4-day weeks in the summer (Northern Hemisphere), and offer a month-long sabbatical every 3 years. We subsidize your home office, wellness and fitness interests, and continuing education. We also offer an annual charitable contribution match. All on top of top-tier health insurance and a retirement plan with company match. See our full list.

Applicants from outside of the US will be offered a contractor role on comparable terms and equal pay with our domestic employees.

How to Apply

Please submit an application that speaks directly to this position. Tell us about yourself, about what you can bring to Basecamp, and about Basecamp’s role in your future. Tell us about what you’ve done and what excites you. You might be inclined to design something especially for us—that’s fine. Just make sure the content of your application is as impressive as its presentation. We’ll also happily accept a traditional, well-constructed cover letter full of personal touches and that shows us how much you want this job.

We’re accepting applications until Friday, October 16, 2020, at 5PM US-Central time. There’s no benefit to filing early, so take your time.

We strongly encourage candidates of all different backgrounds and identities to apply. We believe that our design work is stronger with a variety of perspectives, and we’re eager to further diversify our company. If you have a background that you feel would make an impact on Basecamp, please consider applying. We’re committed to building an inclusive, supportive place for you to do the best work of your career.

What happens next?

We expect to take a few weeks to review all applications. You’ll hear from us by November 6th, about advancement to the interview stage. Expect 2-3 interviews, all one hour, all remote, with your future colleagues, on your schedule. We’ll talk through your background, your approach to design, and dive into your professional knowledge. No gotchas or surprises.

After the interviews, the final candidates will be given an at-home design challenge. The exercise is representative of the kind of work we do, and it helps us understand how you’d approach new problems from scratch. We invite no more than 5 candidates to this stage, and those candidates should expect to spend about 3 work days completing the project. You’ll be compensated for your time.

We aim to make an offer in November with a flexible start date in December.

Please note that we’re unable to offer individual feedback during the screening process. We usually see 1,000+ applications for open positions, and our hiring team simply doesn’t have the bandwidth to offer personalized feedback before the first interview round.

This is a demanding application process and significant, long-term career move to consider. We appreciate you giving us that consideration, and we promise to give you our full attention in return. We look forward to hearing from you!

APPLY HERE

We write code, not documents

Recently a student asked me:

Could you describe one instance where you had to use a diagramming tool (eg. Google Slides Drawings, Lucidcharts, Miro, Whimsical, Gliffy etc) to accomplish a task?

They also provided an example answer I could follow, which consisted of creating a chart to map a user flow, presenting it, getting feedback, adding it to another larger document, and creating Jira tickets.

I was a little surprised (though simultaneously not surprised) — is this how software development is still being taught?

Without being critical of academia, this seemed like a good opportunity to try to shatter by-the-book software development ideas for some future engineers by sharing a different way — our way.

Here was my answer (slightly edited for clarity and typos):

I hope this answer is helpful, but I actually don’t use a lot of diagramming tools, and I think it’s safe to say they’re not commonly used at Basecamp. We don’t write specs and stuff like that as they’re not “real” enough. We will do high level sketches and rough drawings (usually pen and paper or an iPad and a sketching app), but that’s typically it. So more often I’ll grab a pen and paper and sketch out a rough flow of what I need to do, or write out pseudo code of the steps that I need to take. 

Keep reading “We write code, not documents”