A question of skills

One of the first books I can remember reading was A Wizard of Earthsea. I was seven or eight, and it scared me to my core. That dark ocean was real and menacing in ways I couldn’t fully appreciate until later.

Beyond fear, one of the things that stuck with me from that book was the idea of true names. David Mitchell’s love letter to Earthsea paints the picture:

Knowledge of a thing’s true name brings mastery over the object, and as this applies to people as well, to tell someone your true name in Earthsea is an act of intimate trust.


I remember reading that tweet, and how violently I agreed with it. Hard/soft always felt jarring somehow. Ok, gone. I’m warming my hands on the smouldering embers of the dichotomy.

“So, what do we call them instead?”


Back in January, Seth Godin proposed vocational skills and real skills:

Let’s call them real skills, not soft.

Yes, they’re interpersonal skills. Leadership skills. The skills of charisma and diligence and contribution. But these modifiers, while accurate, somehow edge them away from the vocational skills, the skills that we actually hire for, the skills we measure a graduate degree on.

So let’s uncomfortably call them real skills instead.

Before we anoint a replacement, let’s take a moment. Why are we making that distinction? How does this benefit us? How does it help us to achieve our aims?

Almost everyone I’ve spoken with, and every post I’ve read, agrees that hard skills are easier to measure. That soft skills are more difficult to pin down, but equally important (I’d argue even more so). I can buy that. So what?

Dividing skills into types is an attempt to be more precise that costs us clarity instead of adding it. Our every instinct tells us that precision is valuable. Language is an evolving, imperfect attempt to describe the universe. When we reach for precision, we’re hoping to get closer to the true name of things.

There’s a trap here. When we spend time and wit seeking a more perfect description of the different types of skills, we’re working at the wrong level of abstraction. Precision only helps us if it changes how we act.


There doesn’t need to be a distinction. Skills are skills. We can teach them. You can learn them. There’s no meaningful difference in the steps you take to develop a ‘vocational’ skill or a ‘real’ skill, a ‘hard’ or a ‘soft’ skill. An authoritative taxonomy of skill types doesn’t change how you approach things.

What do we need to pick up a new skill? Well, some combination of the following:

  • Time
  • Desire
  • Access to knowledge
  • Practice
  • Observation
  • Making changes in response to what you observe
  • Support

Measuring success is the same whether you are learning HTML or practicing sincerity. You observe outcomes. You need to understand what you are trying to do before you do it, a core part of mastering any skill.

Making this change is pretty straightforward. When you are working on a job post, you already don’t mention hard or soft skills. You talk about the skills and experience you’d like an applicant to have. If you are working on a training plan for yourself or a team member, you can list the skills you want to focus on. Save yourself the mental overhead of working out if a skill is vocational or real. You won’t need it.

We can discard the distinction without guilt. Chipping away at gendered stereotypes is reason enough. Part of the evolution of language is recognising when words are no longer true, or shouldn’t be. We should seek a more comfortable level of abstraction, a truer name.

The names we choose matter.


With endless thanks to Ursula K. Le Guin, who influenced me more than I ever realized. A huge thank you to Erika Hall for prompting this in the first place. Thanks also to Mathew Cropper, Chase Clemons, Brad Stott, Elliott Hilare and Yechiel K for talking with me about this and helping me to see beyond my limits. 💚 to Chase Clemons, James Glazebrook & Wailin Wong for editing.

Your struggles can inspire others

Think back to the the last time you struggled mightily with a programming problem. Did you share it with the world?

If you didn’t, that’s totally OK — most of us don’t! Why would we? Nobody enjoys admitting defeat, much less wanting to make a big deal out of it.


But kudos to you if you did share your struggles, because I bet you made a pretty big positive impact on someone. It very well may have inspired them.

I’m speaking from experience. Someone I respect recently did exactly this for me out of the blue. We were chatting a bit when they mentioned how they were struggling with some parts of Kotlin, just as I was.

What an astonishing revelation! I was surprised (and impressed) by this honesty. How could it be that this person, a great programmer whom I admire and has done amazing work, be struggling just like me?!

It’s strange — logically I know that of course everyone struggles and has rough patches. But in an era of highly polished tweets, blog posts, and conference talks, it’d be forgivable to think that programmers out there never struggle with their work.

