Kotlin: It’s the little things

Kotlin has a bunch of amazing features, and certain ones tend to grab the headlines — things like extension functions, higher order functions, and null safety among them. And rightfully so — those are all incredibly powerful, fundamental features of the language upon which everything else builds on.


And while I love those features, there are a handful of small things you don’t hear much about that I really appreciate on a day-to-day basis.

These are simple, small niceties — the little things you do hundreds of times a day but nothing you’d consider “advanced”. They’re common sense language features that, when compared to Java, end up saving you a bunch of cognitive overhead, keystrokes, and time.

Take this simple, albeit highly contrived, example:

// Java
1 | View view = getLayoutInflater().inflate(layoutResource, group);
2 | view.setVisibility(View.GONE)
3 | System.out.println(“View " + view + " has visibility " + view.getVisibility() + ".");

// Kotlin
1 | val view = layoutInflater.inflate(layoutResource, group)
2 | view.visibility = View.GONE
3 | println(“View $view has visibility ${view.visibility}.")

At first glance the Kotlin version may look similar, as the differences are subtle. But there’s some great stuff to unpack that’ll make your life much better in the long run.

Given that example, let’s take a look at five things from Java that you’ll never need to do in Kotlin.

(Note: For clarity in the code snippets, Java is always shown first and Kotlin second. Contextual code is truncated and the diffs are bolded.)

1. Declare variable types

View view
vs.
val view

Instead of explicitly declaring a variable type (in this case a View) Kotlin simply infers it from whatever is assigned to it. You just write val or var, assign it, and get on with your day. One less thing to think about.

2. Concatenate Strings into an unreadable mess

“View " + view + " has visibility " + view.getVisibility() + "."
vs.
“View $view has visibility ${view.visibility}."

Kotlin provides String interpolation. It’s such a stupid simple feature to have that makes working with Strings much easier and more readable. It’s particularly useful for logging.

3. Call getters/setters

getLayoutInflater().inflate();
view.setVisibility(View.GONE);
view.getVisibility();
vs.
layoutInflater.inflate()
view.visibility = View.GONE
view.visibility

Kotlin provides accessors for existing Java getters and setters so that they can be used just like properties. The resulting conciseness (fewer parenthesis and get / set prefixes) improves readability considerably.

(Occasionally the Kotlin compiler can’t reconcile the getters/setters for a class and this won’t work, but that’s relatively rare.)

4. Call painfully long boilerplate methods

System.out.println();
vs.
println()

Kotlin provides you with concise convenience methods that wrap many painfully long Java calls. println is the most basic (though admittedly not the most practical) example, but Kotlin’s standard library has a boatload of useful tools that cut down on Java’s inherent verbosity.

5. Write semicolons

;
;
vs.

Need I say more?

🏅Honorable mention: Not shown, but you never have to write the new keyword ever again either!


Look, I know these aren’t mind-blowing features. But these little things, in aggregate over many months and tens of thousands of lines of code, can make a big difference in your work. It really is one of those things you have to experience to appreciate.

Put all these little things together with Kotlin’s headline features and you’re in for a real treat. 🍩


If this article was helpful to you, please do hit the 💚 button below. Thanks!

We’re hard at work making the Basecamp 3 Android app better every day (in Kotlin, of course). Please check it out!

Kotlin makes me a happier (better) programmer

What’s Kotlin’s best feature? Creating programmer happiness.


There’s been a lot of action around Kotlin lately. So one question you’ll often hear is “What’s your favorite Kotlin feature?”

And while there are many wonderful things about the language, for me it isn’t about any single technical feature.

My answer? It makes me happy.

Writing code that’s concise, clear, and expressive makes me happy. Focusing on creative solutions to business problems, not boilerplate and ceremony, makes me happy. Feeling an intense motivation to learn, which was missing in the Java days, makes me happy.

And that’s super important. Because being happy isn’t just good for the soul. It’s great for your programming skills too.

As DHH astutely pointed out many years ago in Getting Real:

Would you truly be happy working in this environment eight hours a day? This is especially important for choosing a programming language.

Happiness has a cascading effect. Happy programmers do the right thing. They write simple, readable code. They take clean, expressive, readable, elegant approaches. They have fun.

Imagine extrapolating that feeling over an extended period of time.

The more capable and friendly your language is, the happier you are. The happier you are, the better code choices you make. The better code choices you make, the better habits you build. And the better habits you build, the better programmer you become!

This is exactly what’s happened with Kotlin and me over the past year. And I’m a better programmer because of it.

DHH continues:

We found programming bliss in the language Ruby and passed it on to other developers with our framework Rails. Both share a mission statement to optimize for humans and their happiness.

In summary, your team needs to work with tools they love. Choose the fuse that gets people excited. You’ll generate excitement and motivation and a better product as a result.

This is absolutely true for Kotlin— it fits my brain and optimizes for my happiness. Working with it is just flat out fun, exciting, and motivating. It makes the quality of my work better and it makes me better.

I’ve never been a happier (or better) programmer. 😍


If this article was helpful to you, please do hit the 💚 button below. Thanks!

And if you’ve caught the Kotlin bug, you might like our other posts:

How we made Basecamp 3’s Android app 100% Kotlin

Our best advice based on a year of real-world shipping.

Made with ❤️ in Chicago.

We started our Kotlin journey a year ago based on two hunches: that it would 1) make a huge difference in programmer happiness and 2) wildly improve our work quality and speed.

