I went on vacation and a funny thing happened — I didn’t do any work

Many vacations are broken, filled with the stress of work. Help me bring back the work-free vacation.

My family and I just returned from a 12 day vacation to the San Diego area, where my brother, mom, and dad all live.

We had a wonderful time. We did all the typical vacation stuff — Legoland, beaches, pizza, beer, excessive ice cream eating — and my kids got to spend a bunch of time with their grandparents and uncle. 😍

What made this vacation truly wonderful wasn’t just the fun activities and family, but that I got to enjoy every second of it without a single bit of stress from work.

Work was the furthest thing from my mind. I was focused solely on relaxing, recharging, and spending time with my family.

The sad state of today’s “vacations”

You might be thinking — what’s so special about that? After all, vacation is a time when people unplug from work, relieve stress, and let go of all their worries, right?

Sadly — no, not really.

Search Google for “people working on vacation” and a disturbing amount of negative results come up — a worrying trend of unused vacation days, people who constantly work on vacation, and even life hacks on how to do work while on vacation. ☹️

The American “vacation” in today’s work environment is in pretty bad shape. How bad?

U.S. respondents receive less paid vacation time than any of the countries surveyed — 18 days in the U.S., compared to the average of 24.

— TripAdvisor

They found that among employees with access to paid time off, nearly five days went unused in 2013, and 1.6 of those days did not carry over to the next year. That totals to 169 million days of lost vacation time for Americans


Fears of keeping your job, being passed over for promotions or lead projects, coming back to a staggering pile of work, or feeling like you’re the only one who can do your job all push Americans to stay at the office…


This trend was strongest among millennials: 35 percent said they worked each day while on vacation, and 21 percent said they returned to work less productive.


Not that this is always voluntary. … 24% say they were contacted by a colleague on a work issue, 20% by a boss. And while 20% gave up part of their time off because they were in pursuit of a promotion, nearly the same number (17%) stayed connected because they feared for their jobs.


So, to recap:

  • We get fewer days off than many other countries
  • Even though we get fewer days off, we still don’t use them all
  • When we do use them, we’re so worried about the remote possibility of getting fired or missing out on a promotion, that we just keep on working anyway
  • And even if we get past all that, the jerks at our office contact us about work while we’re on vacation

Wow, American vacations sound fucking horrible!

Take control of your vacation

While these statistics are damning, we’re all adults here. Much of this is under your control, so it’s up to you to take action.

First and foremost, use your vacation days — all of them. Sounds obvious, but this should not be difficult. I don’t care how much your love your job. Find a way to use them. You’ve earned them and they’re part of your overall compensation, and you’re flushing money down the toilet if you don’t.

And when you do take those hard-earned vacation days, you need to turn on your internal work can wait mode for the entirety of your vacation by…

  • Recognizing that dedicated time away from work is actually what makes you more productive. Working on vacation (including compulsively checking your email and other work apps) might feel productive, but you’re only sapping your long-term strength.
  • Letting go of the idea that you have to know everything that’s going on. If you’re at a moderately sized company, there’s always going to be a lot going on — far more than you can keep a pulse on. Relieve yourself of the idea that missing out is a bad thing and not only will your vacation be more pleasant, you’ll be more focused when you return to work.
  • Being realistic about your status. Think about it — your huge promotion isn’t going to magically disappear while you’re on vacation. I guarantee if you’re in the running for a promotion before your vacation, you’ll still be in the running when you return. And if it’s not, you’re working for a ridiculously bad company.
  • Stop thinking that you’re a special snowflake — that you’re the only one who can do a certain job, and that the company will come crashing down without you. It’s just not true, and once you realize this, you’ll feel liberated and everything will be just fine while you’re gone.
  • Planning. Don’t leave your coworkers and your company in the lurch. A tiny bit of setup not only makes everyone around you comfortable, you’ll be able to mentally check out knowing you’ve done your due diligence.

Sadly, there’s one thing that is kind out of your control. And of all the stats I read through, this one bothers me the most:

24% say they were contacted by a colleague on a work issue, 20% by a boss. — Money

Holy shit! Who are these sadists that contact coworkers when they know full well they’re on vacation?!

Look, I’m sure there are very rare cases where someone’s life is literally on the line and you need to be contacted. And if you’re the brainiac who left a bunch of half finished work right before a deadline, you deserve to be bothered during vacation.

But more likely this is a sign of blatant disrespect by the person making the call. So let’s just be crystal clear: if your coworker is on vacation, leave them alone. Deal with it. 😎

Building companies that respect vacations

Beyond what each individual can do to make their vacations work-free, it’s important for business owners and CEOs to encourage that behavior and weave it into the company’s culture.