But of course they do. Which is why when someone you respect shares their real-world struggles with you, it reinforces and crystalizes an important point: there’s no magic to anything we do.

These vulnerable moments are a reminder that all of us are just programmers trying to do our best. That we all succeed basically the same way — by working hard, struggling, learning, and keeping at it with determination.

It also made me realize that while we often share our successes and expertise with the community, it’s much rarer that we humble ourselves and reveal our weaknesses. Don’t get me wrong — it’s amazing to be surrounded with smart people that are gracious enough to share their knowledge with us. A knowledgeable community is incredibly powerful.

But it’s also incredibly powerful and inspirational to share your struggles. Doing so isn’t a sign of impostor syndrome — no, it’s a sign confidence, generosity, and honesty. I’ve been fortunate enough to be on the receiving end of such honesty more than once, and it always inspires me to keep at it and have confidence in myself.

So remember, we all struggle. If you’ve hit a rough patch today, don’t fret. There’s a good chance just about everyone else has too. Hopefully they’ll tell you about it soon.✊


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. Please check it out!

The importance of sucking

Lessons from a bruised leg…

My leg looked liked this a few months ago:

Gross.

No, I didn’t get surgery. No, I was not mauled by a bear.

I went snowboarding for the very first time over New Year’s.

The experience was brutal, needless to say. I fell probably a hundred times. Over and over and over. For those of you who’ve learned to snowboard before, you know what I’m talking about 🙂

Surprisingly, the most painful part of the experience was not the physical aching of my knees or my wrists or my butt.

Rather, the greatest pain I felt was a sinking sensation I had in the pit of my stomach: I was really bad at snowboarding. I wasn’t picking it up “as fast as I thought I was supposed to.” I was frustrated and embarrassed.

I recall thinking to myself, “Maybe snowboarding just isn’t meant for me…

Then, I tried to remember the last time I felt this way. When was the last time I was this bad at something?

I couldn’t remember. I couldn’t remember the last time I was this outside my comfort zone. I hadn’t dared to suck at something — to allow myself to be vulnerable, to look a little “dumb” to my friends — in a very, very long time.

As adults, we gravitate toward the things that we initially have the least resistance to. The new hobbies I’ve tried to pick up as an adult — whether it’s screen printing or yin yoga — are all things I’ve already had a predisposition for. I’ve already been painting and doing yoga for quite a while. It wasn’t a stretch to try those new mediums and related activities.

But with snowboarding, I was in foreign territory. I wasn’t predisposed to snowboarding. And I’d forgotten the importance of doing the things you’re not predisposed to.

When you let yourself be bad at something, you regain your humility. Sucking at something humbles you. As adults, we protect our egos by not allowing ourselves to be bad at things.

You also remember what the point of learning is: to learn. When you learn, you mess around and you mess up. You’re not supposed to be proficient from the get-go.

And, you rediscover that persistence leads to progress. Day 3 of snowboarding was 10X better than Day 1. I got better. In fact, I got back from my second snowboarding trip just yesterday… and I did a few runs without falling once!

I couldn’t be more grateful that I was so bad at snowboarding. It was the reminder I needed to push myself outside my comfort zone more often. To fight the instinct to expect excellence when I learn something new.

Now, I want to seek out more things I’ll suck at.

How about you?


Enjoy this piece? Read more of Claire‘s writing on leadership on the Know Your Team blog. And, check out Know Your Team – software that helps you become a better manager.

Living without expectations


Last year I wrote how I’ve never had a goal. I was reflecting on how I just move from one thing to another without feeling like like I’m aiming for anything. It works for me.

Here’s another thing I try not to have: Expectations.

One of the few things in life we control is our reaction to things. And expectations tee up those reactions. They often set the odds on the outcome, and the odds usually aren’t in your favor. I’ve decided I’d rather stick with actual reactions rather than putting my reactions at a disadvantage by mixing them with with my everything-should-be-amazing imagination.

What’s gained by setting a bar on outcomes you don’t control?

When you don’t have expectations, you experience things objectively rather than tinted with presupposition. Then if you do happen to be disappointed, it’s only because the experience wasn’t good, not that you thought it was going to be INSANELY GREAT and then only ended up as GOOD. A good experience should always leave you smiling, rather than disappointed because it didn’t measure up to a story you made up.