I’m happy to report that our hunches were right! As of this week, Basecamp 3’s Android app is written in 100% Kotlin. 🎉

That puts us in a unique position to share tips from the experience of going from all Java to all Kotlin. How do you get started? What should you look out for? What are the best ways to keep learning Kotlin?

Read on!

🤓 Wrap your head around the basics

First thing’s first — take some time to get acclimated with the the language. There are free resources galore, but here are a few I’d recommend:

  • Jake Wharton’s talk about Kotlin for Android. This was the lightbulb moment for me. After two watches, I really started to get it.
  • Some of my favorite Kotlin features. I wrote this a few months after we started with Kotlin. I specifically wrote it to be basic and straightforward so it’d be easy for beginners (which I was at the time!)
  • The Kotlin docs. When people tell me to read the docs, I often wince. But the Kotlin docs are legit, and are an excellent way to get acclimated.

🐢 Start slow but make it real

Writing your first bit of Kotlin is usually the hardest part of getting started.

To alleviate the pressure, people will often suggest you start with tests or perhaps a Gradle plugin. And while that’s extremely sound advice, it doesn’t work for me. It’s too boring and obscure to get excited about.

I propose something different — write real production code.

This is important because 1) it’s something you can see working in your app right away and 2) it’s more fun! That feeling of accomplishment and seeing something work shouldn’t be discounted — it builds your confidence and keeps you motivated.

Of course I don’t recommend converting a giant class all at once on your first go. Instead try converting a utility or helper method. Take a single method from one of your util classes and rewrite it in Kotlin.

Done! You now have your first bit of production ready Kotlin.

😵 Don’t try to learn the whole language at once

Kotlin has a lot of great stuff in it — so much that you might be tempted to use it all right away.

And while that can work, I wouldn’t recommend it. Instead find a few key concepts that click in your brain (not what others tell you are the best parts of the language), and practice using those to their fullest.

When I got started, three areas clicked for me: flow control (when/if/for), extension functions (add functionality to any class you want), and null safety (in particular the use of let). Focusing on just those few concepts helped me get started without feeling overwhelmed.

Don’t be afraid to start small. You need space in your brain not only to pick up new things, but to let them stick. You’re already going to be dealing with basic syntactical differences — if you try to cram all the goodness all at once, something is bound to get overwritten in your brain.