Why should work-free vacations be a priority for businesses? Speaking from experience, when I come back from a work-free vacation, I’m…

  • Refreshed and mentally sharp. Vacations have a way of clearing big piles of junk out of my brain. When I come back to work, I just feel sharper and think more clearly. Everything that seemed like a hard problem before vacation looks way easier when I return. (Good sleep has a similar effect, though on a much smaller scale).
  • Motivated and excited. I’m absolutely raring to go when I come back to work. Not programming or building for a couple weeks really ignites a fire in me and I apply that to my work. And I really look forward to catching up with my friends and colleagues.
  • Appreciative and grateful. When my time away from work is respected, it makes me appreciate the company that I work for. I’m grateful for all my coworkers that covered my work while I was gone. That appreciation ultimately turns into me putting my best effort into all of my work.
  • Happy. Sounds obvious and maybe a little corny, but of course I’m happy coming off a vacation. I’ve built memories with my family and enjoyed something new and special away from work. Happiness means good vibes in my work!

As a business owner, imagine multiplying those feelings across all your employees throughout the year. I bet you’ll have one hell of a productive workforce. 📈

We can’t fix the entire vacation epidemic across the country, but we can try to fix what’s within our sphere of influence. Both as individuals and as companies, let’s do our part by insisting our vacations be work-free.

We spend literally thousands of hours at work each year — let’s make those few hundred hours away from work really count! 🤘

When we’re not on work-free vacations, we’re working really hard to make Basecamp 3 as great as it can be. Check it out!

If this was helpful to you, please do hit the heart button below or let me know on Twitter. Thanks for reading!

Myth debunking: WebViews suck, everything should be native

Contrary to popular belief, Android webviews aren’t your enemy — they’re your best friend

If there’s one thing that gets a lot of shit on Android, it’s webviews (OK, not as much as fragments, but it’s up there).

How do I know? The next time you talk to an Android programmer or designer, try this little experiment: tell them you use a lot of webviews. Then wait for the confounded looks on their face and the subtle “ouch, sorry” nodding of the head.😲

The reason people feel that way is because we’ve been conditioned to think the “right way” to build apps is by making everything a native screen. Surely no serious, self-respecting native app developer would use a bunch of webviews!

To the contrary! Webviews are wonderful and offer us incredible scale, flexibility, freedom, and happiness.

200 screens, 2 programmers, 1 designer, 40 hour weeks, 3 vacations, 1 sabbatical

Being a small company is something we hold dear at Basecamp — it’s a core value of the company.

But Basecamp 3 is not a small app — its feature set is both broad and deep. It has well over 200 unique screens, and new ones are added every week.

And yet with so many features and screens, Basecamp 3 for Android was still built by only two programmers and one designer.

In earnest, the Android app started development in March 2015 (when we assembled our full team), and it launched at the beginning of November 2015. That’s roughly 0 to 100% in 8 months.

The key to shipping was that we leaned on the webviews where we needed to.

While the Android team was building native functionality and views for high-touch screens (things like push notifications, navigation, the home screen), a whole bunch of other webview screens were built by our web team. They had our back, building high-fidelity, mobile-friendly webviews that our app could use.

For the sake of argument, let’s do some back of the napkin math to see how important webviews were to Basecamp 3 for Android. If we assume each screen takes an average of 3 days to build/test natively (which is a highly aggressive estimate, but let’s go with it), the math would work out to:

200 screens x 3 days per screen = 600 days
600 days / 2 programmers = 300 days per programmer
300 days / 20 work days per month = 15 months

15 months! That would have been a mere 7 months overdue. Or if you wanted to be a real sadist, we could assume 30 days a month of work, and that would get us to 10 months! 😭

And let’s not forget, this also assumes 1) no new screens are added 2) no screens are ever changed 3) we are 100% efficient every single day and 4) we don’t take a single day off. Yeah right!

The math simply didn’t add up. To make the math work, we had to rely on webviews.

The result: we worked 40 hour weeks during the cold months, and 32 hours weeks in the summer months. We took our vacations and sabbaticals. We lived our personal lives. And on launch day, we had full coverage of Basecamp 3, on-time, in-scope, and without burning anyone out.

If your app is moderately large, and keeping your team small and sane is something your team values, you need webviews.

Programmer happiness and native level-ups

One argument the all-native camp makes is that native screens are simply better all around. But better for who?

Sure, you could argue that a native screen provides the best interaction experience for customers. And whatever is best for a customer, it’s certainly worth doing, right?

But it’s not really that cut and dry.

What’s best for the customer sometimes means doing what’s best for your team. And what’s best for your team is when you’re happy — when you’re excited to work on something and given autonomy over your work. That’s when you produce your best work for a customer.

Webviews give us the flexibility and freedom to choose what screens to level up as native views, instead of being forced to make everything native.

This allowed us to focus on screens we knew would get used a lot (like our home screen) and really fine-tune those. Not only was that good for our customers, it was good for us. Those screens are a ton of fun to build.