Leaving expectations out of it makes everything more direct. It’s simply how you feel about something rather than how you feel colored by how you thought you were going to feel.

To put it another way, not having expectations means you can’t be let down. Being let down means something didn’t measure up to what you expected. So instead of being let down about something, I’d just be unsatisfied with the outcome. That may sound subtle, but it has a distinctly different emotional impact.

Expectations are what let you down, not outcomes. Outcomes just are. I’ll evaluate those rather than how they measured up to some artificial line in the mental sand.

In practice

I don’t drive our business with expectations. We simply do our best work and the chips fall where they may. Having expectations makes outcomes binary — you did what you hoped to do, or you didn’t. I’d prefer to live with just doing and enjoying the flow. BTW, predictions are different from expectations. Predictions don’t come with an emotional impact if the outcome doesn’t measure up. Predict wrong? “I was wrong”. Expectations not met? “That sucks”. See the emotional difference?

In my personal life I don’t have expectations of others, except to say that I assume all people are good until proven otherwise. I’m more interested in how people are, than what I expect them to be. If you ever want to be disappointed by someone, set unrealistic expectations. Of course as you get to know someone you have a sense of what they’re capable of, but even then people just do as they do, they don’t miss, meet, or exceed my expectations.

If I’m competing on something, I don’t expect to win. I want to win. I’ll do my best to win. But I don’t expect to win. My expectations have nothing to do with what I’m competing on, and I don’t control the other side. I can only do my best regardless, so why measure that against anything other than the ultimate outcome?

When I go to a movie I don’t expect it to be bad, good, or great — I just want to go see the movie. After it’s over I can ask myself if I liked it or not, not how it measured up to how much I thought I’d like it (or not). I’m convinced that people would like things a whole lot more if someone else didn’t tell them they wouldn’t like it. Stuff’s pretty great, you know.

When I head to the airport, I don’t dread security or lines or waits. Why? Because I have no expectations of those things. And let’s face it — expectations of those things are usually bad. So if they are actually bad, you expected disappointment and got it. What a sad way to start a day.

When I go for a run I don’t expect to run a 6 minute mile, but if I do, great. And if I don’t that’s fine too — I still went for a run. If I was competing, that might be different, but I’m just enjoying.

When the new iPhone comes out, I’m never disappointed that it didn’t have this or that. I’m usually delighted. Why? Because I wasn’t expecting anything other than something new. I can judge that thing when it exists, rather than setting up opportunities to be upset. The number of people who complain about something new that didn’t exist five minutes ago is a testament to the negative power of expectations.

Indifferent?

Is this indifference? It’s not — I’m not indifferent. I have plenty of opinions and points of view. Some strongly held, others less so. But I only consider outcomes once they happen rather than writing a script in my mind that I react to after the fact.

I wasn’t always this way. I used to set up expectations in my head all day long. Constantly measuring reality against an imagined reality is taxing and tiring. I think it often wrings the joy out of just experiencing something for what it is. So over the past few years I’ve let those go and ended up considerably happier and more content.

And really, every day has a shot at being pretty great when your only expectation is that the sun comes up.

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!

Rewriting bad writing

Become a better writer by taking a poorly written piece and rewriting it yourself

Once in a while I read something so complex and poorly written, when I’m finished I have no idea what I just read. It’s insanely frustrating.

While writing isn’t an easy skill, people make it way harder than it needs to be. They think choosing complex language shows skill and smarts.

It doesn’t! Writing plainly and clearly does.


Somewhere along the way, Jason Fried dropped a lesson on our team: if you think something is poorly written, rewrite it.

It 1) is a chance to learn 2) shows you’re willing do the work beyond complaining and 3) helps you think about how to handle a similar situation. Ultimately the exercise makes you a better writer.

Let’s do it.


Case study: A Mozilla project announcement

Below is an overly complex, hard to read project announcement. Try to fight your way through it. 😰 My rewrite follows.

Disclaimer: This is an isolated critique of a single piece of the author’s writing. It’s absolutely not about them as a person or their other work. I’ve written plenty of bad stuff too. Please feel free to go back and critique the hell out of my writing, it’s a good way to learn.

Mozilla’s version

Announcing Project Mortar