🔀 Learn from the auto converter

JetBrains has done a solid job with their Kotlin plugin and its ability to auto convert Java to Kotlin. It can get your class 60–70% of the way there, leaving you with some tuning and idiomatic/stylistic things to take care of.

There are two great ways to learn from this:

  1. Auto convert the class, but keep the Java class handy. Put them side by side, and see how the Kotlin compares. You’ll pick up a ton by just seeing how the auto converter chose to implement the Java in Kotlin.
  2. Auto convert the class, but don’t leave it in that state — while the 60% version will run, that last 40% is what makes the difference between OK code and great code. Attack everything for clarity and conciseness and look for ways to follow Kotlin idioms that the auto converter couldn’t figure out.

🤔 Question all your Java habits

As you begin writing Kotlin, the sad reality is that you’ll probably have some bad Java habits you’ll need to break.

I found myself writing terrible if/else blocks in cases where a when would be so much better. I was writing null checks around objects when a simple object?.let{} would’ve been better. And much more.

You may also have built up some strong ¯\_(ツ)_/¯ attitudes toward ugly code blocks. Because Java is so verbose, over time you may have begun to accept an occasional ugly code block as “well, that’s Java”.

Writing in Kotlin will help you see through those, but you will need to let go of the idea that ugly code is OK. Sure there will be times when ugly code may be situationally necessary, but you won’t be able to blame Java’s ceremony any more.

So regularly question whether you are doing something the “Kotlin way”. When you see code that feels long or complicated, pause and take another look at it. Over time you’ll develop new, better habits that will overwrite your Java ones.

🏕️💨 Leave the campsite cleaner than you found it (no new Java ever)

A good way to keep your code heading in the right direction is to tidy up small bits of Java as you pass by. As the saying goes, leave the campsite cleaner than you found it.

A lot of times when building something new, you’ll incidentally need to make a small change to an existing Java class — add an attribute, change a type, etc. These are often small classes like a model or utility class.

Convert them! Don’t be lazy and leave them be. This incremental, slow approach over time will save you and your team much frustration in the long run.

❄️ Use cool downs for Kotlin

A great time to work on Kotlin conversions is when you’re cooling down off a big release.

Often we’ll do our normal two week cycle, release a big feature, and then take a few days to watch for stability and customer issues.

Those couple days aren’t going to be enough time to get into something big, so it’s a great time to convert some classes to Kotlin. Over time you’ll get faster at this and be able to knock out a few classes per day.

👴🏻 Curb your enthusiasm

When you start to feel comfortable with Kotlin, you might get a little…excited. That’s a good thing! That energy and enthusiasm keeps you motivated and learning.

But it’s also easy to go overboard. I certainly did.

I‘d collapse whatever I could into single-expression functions to save lines, only to realize I was giving up clarity. I’d use too many when blocks, even in cases where a simple if/else would’ve been sufficient and clearer. I’d write extension functions galore, then realize I was creating more cognitive overhead than I was saving.

It’s wonderful to be enthusiastic and use all the tools that Kotlin gives you. But try to keep your cool (unlike me) and make sure you’re using language features for the right reasons.

💸 Don’t forget about your customers

While seeing more and more Kotlin makes your life much better, you need to keep one very important (obvious?) thing in mind: your customers don’t care.

I fully support the argument that programmer happiness leads to great code and ultimately a better product. It’s crucially important.

But as with all good things, you need to find the right balance. Converting all your Java to Kotlin might be a fun goal for you, but meanwhile your customers might be struggling with a nagging bug.

The great thing is that those two things aren’t mutually exclusive. Grab those bugs and squash them with Kotlin — it’s a win-win! (If we’re being honest, Java probably caused the bug in the first place anyway).

👯 Don’t go it alone

Depending on your company makeup, this might be easier said than done. But if you can, find a Kotlin buddy!