Now imagine the opposite scenario — having to re-make native screens for every admin, settings, or text-heavy instructional screen that’s already been made on the web. As a motivated designer or programmer, how quickly would you get bored with that kind of copypasta work? Those aren’t the kinds of things that get intrinsically motivated teams out of bed in the morning.

The freedom to choose our native level ups was a true godsend, and was only possible because we had full webview coverage for everything else.

You don’t need 100% native fidelity on every screen

I can hear the haters — “Sure, you can use webviews for everything, but everyone can tell they’re webviews and not native”.

So what?

Does every single screen need to have 60 fps animations, with activities that launch from the exact x/y coordinate where my finger touches the screen? Does that kind of fidelity matter on an admin screen? Does it matter to people who are just trying to get their work done if a screen follows the Material Design spec exactly?

Look, I’m all for great design and attention to detail. We take it seriously and I respect it immensely.

But everything is a tradeoff. And under the right circumstances, am I willing to trade a little native fidelity when we can get 90% of the way there with a webview? Absolutely.

Webviews with Turbolinks 5 enabled are plenty fast

Critics of webviews may point to their page loading performance as a reason not to use them.

But with the introduction of Turbolinks 5, the performance of webviews is pretty much a non-issue.

It doesn’t give you carte blanche to make ridiculously heavy webviews, but it sure will carry you pretty far even if you do.

To take advantage of our Turbolinks enabled webviews in Basecamp 3, we built and open-sourced Turbolinks Android, a library that makes working with Turbolinks trivial. Just add one dependency, then tell the library to load your page:

protected void onCreate(Bundle savedInstanceState) {

That’s basically it. Turbolinks Android takes care of the rest — providing you with everything you need for ultra-fast page loads from a single, low-memory webview instance.

Scaling our apps with independent, complementary teams

Webviews give us immediate and amazing scale across platforms. Instead of using the efforts of just two Android programmers, we can harness the power of all thirteen of our programmers together.

Every team working on a feature has the capability to not only build new stuff, but to deploy them to all of our customers quickly with minimal coordination across teams and zero red tape.

Once a team has tested a new feature on the Android app, they deploy it without any intervention from us. Every customer immediately benefits from the new feature on the web and in the app.

This is a wonderfully independent, yet complementary way to work. No team is ever stymied in deploying new stuff to customers, and every platform, including our Android app, automatically improves.

So there you have it — we’ve reaped a bunch of amazing benefits from webviews, a component that gets more scorn than love in the Android world.

But remember, one size does not fit all. The techniques and styles that work for some teams might not fit your team well.

Continue to challenge conventional viewpoints that don’t feel right to you (including this post)! The most important thing is to find what fits your team’s values and build around those. 🤘

We’re working really hard to make the all-new Basecamp 3 and its companion Android app as great as they can be (using webviews, of course) 😉. Check ’em out!

If this was helpful to you, please do hit the heart button below or let me know on Twitter. Thanks for reading!

Hiring a programmer? Ditch the coding interview and get back to basics

10 articles from the Basecamp archives focused on common sense hiring practices

This week was going great…until I saw yet another article coaching programmers on how to prepare for a coding interview. Imagine, the secrets to “winning” a coding interview and getting your dream job, all unlocked in one article! 🤔

I suppose I shouldn’t really blame people for writing articles and books claiming to teach you how to beat coding interviews. They’re just trying to help other people and maybe make a quick buck. They aren’t really the source of the problem.

The real problem is that this entire cottage industry is built on the false pretense that coding interviews have any value whatsoever.

So before we go any further, let’s establish one very simple truth: coding interviews are worthless.

The Practical Developer nails it. (Original Tweet)

I won’t bother going into detail as to why coding interviews are so worthless. Many have already hit the nail on the head — the reasons are varied, numerous, and already well-documented.

It is interesting, though, that nobody really seems to know when, where, or who started them. My guess is because no single person or organization wants to be blamed for so much industry wide suffering. (If you do happen to know the origin story, I’d love to read it).

Regardless of how it all got started, a growing number of tech companies seem to use coding interviews regularly (as evidenced by all those amazing how-to articles and book). And therein lies the danger.

If more and more companies start to believe in coding interviews, the trend will gain frightening momentum. Pretty soon nobody will ask why they’re even doing them. People will start to assume that if a lot of companies are interviewing like this, then they must be valuable, right?

No! We need to kill this virus before it spreads too far. There are much better ways to find a good programmer.

Over the years Basecamp has published a handful of articles about hiring. It’s something we rarely do (the company is 17 years old and has just 49 employees), so we’re very considerate with each hire.

Instead of following a silly interviewing trend that’s flawed to its core, we just follow some common sense practices.

Below are 10 articles we’ve written from the past decade or so with tried and true ideas to help you find a great programmer.

Every one of them holds up today, and we still rely on these ideas ourselves. And no, not a single one involves you watching someone sweat through a pointless whiteboard exercise. 😓

As a business focused on the long-term, these ideas have paid off in spades for us. I hope you’ll consider these ideas, and join me in giving a big 🖕 to the coding interview trend!

Stop whining and start hiring remote workers

There’s so much untapped tech talent that does not live near your office, but would work for you if you allowed them to.

The person they’ll become

I love betting on people with potential. When they finally get that chance to do their best work, they blossom in such a special way.

Why we don’t hire programmers based on puzzles, API quizzes, math riddles, or other parlor tricks

The only reliable gauge I’ve found for future programmer success is looking at real code they’ve written, talking through bigger picture issues, and, if all that is swell, trying them out for size.

Kick the tires

Before we hire anyone we give them a small project to chew on first. We see how they handle the project, how they communicate, how they work, etc. Working with someone as they design or code a few screens will give you a ton of insight.

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

Hiring is hard. Likewise, landing a great job is hard. In a sea of resumes, effort rises to the top.

“We hire only the best”

The best are generally the best because they aren’t typical. Because they came at things from a different angle that gave them a unique perspective, which happens to provide more insights than the widely-distributed approaches


If you are trying to decide between a few people to fill a position, always hire the better writer. It doesn’t matter if that person is a designer, programmer, marketer, salesperson, or whatever, the writing skills will pay off.

Hire managers of one

A manager of one is someone who comes up with their own goals and executes them. They don’t need heavy direction. They don’t need daily check-ins. They do what a manager would do — set the tone, assign items, determine what needs to get done, etc. — but they do it by themselves and for themselves.

How to hire a programmer when you’re not a programmer

Find out how they manage their work. Software often slips — find out how they avoid this. Find out when they shipped something on time and ask why that project was successful.

Actions, not words

Programing is all about decisions. Lots and lots of them. Decisions are guided by your cultural vantage point, values, and ideals. Look at the specific decisions made by a candidate in coding, testing, and community arguments to see whether you’ve got a cultural match.

Hiring is so important to us because we care a lot about our customers, our product, and our company.

If this was helpful to you, please hit the heart button below or let me know on Twitter!

Some of my favorite Kotlin features (that we use a lot in Basecamp)

Team Android at Basecamp recently passed a fairly big milestone — over 25% of the Basecamp 3 Android app code base now runs on Kotlin! 🎉

Github statistics for the Basecamp 3 Android app as of 5/27/16.

We’ve found that Kotlin not only makes our code much better, but massively increases programmer happiness. All of this ensures we’re making the best app we can for the tens of thousands of Android users we support.

Given our new experiences with the language, I thought it’d be worth sharing some specifics that make the language so wonderful to work with.

Unlike most articles that introduce you to a language, I’m going to avoid using too much programming lingo. Instead, I’ll try using plain English in the hopes that it’s more accessible to beginners. 🤗

Some notes about the code examples:

  • I am by no stretch an expert in Kotlin. Read, consider, and discuss!
  • They look better on a desktop browser. You can get by on the mobile app in landscape mode, but I’d recommend breaking out your laptop to read them.
  • They’re brief and simple on purpose. Long-winded examples tend to cause confusion. Take these simple examples and extrapolate them into your own potential uses, and you’ll see a lot more power.

Let’s get started with seven of my current favorites!

1. Replacing simple if/else if/else blocks with when

One of my absolute favorites.

// Java
if (firstName.equals("Dan")) {
} else if (lastName.equals("Dihiansan")) {
} else {
// Kotlin
when {
firstName == "Dan" -> person.team = programmers
lastName == "Dihiansan" -> person.team = designers
else -> person.team = others

when blocks are effectively the same as a simple if block, but look how much more readable that is!

There’s a similar convention when only one argument is being checked. Typically this would be a long, ugly switch/case statement in Java.

// Java
switch (firstName) {
case "Dan": person.setTeam(programmers)
case "Jay": person.setTeam(programmers)
case "Jamie": person.setTeam(designers)
// Kotlin
when (firstName) {
"Dan", "Jay" -> person.team = programmers
"Jamie" -> person.team = designers
else -> person.team = others

I swear, this alone is worth writing Kotlin.

2. Beautifying even the ugliest click handlers

Using Anko, a library built for Kotlin, click listeners are ridiculously easy.

I hate writing these in Java so much that I could barely bring myself to write an example here. But I soldiered on. 😭

// Java
view.setOnClickListener(new View.OnClickListener() {
public void onClick(View v) {
System.out.println("This is horrible");
// Kotlin
view.onClick {

3. No more view binding

By using the Kotlin Android Extensions, you no longer need to bind views to objects to start working with them. You can access them directly without any binding. Zero. None.

// Java
EditText composer = findViewById(R.id.composer);
// Kotlin 
view.composer.text = "Allo!"

That might not look like a big deal in isolation, but think about how much of your Activity/Controller code is the ceremony of binding a view to an object before you can start to work with that object. Kotlin bypasses all of that.

4. Functions in one line

One line functions can technically be written in Java, but you’d be going against generally accepted styles.

Kotlin’s inherent brevity makes one-liners (officially called single-expression functions) quite common, and they look great. No extra lines and no braces required.

// Java
public String fullName() {
return getFirstName() + " " + getLastName();
// Kotlin
fun fullName() = "${firstName} ${lastName}"

Bonus: the return object type is implied, so Kotlin will automatically know the method is returning a String without ever having to write “String” anywhere.

You may have also noticed in this example 1) no need for public and 2) string interpolation.

5. Convenience methods built on top of familiar objects

Kotlin has extended objects you’re familiar with and made them even better and packaged them into the Kotlin Standard Library.

Take String comparisons for example:

// Java
if (name.toLowerCase().contains(firstName.toLowerCase())) {
// Kotlin
if (name.contains(firstName, true)) { ... }

Not a huge difference, but enough to improve readability in many places. The standard library has tons of these kinds of tweaks. Perfect!

6. Reducing the need for`if (whatever != null)`

Null checking is so painfully common in Java that `if (whatever != null)` is probably in your recurring nightmares.

Kotlin has a number of impressive null safety features built in, and let is just one of those ways to achieve more readable code.

// Java
if (message != null) {
// Kotlin
message?.let { println(it) }

Here if message is not null, Kotlin will let the block (what’s inside the braces) run. If it’s null, it just skips it.

There’s one other bit of awesomeness — notice the println(it) statement? The it keyword allows you to reference the object the let began from.

7. The Elvis operator

I mostly love this operator because of its name. It looks like this:

?: // Turn your head to the left, you may see someone familiar

Fun name aside, the real reason this is great is because it handles the common scenario of “if something is null, I want to give it a value, but otherwise just leave it alone”.

// Java
if (people == null) {
people = new ArrayList();
return people;
// Kotlin
return people ?: emptyArrayList()

Here if people isn’t null, it returns. If it is, it returns whatever is to the right of the Elvis operator.

So that’s just a brief look at some things that make my life better every day working with Kotlin.

If you’re interested in getting started with Kotlin, their documentation is very good, and you can poke around the interactive Kotlin Koans. I tend to struggle with things like koans (feels too much like school work!), so if you’re like me, I’d encourage you to try building something real.

We’re working really hard to make the all-new Basecamp 3 and its companion Android app as great as they can be. Check ’em out!

If this was helpful to you, please do hit the heart button below or let me know on Twitter and we’ll keep adding to this Kotlin series.

“Eat, sleep, code, repeat” is such bullshit

Despite the hype, programming is not an all or nothing endeavor

I’m on my way back home from Google I/O 2016. It was a fantastic conference — I met some great people and learned a lot.

But while I was there, I saw something horrifying, something I couldn’t shake from the moment I saw it…

Eat. Sleep. Code. Repeat. Bullshit!

“Eat. Sleep. Code. Repeat.” was printed on everything. I’d seen the phrase before, but this time it burned into my brain, probably because it was being so actively marketed at a large conference. I literally let out an “ugh” when I saw it.

What’s the big deal? It’s just a shirt.

Look, I get it — Google I/O is a developer conference, and the “eat, sleep, code, repeat” phrase is intended to be a clever way (albeit a completely unoriginal one) of saying “coding is awesome and we want to do it all the time!” I appreciate the enthusiasm, I do.

But there’s a damaging subtext, and that’s what bothers me. The phrase promotes an unhealthy perspective that programming is an all or nothing endeavor — that to excel at it, you have to go all in. It must be all consuming and the focus of your life.

Such bullshit. In fact it’s the exact opposite.

At Basecamp I work with some of the best programmers in the world. It’s no coincidence that they all have numerous interests and talents far outside of their programming capabilities.

Whether it’s racing cars, loving art, reading, hiking, spending time in nature, playing with their dog, running, gardening, or just hanging out with their family, these top-notch programmers love life outside of code.

That’s because they know that a truly balanced lifestyle — one that gives your brain and your soul some space to breathe non-programming air — actually makes you a better programmer.

Life outside of code helps nurture important qualities: inspiration, creative thinking, patience, flexibility, empathy, and many more. All of these skills make you a better programmer, and you can’t fully realize them by just coding.

Don’t believe the hype

It’s no secret that the tech industry loves hyperbole. How will you ever reach the coveted title of ninja, rock star, or wizard if you don’t spend all your waking, non-eating hours programming?!

I’ll give my standard advice: ignore the hype.

It’s wonderful to be so dedicated to your craft that programming is all you ever want to do. I love that enthusiasm. It can carry you to great heights.

But if you want to become the very best programmer you can be, make space for some non-programming activities. Let your brain stretch its legs and you might find a whole new level of flow. 🤘

When I’m not programming, I love being a dad. I also enjoy donuts and pizza.

And when I’m not thinking about kids, donuts, or pizza, I do my best programming for Basecamp 3 and its companion Android app.

If you liked this post, please do hit the heart button below or let me know on Twitter!

How I fell in love with a programming language

After a month with Kotlin, I finally understand what the hell DHH has been saying about Ruby all these years!

Basecamp 💖 Kotlin! (Illustration by Nate Otto)

If you know only one thing about DHH, it’s that he adores the Ruby programming language. He doesn’t just like it. He genuinely loves it. There’s zero debate about this.

I’ve always highly respected his viewpoint. But I can’t say I’ve necessarily been able to fully relate to it.

Don’t get me wrong. His rationale and explanations make perfect sense. I don’t write a lot of Ruby, but I understand why people like it a lot. It’s very pretty, expressive, and clear. It has a ton of great features. Those are the facts.

But when David talks about Ruby, he doesn’t hammer on facts. Rather, he exudes emotion. Emotion is what really cuts deep and inspires people.

Sure, he also mentions some language features, but it’s far more interesting when he excitedly talks about Ruby’s beauty, how it makes him genuinely happy, and how its transformed his life. His deep passion and enthusiasm trumps any facts or features. You can tell Ruby is, to him, something special and profound. He loves it.

And it’s usually at this point when I ask myself, “What the hell is DHH talking about?”😕

The reason I could never fully relate to David’s visceral, emotionally charged stance on Ruby is because <gulp> I’ve been a Java guy for 15+ years.

I know it’s not a particularly cool thing to say, but for all its warts, Java has served me well. And as Android’s native language, it’s been a true blessing in disguise. Who knew all those years of writing shitty webapps would turn into such an awesome mobile opportunity?

But I’ve never had strong feelings about Java itself. I liked some things about it, and I hated others. Whatever…it did the job. It was fine.

For many years my perspective was simple — I didn’t have to love Java (or whatever programming language) to do my work well.

Me and my Java.

That all changed a few months ago.

At the suggestion of my Android partner in crime, Jay, we started to look more seriously at Kotlin. It had been in the back of our minds for a while, but when it hit 1.0, we took a more serious look.

Jay jumped in first with some experiments and I played around, but I didn’t think too much more about it. I continued with my 100% Fine Artisanal Java™ features.

Then about a month ago I wrote my first Kotlin class.

It was a popup adapter in just 86 lines (17 of which were package and import statements), and I couldn’t get over how concise and readable it was. I could barely comprehend how little I wrote to get something to work.

It took me a few passes, but all of a sudden, I sensed the difference. This wasn’t just about language features or what the FAQ said the language was capable of.

This was about how I felt.

It was genuinely fun. I found myself smiling. I found myself saying “holy shit” more than a few times. I’d read code over and over and couldn’t believe how much I was accomplishing in so few lines. I couldn’t believe the clarity of the writing.

Over the next few days, I wrote more and more Kotlin. I wrote my first extension. Then I converted an existing helper class and instantly cut 94 lines. I wanted to write more!

With just a few hours of effort, I cut 94 lines without breaking a sweat.

I was amazed, excited, and having a ton of fun. I was also slightly freaked out by this weird new experience brought on by a programming language.

Then it finally dawned on me. Oh my God, this is it. This is what loving a programming language is like.

Over the next couple of weeks, that warm fuzzy feeling just grew and grew.

Whenever I’d have to work with Java, it was painful. I’d find myself rushing through it and making stupid mistakes because I had more important Kotlin files to attend to.

But when I opened the Kotlin files, I felt at home, relaxed. The code was beautiful and expressive. It was concise but powerful. I kept finding new ways to write more clearly, more directly. And I was happy!

In short, I was feeling what David had felt about Ruby for all those years. I finally understood what the hell he was talking about!

And so that’s where we’re at in the love story. It’s still really early, and who knows if this is just infatuation or true love. For all I know it’ll all come crumbling down.

But no matter how it turns out, I learned this very valuable lesson (and it only took me 15+ years)…

Nobody can truly decipher a programming language‘s greatness for you. No amount of explanation will help you feel a great language at your fingertips. They may try, but it won’t fully click. You have to experience it for yourself.

If you’re programming now, but don’t love the language you’re writing, I’d encourage you to try one that has a reputation for positive vibes: Ruby, Kotlin, Swift, or Coffeescript. And don’t just read the docs and do tutorials — pick one and try building something real.

Just remember…

Good luck. I hope you find love on your journey.

We’ve been working really hard to make the all-new Basecamp 3 and its Android app as great as they can be. Check ’em out, we hope you love them. 😀

If you have any feedback, I’d love to hear it! Email me or hit me up on Twitter and let’s chat.

Admire someone? Write them an email, you might be surprised

How a simple email to Mike Monteiro led to a handshake and a hello.

A couple years ago I attended a conference in Austin. There were a lot of great speakers, but the one I really wanted to see was Mike Monteiro. I’ve admired Mike’s work from afar for many years because it’s so honest and direct.

I watched Mike’s entire talk, What Clients Don’t Know (and Why It’s Your Fault), and enjoyed it thoroughly. It was so great, I wanted to say thanks — it’s the least I could do for something I liked so much. I looked through the crowd for a while, but was never able to find him.

But I still wanted to say thanks, so I took a shot and sent him an email, fully assuming he wouldn’t read it. I kept it brief — I introduced myself, let him know that I’ve admired his work for many years, and thanked him for a great talk.

My email to Mike wasn’t anything special. Brief, friendly, and with a dash of personality. That’s it!

Later that morning as we hung around the lobby, Mike walked up to me and said hello. We shook hands, and he mentioned he got my email and said thanks for that. The whole interaction was maybe 30 seconds, and I probably made a fool of myself.

But my foolishness aside, I got to meet someone who I admired. All it took was the simple act of saying thank you in an email.

This isn’t a unique story, either. Before I started working at Basecamp, I would occasionally email Jason — just to say hello and to thank him and the team for Basecamp. Eventually those individual emails turned into conversations. And those conversations ultimately turned into my dream job.

Our friend and current CEO of Highrise, Nate Kontny, has written about a similar story. He’s cold-emailed hundreds of people over the years. And while most have been ignored, some have started some really important conversations (like the one that led him to become the CEO of Highrise).

So if you admire someone, want to say thank you, or just want to strike up a conversation, don’t be afraid to send a nice email.

All the headlines keep declaring that email is dead, but it absolutely isn’t. Let your ideas, genuine gratitude, and personality shine in an email. You might be surprised what it leads to.

Ever since I emailed Jason and landed my dream job, I’ve had tons of fun working on a lot of great projects, including the all new Basecamp 3 and its companion Android app. Check ’em out!

And hey, if there’s anything I can ever help you with, email me or hit me up on Twitter and let’s chat.

Why I don’t worry about our app’s negative reviews

Illustration by Nate Otto.

Our happiest customers are most likely our quietest customers

Like any app developer, the Android team at Basecamp cares about our app’s reviews. We look at them regularly because they can be a valuable source of feedback and a way for us to talk to our customers.

And like any app developer, we see our fair share of negative reviews. As a small team who takes feedback seriously, it’s a bummer when someone doesn’t like our app.

A negative review of Basecamp 3 for Android. 😭

Of course not all negative reviews are thoughtfully written, and much has already been made of how broken ratings and reviews are. Still, it’s hard not to take some of it to heart and let it weigh you down.

But over time, I’ve learned one really important thing…

No matter how many negatives reviews we get, there are a lot of people who really like our app — they just don’t write many reviews. It’s important to remember those happy, quiet customers and not get too hung up on negative reviews.

Leaving reviews just isn’t a priority for many people

Here’s the thing — as much as you want them to, there’s really no strong incentive for someone to leave you a positive review.

For many people, your app is doing its job dutifully and everything is working great. It’s not changing their lives or revolutionizing their world, but it’s helping them get something done. They’re thankful it exists.

But for them writing a review is never going to be a priority. Even if they love your app and are raving to their friends and co-workers about it, giving you written, positive feedback is never going to compete against the hundred other things they’ve got going on in their lives.

You may have even experienced this yourself — do you have any apps installed that you like but have never left a positive review for? I certainly do.

Sure, there are ways to boost your ratings and reviews, and you should take whatever opportunities you can to help your app. But no matter what you do, there will always be a subset of users who are very quiet, but very happy.

Listen to your negative reviews, but keep your quiet, happy customers in mind too

While negative reviews aren’t always useful (particularly one-star reviews with the word “useless” written in it), some can be genuinely helpful.

What’s most important is that you listen to the reviews that have constructive criticism and feedback.

Great feedback from a customer, and an A+ response by our designer, Jamie Dihiansan. He listens, responds thoughtfully, and leaves the door open for a conversation.

Respond if you can, and encourage them to email you directly with more details. Feedback and direct interactions with customers are valuable and show that you’re listening. Consider their ideas, prioritize, and start making your app better for those customers.

But at the same time it’s very, very important to know that there are a lot of people using your app that are perfectly happy with it.

You’ve already done a great job to get to where you are. Don’t lose sight of that.

Be sure to give everything five minutes so that the squeaky wheels don’t cloud your judgement. Continue to trust yourself and your team to make sound decisions based on considerate thought, not knee jerk reactions. And really think about all your customers, not just the vocal ones.

Sometimes our happiest customers do write reviews. 😀

Believe me, the positive reviews and happy customers are out there. You just can’t hear them all.🤘

We’ve been working really hard to make the all-new Basecamp 3 and its companion Android app as great as they can be. Check ’em out!

If you have any feedback, I’d love to hear it! Email me or hit me up on Twitter and let’s chat.

I’m a boring programmer (and proud of it)

Archetypes for programmers (if you believe all those silly job postings). Illustration by Nate Otto.

I have a confession to make — I’m not a rock star programmer. Nor am I a hacker. I don’t know ninjutsu. Nobody has ever called me a wizard.

Still, I take pride in the fact that I’m a good, solid programmer. One who works hard at his craft and really enjoys it, even without the fancy labels.

Keep reading “I’m a boring programmer (and proud of it)”

Writing software is easy

If you think building a software product is tough, try building a legendary car from scratch.

Photo courtesy of White Horse Pictures

I recently watched A Faster Horse, a documentary about the development of the 2015 Ford Mustang. It examines how that Mustang, whose nameplate is an icon in Ford’s history (and America’s), went from idea to final shipping product — a five year process.

The amount of work it takes to produce a new car is absolutely dizzying. Take the following list for example, which is just a small sampling of the thousands of high-level items the Ford team is tasked with:

  • Initial idea and design sketches
  • CAD models and full size clay models
  • Engine and transmission development
  • Interior development
  • Software development
  • Supply chain development, management, and parts procurement
  • Cost analysis and pricing structures across hundreds of markets
  • Crash testing and safety/government regulations across multiple continents
  • Dozens of development mules for hundreds of test drives for ride, engineering, and performance tuning
  • Global marketing
  • Global legal
  • Final assembly of hundreds of permutations of the vehicle
  • Global logistics and final shipping to dealers

And if all that weren’t enough, once the car ships, it’s out of your hands. Recalls occasionally happen, but even those are typically for tweaks and safety, not reshaping the car itself.

Compare that to what we do in modern software development:

  • Initial idea, design sketches and quick prototypes
  • Write some code, probably with free tools
  • Find a server for hosting
  • Do some testing
  • Pick a price and build a little marketing around it
  • Ship your product with a few clicks
  • Iterate and ship it again

When I sat back and thought about how vastly different these industries are, a few things jumped out at me:

  • The work that companies like Ford do to bring a car to market is truly impressive. The coordination and teamwork is unbelievable, and it’s a real credit to the power of people.
  • I love working on Basecamp, a product whose fundamental goal is to bring people together to work on getting things done, solving problems, and doing great work — exactly the kinds of things that Ford does to bring the Mustang to market.
  • The challenges I face in my day to day work as a programmer aren’t really so bad. 😎

It’s that last point that really stuck in my head.

We (myself included) can sometimes get bogged down by the challenges in building software. If you’ve ever had a frustrating day of programming, team battles, or a tough interaction with a customer, you know the heavy feeling I’m talking about.

But compared to building a car from scratch, we’ve got it so good — writing software is easy!

Embrace imperfection and ship it 🚢

Of course I don’t mean to trivialize our work or make reductive statements about our day to day problems. We all have tons of responsibilities on our shoulders to make great products that our customers love. On a daily basis we work on problems we don’t fully understand, critical bugs, and important features, all within a set of team dynamics and personalities.

But as hard as it is to tackle those issues, our struggles are relatively tame. If you take a look at the world around you, I bet you can find products that were insanely hard to ship, arguably much harder than software.

I personally think about the engineers at Boeing who are building massive jumbo jets every day. I’m in awe of construction crews who regularly build 50 story high-rises in Chicago. I’m fascinated by the amount of work that went into building my Nexus 6P so precisely.

A car or airplane has to be near perfect when it ships. A building must have every detail planned and triple checked. A phone must be engineered to the millimeter.

But modern software doesn’t have to be any of those things. We have a huge advantage — we can ship imperfection.

Software development brings us incredible freedom — freedom to build and ship things in days, not months; freedom to iterate and tune until our heart’s content; freedom to plan a little, but not excessively; freedom to be imperfect.

I am all for being detail oriented, but perfection is unobtainable in software. I’ll look closely at every detail of a feature and consider all the angles. Often there are imperfections, but if it’s a close call and the feature is good enough, I’ll always vote for shipping instead of holding it back.

This is not to say you should take shipping lightly. You should always consider the impact to your customers and understand any risks you might be taking by shipping an imperfect feature. And I’m not saying you should go rogue and ship things that fall outside the acceptable standards of your team or company.

But it’s also healthy for you and your brain to ship regularly— to put something out there, feel a sense of accomplishment, and let your customers react to it. You can hem and haw all day, but ultimately your customers will be the true judge of your work, not you or the people on your team.

And hey, if it doesn’t work out, just be glad you weren’t building a car. If something goes really haywire, you don’t have to institute a global recall. Refocus on the problem, reconsider it, fix your app, and ship it again. 🤘

We’re hard at work making the all-new Basecamp 3 and its companion Android app great. Check ’em out!

If there’s anything I can help you with, don’t hesitate to hit me up on Twitter!