In order to enable stronger focus on advancing the Web and to reduce the complexity and long term maintenance cost of Firefox, and as part of our strategy to remove generic plug in support, we are launching Project Mortar.

Project Mortar seeks to reduce the time Mozilla spends on technologies that are required to provide a complete web browsing experience, but are not a core piece of the Web platform. We will be looking for opportunities to replace such technologies with other existing alternatives, including implementations by other browser vendors.

In order to keep costs low, we may use APIs internally that are not considered web standards. These APIs will not be exposed to the web. Solutions that both reduce our support cost, achieve the desired user experience, and make use of web standards will be preferred.

The project will start by investigating how Firefox handles PDF rendering followed by looking into lower cost approaches to providing Flash support as it’s usage continues to decrease. Project Mortar is currently investigating using the minimum set of Pepper APIs needed to support the PDFium library and the Pepper Flash plugin. If successful, this work will allow us to completely remove NPAPI support from Firefox once NPAPI is disabled for general plugin use.

Keep an eye on https://wiki.mozilla.org/Mortar_Project for status and future updates for this project.

Here are the main problems with this announcement:

  1. Its super long sentences are hard to parse and understand.
  2. It uses a lot of impersonal third-person language.
  3. There’s too much detail/fat drowning out the main message.

Let’s fix those and see what we can learn.

My version

Today we’re launching Project Mortar.

The goal: advance the web by reducing Firefox’s complexity and long-term maintenance.

We all want to make the best browsing experience for our users. That means we need to spend less time building non-core web components. Especially when we can replace them with existing alternatives.

We’ll keep our eyes open for the best options, like those based on web standards. Occasionally we may need to use our internal, closed APIs. Together they’re our best chance at reducing support costs while still giving users a great experience.

We’ll start with two major areas in Firefox — PDF rendering and Flash.

We’re starting with PDFium and Pepper Flash as possible replacements. We’re currently looking at what Pepper APIs we need to pull this off. If all goes well, we can completely remove NPAPI support after it’s disabled for general plugin use.

We’ll continue to post updates on the project wiki.

As always thanks for reading and for your continued support!

I don’t mean to pat myself too hard on the back, but I think that’s a a lot clearer and easier to understand. 😉

What do you think? Better or worse? What did I do right or wrong?

Write your version in the comments below and let’s discuss — remember, it’s a good way to learn!


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

Writing is a big part of what we do at Basecamp. It plays an important role in making Basecamp 3 and its companion Android app as great as they can be. Check ’em out!

Your ideas are important — share them with the community

Sharing your ideas helps you and others get better. Here’s how to get started.

At least once a week I say to myself, “That’s interesting. I should write something about it.”

And then I don’t. A bunch of excuses fly into my head.


“Lots of people have already covered this. I’m not an expert. Why would anyone care what I think?”

Sound familiar?

I need to constantly remind myself to stop making excuses and that it’s important to share my ideas with the community.

Maybe I can convince you to do the same?

Ditch the excuses

The fundamental flaw in these excuses is assuming your perspective isn’t valuable to others. It’s a convenient excuse to say your viewpoint isn’t unique, so why bother.

But really it’s the exact opposite.

Your perspective is 100% unique — a composite of thousands of life experiences that nobody can replicate. Nothing that’s ever been previously shared has been through your words and the lens of your experiences.

So don’t worry about being original. You already are.

Understand the importance of sharing

You still might be wondering — why should I spend the time and effort to share?

It helps you

Sharing teaches you how to build compelling stories and make persuasive arguments — clearly and concisely. You’ll learn something new about your work every single time you share.

Don’t worry if you’re “just” a beginner. If you make a mistake, the community will offer helpful tips on how you can improve. That’s free advice from a bunch of experienced people that you can learn from!

And don’t forget — you’re simultaneously leveling up your portfolio. Over time you’ll build up a fantastic body of work you can point to at any job interview.

It helps others

Whether you recognize it or not, you didn’t get to where you are alone — you’ve learned and improved with help from a lot of people.

Any time you’ve read a blog post, used an open-source library, or learned from a conference talk, it’s because someone else helped you by sharing their ideas.

So it only makes sense to give back to a community that’s helped you so much already (and will continue to do so).