There is no question that I’m more proficient at Kotlin because of my buddy Jay. We regularly share ideas, review each other’s Kotlin, and poke fun at Jamie, our designer.

Sometimes that stuff happens in informal chats, but the by far the most valuable place to learn is in pull requests. You can let your code speak for itself, and the feedback can do the same. When it comes to learning Kotlin (or any new language really), this is absolutely crucial.


Alright, you made it! I know that’s quite a bit to chew on — maybe some obvious, maybe some not. But I hope it helps get you on the right path to joining us in Kotlinland!

If this article was helpful to you, please do hit the 💚 button below. Thanks!

We’re hard at work making the Basecamp 3 Android app better every day (in Kotlin, of course). Please check it out!

Can’t crack that programming problem? Go to sleep (or take a walk)

Think back to the last time you had that really tough programming problem you couldn’t crack.

If you’re like me, you may have spent a few hours trying to brute force a solution. Then, in despair and frustration, eventually you gave up for the night.

And then the next morning, you wake up and the solution is clear as day in your head. You face palm yourself, rush to your computer, implement it in 15 minutes, and all is well in the world again.

Or this — I work a problem all morning to no avail. Lunch time hits, so I take my dog for a 30 minute walk. And somewhere along that walk I’ve figured out the solution. I get back home and fly through it the rest of the afternoon.

George has the right idea, but this doesn’t count as real sleep. 😆

Look, I realize I’m not saying anything particularly new or profound here. But it absolutely bears repeating because I often forget this too:

Sleeping and walking are some of the best techniques to improve your work as a programmer.

(Pro tip: don’t take your phone to bed or on your walks. Your brain needs to be fully disconnected.)

I’m no scientist or expert on how the brain works, but there is plenty of science to back it. The basic premise is that free association and fixation forgetting (letting go of what you’re banging your head on) is crucial to problem solving. Your brain can put together solutions more effectively when it’s allowed to wander.

This is exactly why “Eat, sleep, code, repeat” is such bullshit. Your brain needs to do something else from time to time (and be rested) to do your best programming.

So the next time something isn’t clicking, leave it. Forget about it. Take a walk and go grab a donut. Get 8 hours of sleep. Your brain will do the heavy lifting and tell you when it’s ready to solve that problem.


If this article was helpful to you, please do hit the 💚 button below. Thank you!

We’re hard at work making the of Basecamp 3 better every day (by getting a good night’s sleep every night). Check it out!

Get to the point

It’s the single best way to improve your day-to-day writing.


If you want to consistently improve your everyday writing, there’s one really straightforward thing you can do…

Get to the point.

When you get to the point quickly, your writing becomes instantly clearer. Clarity makes your writing easier to understand, easier to retain, and more enjoyable to read. All of that makes your readers happy.

Here are a few pointers in how do do that.

Avoid the long windup

The long windup is the most common (and most painful) mistake I see when reading.

Common offenders are things like a grand introduction about yourself, a discussion of why your post is important, a massive outline, or a long setup story that buries a one-line reveal.

You don’t need any of that, and your readers don’t want it either.

When readers run into a long windup they either 1) skim to find the main point or 2) just leave. Either way they’re irritated and are probably going to miss the valuable parts of your writing.

So let’s avoid that by keeping the following in mind:

  • You shouldn’t have more than a couple short paragraphs before you’ve stated your main point. If you do, start editing.
  • If you have any of those offenders I mentioned above, cut them and re-read your draft. I’ll bet it’s far clearer and more effective.
  • Assume your readers are there for a reason. If they’ve clicked in, they’ve already expressed interest. Give them what they want, not a bunch of setup.

Here are a couple good examples of short intros and getting to the point:

A direct, well-written pull request by Conor.

Work ethic by Jason F.

Edit for your audience

While writing and editing, you should repeatedly ask yourself two questions…

  1. Who, specifically, am I writing this for?
  2. What do I want them to know when they’re done reading?

If there’s anything in your writing that doesn’t support your answers, it’s time to get editing. You’ll find yourself getting to the point a lot faster and more effectively.

For example, let’s say your answers are…

  1. I’m writing this for Ruby programmers
  2. I want them to learn a few tricks I’ve learned over the years

Bam. Your writing is instantly narrowed in focus. You can tailor your writing specifically to programmers familiar with Ruby. And you can jump right into the tips and tricks, not a bunch of basics about the language.

Be direct, not incomplete or cold

I want to be clear — getting to the point/being direct is not the same as being cold, unfriendly, or incomplete.

Getting to the point shouldn’t come at the cost of watering down your supporting case. Be direct and get to your point, then support your case and tell a compelling story. Be mindful though — don’t add fluff. Be precise.

Along the same lines, being direct doesn’t mean you can’t be friendly (especially in messages or emails). Being warm never hurts — how you say something still helps in getting your point across.

Practice (at the right times)

Don’t worry, everyone struggles with getting to the point sometimes. Every early draft I write has extraneous fluff that ends up getting cut.

The good news is that I (and you!) have plenty of opportunities to practice every day. Every time I write — a message in Basecamp, an email, a pull request, or a blog post — is a chance to keep working at it.

But let’s be honest, I’m not constantly working on it. There are times where I need my writing to be sharp, and other times I just need to get it done. That’s OK!

It’s hard, time-consuming work to do your best writing. So don’t worry about doing it all the time. You don’t have to polish every piece of writing. Instead, pick your moments and really try to nail those.


Remember, getting to the point means greater clarity, and clarity is king when it comes to writing. It saves time, avoids confusion, and enhances comprehension. Combine that with a strong supporting case and a friendly tone and you’ve got writing gold! ✍️💰

If this article was helpful to you, please do hit the 💚 button below. Thanks!

We’re hard at work making Basecamp 3 better every day. Check it out!

Just starting out? Ditch the “full stack developer” label

The words you use to represent yourself matter — and those words mean nothing.

The only time “full stack” means something. 😍

The vagueness and confusion around the phrase “full stack developer” has been lingering for years. Google it and you’ll find plenty of discussion about why it’s such a loaded term.

Given that long-standing vagueness, labelling yourself as “full stack” might be doing you more harm than good, especially if you’re just starting out.

🥞 Are you being honest?

“Full stack” basically implies that you can do it all — that you can build front to back effectively and ship.

But can you really do all of that well?

Anyone with some programming experience can learn the basics of something new and cobble a solution together. But that certainly doesn’t make it good software — a goal every good, experienced programmer strives for.

When someone with a few years experience labels themselves as a “full stack developer”, I’m pretty skeptical. Is there really enough experience there to be good at everything? I’m not saying it’s impossible, but it’s certainly not likely.

Not to mention, what’s a “stack” in 2017 anyway? HTML, CSS, Javascript, Rails, Node, PHP, Go, Python, React, Angular, MySQL, Oracle, Swift, Kotlin, Android, iOS, .Net, Java, jQuery, Mongo, Redis…about a thousand other things?

Here’s the important thing to remember — knowing your limitations isn’t a sign of weakness or impostor syndrome. It’s a sign of honesty, and that in itself is a major strength.

Don’t sell yourself short, but don’t be afraid to acknowledge your (current) limitations either. People will respect you for it.

🥞 What matters to you? What’s your focus?

Referring to yourself as “full stack” doesn’t express any opinions or preferences — it’s vague, broad, and bland. It’s the equivalent of saying “I’ll do whatever work, it doesn’t matter to me”.

And if that’s the case, well, stick with that label. But if the work does matter to you (and it certainly should), speak your mind.

If Rails is your favorite technology, say so — be proud of it! If Javascript is your thing, huzzah! Just don’t fall back to labelling yourself with a bullshit buzzword that everyone else uses.