Don’t worry, it took me a long time to realize this too. But I encourage you to really think about it sometime. It could really serve as strong motivation for you to start putting your stuff out there too.

Get started

Hopefully by now I’ve convinced you that 1) your perspective is valuable and 2) it’s worth your time.

So how should you get started?

Keep your eyes and ears open for inspiration

I read, watch, and listen to a lot of stuff that inspires me to share my thoughts. Sometimes I agree with them, sometimes not.

But the more you consume, the more chances you have to come up with shareable points or counterpoints. Not to mention, simply consuming content is a good way to learn.

Focus on topics that are important to you

I usually loiter at the intersection of learning/teaching, Android, Kotlin, arguing against excessive work, and the importance of teamwork — all things I care about.

Find the subjects you care about, not trending topics. You’ll know you’re on the right track when the ideas are flowing and don’t feel forced.

Find a medium that works for you

For me it’s writing. But there are lots of other ways. Talk at a conference or local meetup. Record a podcast. Shoot a video series. Contribute to an open-source project. Write a gist and tweet it out.

There’s absolutely no shortage of ways to get your ideas out there.

Look at existing examples of sharing that you liked

Read other people’s writing, watch their videos, and listen to their podcasts. What did you like? What would you differently? Use existing content as a model, then make it your own.

Just start!

Inertia is an absolute killer when it comes to sharing, so getting started will be the hardest part. You’ll be a little nervous and overanalyze everything you make. I certainly was.

I wish I had better advice, but you’ll just need to fight through it and get some stuff out there. Once you get past the first couple, it gets easier — and your content will get a lot better too.


I hope I’ve convinced you to start sharing! If you need any help, you can always hit me up on Twitter.

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

In addition to sharing and teaching, 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!

Learning and mastering isn’t the same


When I first began making applications for the web, getting started was hard. Just figuring out which components to download, how to configure them, and getting Hello World through it all was a daunting affair. Frameworks like Ruby on Rails changed that, and now it really is possible to animate a complete database-backed web application in 15 minutes or less.

That means these days you can go from (almost) zero prerequisites to a (sorta) working software prototype in a bootcamp’s worth of introduction material. That’s amazing. Basic proficiency has never been more attainable or approachable.

Given this leap, it’s no wonder that people mistake the beginning for the end. That getting started is the same thing as knowing it all. But it remains a completely unrealistic expectation, and thus a mistake. Building a complete information system, like, say, your Basecamp or Shopify or GitHub or Zendesk remains real work that requires deep skill. It’s foolish to pretend otherwise.

And perhaps we have pretended otherwise at times. I’m certainly guilty of focusing on just how easy we made getting started that the conversation often didn’t extend to the work it takes to finish. Simply because that’s what felt like the main obstacle to getting more people onto the path of learning at the time.

Now that this obstacle is mostly cleared away, it’s time to focus on the latter part of the discussion: Becoming really good at anything takes time. Web development is no different, not even with Rails. We’ve changed the game from “hard to learn, hard to master” to “easy to learn, hard to master”. Yes, the second part remains the same.

I’m still learning. I’m still getting better. And I’ve been at this web development game for damn close to twenty years (if you count when I started dabbling with HTML/CSS). That doesn’t at all mean it’ll take you twenty years to become good at it, but it probably does mean that you should have realistic expectations about what you can learn in three or six months.

And it’s not so much about how long it’ll take you to learn your way around the framework or the language or the ecosystem. It’s as much as how long it’ll take you to become an expert. It’s one thing knowing there are 10 different ways to do a thing; it’s another to know which is a better fit and when.

This is part of why I like to compare writing software with writing prose. Most people in the developed world will have basic proficiency writing their native tongue by the time they finish high school. But how long does it take to become a great writer? Longer than that. Much longer, in most cases. Few find that surprising.

Yet plenty of people do seem to be genuinely surprised that a developer who just picked up Ruby on Rails, or any other extensive framework, language, or ecosystem, doesn’t make all the right choices the first time they’re faced with them. And that’s just plain silly.

Let’s continue to celebrate how easy we’ve made getting started, but let’s also set a realistic timeline for mastery. Not to scare anyone off the journey, but to prepare them for it. A glorious, years-long journey of learning. It’s a lot of fun if you know what you’re in for.