Saying you’ve been “A proud, productive Ruby on Rails programmer for two happy years” sounds a hell of a lot better (and means a lot more) than “full stack developer”.

Along the same lines, don’t overdo it when presenting your skills.

“Full stack developers” are often the same folks who list out the dozens and dozens of skills they have. Whether they have those skills is irrelevant — it gives the appearance of a quantity-over-quality cover story.

When listing out your strengths, be sure to keep the list short and focused. A handful of really strong talking points is far better than a wall-of-text laundry list of skills. It demonstrates clarity in your thinking and a healthy opinion on what matters to you.


The bottom line is this: the words you pick to represent yourself really matter, especially when you’re just starting out. “Full stack” is far too bullshitty to do you any good.

Figure out your limits, be honest, and focus on what you enjoy most. Express those in your work and how you talk about yourself. You’ll have a clearer head and will be positioning yourself for a much happier, long-term programming career.


If this article was helpful to you, please do hit the 💚 button below. Thanks!

We’re hard at work making the various stacks of Basecamp 3 better every day. Check it out!

A fantastic lesson in sales (without being smarmy)

There are few things I hate more than a smarmy sales experience. You know the ones — high pressure, hidden costs, and with zero interest in your actual happiness. Basically, your typical car salesperson.

Yet I’m fascinated by sales in general. Knowing how to sell is an amazing and valuable skill. So when I see it done right — with genuine care and attention — I stop, listen and learn.


A week ago, the most mundane thing in our house broke — our window blinds. We weren’t really sure how to fix them, so my wife Julie went to a family-owned small business called Rainey’s to ask for help.

When a sales driven business has been open for 78 years, you listen and learn!

Mark, the owner, was super friendly. It may sound obvious, but when a customer is confused, you’d be amazed at how a friendly voice (or tone, if written) can put that person at ease. Right off the bat the customer feels welcome and is open minded.

After a brief chat explaining some options, Mark soon found what we needed. It was a $5 part, but he didn’t charge us for it. He just gave it to Julie for free so we could fix it ourselves.

Even though $5 isn’t a lot of money, the gesture was meaningful. It signaled something small but important: Mark wasn’t interested in maximizing every dollar or short term sale. He was genuinely interested in helping us. He was thinking of us as long-term customers. We really appreciated that.

Mark is no sales newbie though. He used this as a chance for a soft (but effective) upsell: “When one of the strings goes bad, usually they all start to go.” He told Julie how much it would cost to get the whole thing fixed and his exact availability for the next few days and the turnaround time, in case our operation failed. Sharp, smart, well-timed salesmanship.

Julie was so happy with all the help that it made her think of another house project we’ve been lazy about. She asked a few more questions, and boom, it sounds like Rainey’s is our partner for that project too!

What an amazing series of events. With a tiny investment of ten friendly minutes and a $5 part, Mark landed hundreds of dollars worth of work from us this year alone. And who knows how much lifetime business he’s earned from us.

It’s no wonder that Rainey’s has been in business for 78 years. 😍


At Basecamp we admire businesses like Rainey’s, who’ve figured out how to be successful for a long, long time. We like ’em so much that we created a podcast dedicated to their stories called The Distance. Check it out!

A few tips to avoid the never ending comment thread

Asynchronous communications are a wonderful thing for productivity. But they do have a dark side: the all-too-common, never ending comment thread.

Emails and message boards are where they’re commonly seen. It usually goes something like this:

Dan: “I think we should try this.”
<5 seconds later>
Julie: “I’m not sure that’ll work.”
<5 seconds later>
Tom: “Maybe this is another option.”
<50 more comments pile on within 5 minutes>

I know this because I’m guilty of adding to the comment pile too. 😬

It’s not surprising that this occurs. This kind of rapid-fire back and forth feels good. It feels like we’re getting a lot done and having a rich discussion. The problem is that we aren’t, really.

In these kinds of exchanges, nobody is listening. Everyone is so eager to give their opinion that they’re too busy typing without reading. We’re talking past each other, not to each other.


So let me offer three tips to improve these kinds of discussions — things I try to remind myself to do everyday.

Read

And when I say read, I mean read. I don’t mean skim, I don’t mean “get the gist”.

Really read what someone wrote and try to understand it. And if you don’t understand it, ask questions instead of giving an opinion.

Wait

This will be difficult because it runs counter to what we’ve become used to — immediate everything.

But I implore you to try it. Read a comment and then leave for a while. Let your brain background process and actually think about it. Come back an hour later and respond.

This accomplishes a bunch of things:

  • It helps you formulate a complete thought instead of a one line, off-the-cuff response.
  • It sets a positive, slow-response precedent for others. The more people who learn to read and respond thoughtfully there are, the better off your team will be.
  • It has a cascading positive effect by cutting noise. Specifically it gives people who don’t read comments 24/7 a fighting chance to keep up without being flooded with half-baked thoughts.
  • It gives the discussion a chance to resolve itself. You’d be surprised how many times a discussion can go in a positive direction without your input.
  • It let’s you focus on other, more important work!

Switch Tools

If all else fails and the comment thread still spins out of control, you’re using the wrong tool. You’ve taken something inherently slow and are using it way too fast.

If that happens, switch tools. If you’re on a message thread, move up to a chat. If after 10 minutes the chat is falling apart, escalate to a Hangout.

Bottom line — it’s important to recognize the speed of your conversation and match up to the right tool for the job.


That’s it. Three simple things: read, wait, and (if necessary) switch tools. Keeping those tips in mind will make for a calmer, more pleasant workplace in 2017! 😀

If this article was helpful to you, please do hit the 💚 button below. Thanks!

We’re hard at work making Basecamp 3 better every day. Check it out!

Don’t overlook the quiet voices and contributions

A few years ago I worked at a mega corporation. I had just finished up a brutal week of all-day meetings with 20 people. My boss and I sat down to catch up. Eventually, she warned:

“Dan, you need to speak up more. You need to participate and contribute during these meetings.”

I was livid.


She felt that others had “contributed” far more than me.

It didn’t matter that people were talking just for the sake of it — repeating things that were already said and adding no value. It didn’t matter that very little was accomplished from all that talking. It didn’t matter that the week was a huge waste of time. It only mattered that people were speaking loudly and frequently.

All of my quiet contributions — selectively speaking, listening, thinking, writing, leading small group discussions — were being completely ignored.

Suffice to say, I didn’t last very long at that company.

But the sad part is that given the right environment, I could have. I had plenty of energy, ideas, and good work in me. But because I wasn’t always a loud voice, all of it was being overlooked.


If you’re a leader in a company, it’s important to keep your eyes and ears open for all types of contributions. The quiet members of your team have a wealth of insights everyone can benefit from.

While it’s easy to hear the loud voices, they might be drowning out the quiet ones. To tap into the potential of those quiet voices, here are a few tips to keep in mind:

  • Encourage writing as the preferred medium to share ideas. Writing has a wonderful way of leveling the playing field. No single voice can physically drown out or interrupt another. Not to mention it’s far more efficient than huge meetings.
  • Don’t correlate being quiet in meetings with a lack of participation. It’s likely that people are thinking about conversation at hand before responding. This is a good thing. Instant reactions aren’t what you want anyway.
  • Give people time and space to think. Don’t fret if written responses come in slower than you’re used to. Reviewing ideas, thinking, and building thorough contributions takes time and focus. These responses will be far better in quality than the speedy ones.
  • Judge contributions by quality, not quantity. Not everyone needs to chime in on everything — there’s already too much noise and commentary. Look for depth and breadth of contributions, not volume.
  • Don’t assume you’re privy to every bit of collaboration that’s happening. People share and discuss all over the place — in small groups, individually, in public, in private. Just because you don’t see collaboration, that doesn’t mean it’s not happening.
  • Ask for opinions individually. Sometimes the quiet voices just need a tiny bit of encouragement. Find the medium they prefer (IM, Hangout, face to face) and talk to them individually about a particular topic they’re interested in. You might strike gold and it will help them find their voice in the long run.
  • Avoid large group-think sessions. They’re insanely ineffective. Short bursts of collaboration in small groups is great. Huge ideas spread across hours and hours? Not so much.

I really believe in quiet voices. They’ve taught me the most and positively influenced my career — far more than the big talkers.

I hope you’ll give them a chance.


If this article was helpful to you, please do hit the 💚 button below. Thanks!

We’re hard at work making Basecamp 3 and its companion Android app better every day. Check ’em out!

A shining example of how to teach

I was recently fumbling my way through a programming problem. I couldn’t figure out the root issue, so I cobbled together a shaky solution and posted my ¯\_(ツ)_/¯ on Basecamp.

Then Sam Stephenson stepped in to help. I admire and respect Sam a lot — he’s patient, thoughtful, and wicked smart.

He wrote such a well-crafted response to my post that I consider it one of the best teaching moments I’ve experienced.

Here’s his response in its entirety (discussion about why it’s so great follows):


Why do I think this such a great teaching post? Let’s break down it down…

🤔 It’s clear and thoughtfully constructed

Sam’s post was so clear that as I read it, I felt like he was walking me through it in person. This is no accident — he’s an excellent writer.

How did he do it?

Take a look at the structure of the post. He identifies the root cause, outlines a broad conceptual solution, demonstrates a concrete solution, and lastly summarizes. That’s an excellent pattern to follow.

The “design” of the writing is important too. He uses short paragraphs to make the post readable. The words he chooses are clear and simple, and avoid unnecessary complexity. And he makes effective use of contextual elements (quoted text, linked text, and images) to help illustrate his point.

✂️ It’s concise

In a mere 213 words Sam articulates the issue and a potential solution. That isn’t easy — a post like this could easily be 2–3 times as long.

There’s no fat in his post. It’s thorough, direct, and doesn’t wander around non-essential details. He makes his point and gets out.

This is critically important. It’s very difficult to parse out what’s important if it’s buried in fluff. Keeping the post focused is a big part of why it’s effective.

🚦It’s directional, not a direct solution

A great way to teach is to point someone in the right direction, but not give them the exact answer or code snippet. Let them figure out the details and learn from whatever issues come up as a result.

In other words, don’t be Stack Overflow.

In this case, Sam’s given me plenty to work with. But it’s not a direct solution I could lift into our code, and that’s a good thing.

🛣 It goes the extra mile

Sam is Ruby/Rails expert, not an Android developer.

Yet he put the extra time and effort into setting up an Android development environment and working through a proof of concept. Nobody asked him to do it — he just did it!

He could have very easily responded with a one line post saying “Did you try this…”, and we probably would have gone back and forth a dozen times on it.

But he didn’t. He slowed way down, worked through the solution (in an unfamiliar development environment), and posted a thorough response a day later.

In the long run, Sam’s extra effort saved us time (no back and forth discussion), made the app better for customers (I fixed the app in a couple hours) and taught us all something new.


This was an exceptional bit of teaching by Sam. It’s an example I hope we can all learn from and aim for.

Every day we have opportunities to teach others. Often we ignore them or give them only a few minutes of our day. But I hope this example shows how impactful teaching can be when we put genuine effort into it.

I’ll never forget what Sam taught me here — no, not just the technical bits. Really what he ended up teaching me was how to be a better teacher. 🤓


If this article was helpful to you, please do hit the 💚 button below. Thanks!

Teaching is a big part of what we do at Basecamp — we’ve been sharing our ideas and teaching on our blog for many years.

When we’re not sharing and teaching, we’re hard at work making Basecamp 3 and its companion Android app as great as they can be. Check ’em out!