Real Work vs. Imaginary Work

Since we launched Hill Charts in Basecamp we’ve been fielding many interesting questions. One common question is: how do we catch more problems in the uphill phase so they don’t surprise us later?


What happens is, people think a piece of work is downhill, and then all of a sudden a problem comes out of nowhere. Especially when it comes to programming issues. “Why didn’t we catch this earlier?”

The reason often traces back to the uphill phase. An engineer looked at some work and imagined the solution in their head. “Yeah I don’t think that’ll be too hard.” They saw in their head how to do it, so they positioned the work at the top of the hill.


What happened next? After they got their hands dirty and started building, the reality turned out to be more complicated.


The problem is the uphill work was imaginary. Thinking about how you’re going to do something is not the same as rolling up your sleeves and trying.

The solution is to start at the bottom. If all of you’ve done is thought about the solution, then mark your status at the bottom left of the hill to show you haven’t built anything yet.

Start at the bottom when the solution is still imaginary

Now to move uphill, write some code to prove out the idea. Pick out the most essential steps or moving parts and write enough to validate the approach. Some teams call this “spiking” or “stubbing out” the work.

Doing real work to move uphill

You’ll still run into the unknown. But the difference is now you and the rest of the team expect that to happen because you’re still in the uphill phase. In fact all of your development work on this side of the hill is about spiking the unknowns and finding these trouble spots.

Catching the problem on the uphill side

You can’t bet on work that isn’t over the hill. So nobody will be surprised if a problem comes up on the left side. This is a healthy time to get stuck.

There could be a variety of solutions. Maybe you need to put heads together with your peers. Or get advice from someone senior. Or consider a different package or library to do what you want. Whatever the solution, everyone can see the problem as a step toward figuring out what’s going to work — what’s going to make it over the hill.

Doing work to get over the hill gives you more certainty

Having spiked out the most important parts of the problem, you can be confident that what’s left really is just a matter of execution. Sure there will be little surprises, but you’re less likely to run into something that blows the budget or breaks important assumptions.

The key point here is: imaginary work doesn’t count. Get to running code early. Or a rough interface. Or an outline of the copy. Whatever it is, the way to get uphill is to roll up your sleeves. Seek out the things that might go wrong and show evidence that the approach will cover them all. Then when you get to the top of the hill, your team can trust that the work is really going to ship as planned.

Conceptual compression means beginners don’t need to know SQL — hallelujah!


It used to be a fundamental requirement that you learned an extensive amount of SQL before you were able to start working on database-backed applications. It was taken as self-evident that you needed to speak the native language of the database before you were qualified to use it. And better yet, you really ought to understand and care about your particular brand of database engine.

This is no longer so. That fact has snuck up upon us, but it’s none the less true — and that’s amazing.

Through advances in leaky abstractions, we’ve managed to compress the conceptual overhead of the database so much that it needn’t feature in the introduction material for making database-backed applications. In Rails, we call that abstraction Active Record, and it falls into the category of object-relational mappers (ORM).

The ORM was long derided by programmers as an unreliable, even harmful, aid of the lazy or the weak. Something Real Programmers shouldn’t expect to lean on, as it was likely to break down if not immediately, then certainly soon thereafter. And then you’d better know all your relational theory!

That’s the past.

Basecamp 3 has about 42,000 lines of code, and not a single fully formed SQL statement as part of application logic! It serves millions of people. It not only leans on the ORM abstraction, it hardly even thinks about it the vast majority of the time.

Do you know what else application programmers rarely need to think about any more either? Memory management and garbage collection. It used to be just as foundational to know your pointers, your destructors, your mallocs, and all the other conceptual overhead needed to deal with manually managing memory. Now it isn’t.

Our abstraction of SQL isn’t quite yet to the point of our abstraction of memory management, and certain frameworks and environments are further ahead than others, but it’s getting closer. The first version of Basecamp had a bunch of #find_by_sql calls, the latest have none. That’s progress.

It’s not that knowledge of SQL isn’t nice to have. It’s good to know a lot of things. Just like it’s helpful to have a strong conceptual model of how computers deal with memory management. It’s just that you no longer need to know these things to start making applications, and that’s a wonderful thing.

SQL, like memory management, is a concept you can unpack when you need to. Further down the line of your career. Then after you learn it, you can compress it back down again and spend more of your mental capacity on other things most of the time. I used to write SQL statements every day. Now maybe I do so once a month? Less? And that’s against a major application that’s reached a scale that most beginner apps never will.

Some programmers will scoff at this notion instinctively. That it’s simply irresponsible for programmers to start writing code until they know these historical fundamentals. I suppose it’s natural to think that all the hard work you spent learning the basic concepts — that indeed were required when you got started — should still be taught to all on day one. This is one of the key pitfalls of experience. Falling in love with the trials and tribulations you had to suffer, rather than rejoicing in the fact that the next generation doesn’t have to endure them.

The relational database is a glorious invention, but for most programmers it doesn’t need to be more than an appliance. Sure, take the time to learn how the drying tumbler machine works, it may well save you a service call to a specialized technician one day. But it’s hardly a requirement for living with such a device and getting your clothes dry.

The relegation to “appliance status” isn’t a dig, but an honor. It means we’ve finally made the technology and the abstraction so good that many, if not most, programmers don’t even have to think about it on a daily basis.

It also means it’s become a commodity. At Basecamp we happen to use MySQL, but to be honest, it’s basically only for historical and operational reasons. We could switch to PostgreSQL tomorrow, and I wouldn’t really give a damn. We have nothing in the application that relies on a particular brand of the database appliance.

Building stuff with computers means building on top of abstractions. CPUs, 1s and 0s, assembler, C compilers, database drivers, memory management, and a million other concepts are required to make our applications work. But as we progress as an industry, fewer people need to know all of them, and thank heavens for that.

It takes hard work to improve the conceptual compression algorithms that alleviate application programmers from having to worry about the underpinnings most of the time, but it’s incredibly rewarding work. The more effectively we compress the concepts of yesterday, the lower the barriers to entry become. And we need low barriers if we are to get more people started making applications.

SQL is perhaps the brightest example of conceptual compression over the past decade or so, but application work is full of other examples. And we need such conceptual compression more than ever to starve off specialization, and to preserve the power of individual generalists to make complete applications.

We’re currently living through an explosion of conceptual expansion and experimentation on the client-side in the web application world. That’s really exciting! Lots of new ideas and approaches churning rapidly. But it’s also needlessly intimidating in many ways. We don’t all need to spend hours or days learning how to configure build pipelines. Some day our leaky abstractions will be good enough that the conceptual compression will relegate such tooling to appliance status as well. That will be a good day.

You can’t learn everything. You can’t hold every concept fully expanded in your head. And moreover, you shouldn’t. As we compress formerly fundamental concepts, we make room for new, grander abstractions. These are the leaps of progress it’ll take to continue to make us more efficient and ultimately more effective.

But I get that it’s hard to break habits. Like the stereotype of an old person complaining about the price of gas or a gallon of milk because their frame of reference is anchored in a time past. Broad-based progress sometimes need that generational churn to really happen (and that’s not about your physical age, rather the years of experience).

Don’t be a fogey. Don’t fight the conceptual compression. Help make it happen.

Getting Real: A new YouTube channel from Basecamp

Click the image above to jump to our new YouTube Channel!

For years people have been asking us how. How do you design things? How do you code things? Why do you do it this way vs. that way? How do you think about writing? How do you think about what makes it into a product and what does? How do you decide which features to build and which ones not to? How do you stay up on everything that’s going on in your business?

We’ve written about these topics for years — and we’ll keep writing about them — but we want to bring some show to the tell. So we started a new YouTube Channel called Getting Real. To start, DHH and I will be posting occasional videos of actual day-to-day work. Down the road other people at Basecamp may join in.

So far we have a dozen videos up. More are coming. Check out what we have so far and subscribe to be notified when new ones are ready to watch.

We hope you dig it! And if you have any ideas for future episodes, please post a comment below.

On Writing Software Well


I’ve begun a new YouTube series called On Writing Software Well where I explore the real Basecamp codebase in search of interesting programming topics. It’s less “here’s how to do it” and more “here’s what I was thinking when we made this choice or took this direction”. And it’s intimately grounded in real, production code that’s been used by millions of people.

It’s partly a reaction to the endless debates we tend involve ourselves in as software writers without looking at real code. When you debate without code, you’re likely to get sucked into illusions of disagreement. You argue from your experiences with codebase A, I argue from my experiences with codebase B, and we clash because A isn’t B. That’s just silly.

Yet somehow arguments grounded in production code are rare. Few people seem willing to lift the curtain on such codebases, which is a damn shame. Because that’s where the real wisdom is buried. That’s where people have been forced to make actual trade-offs between competing patterns and practices. It’s those trade-offs and the circumstances around them that are valuable.

Programming arguments based in example code is most often stylized and idealized. It’s Platonic shadows on the cave wall. So easy to dig in and defend a technique when you don’t actually have to worry about guarding the flanks, setting up camp, and getting your supply lines in order. You know, like in real life.

So that’s my mission: To take you into the trenches and have you fight by my side in the battle against complexity and in the search for beautiful code.

Yes, the code is all Ruby and Rails, but the principles should travel reasonably well. So even if you don’t do Ruby on Rails, I’d be surprised if there wasn’t something to in there to pique your interest and rattle your convinctions.

Here are the first five episodes:

It’s time for recurring meetings to end

Why are we still doing this to each other?

It’s thankfully been a really long time since I’ve been invited to a recurring meeting. But I heard a couple mentions of them last week, and it brought back terrible pre-Basecamp memories.

It reminded me that not everyone is so lucky — many people still have to attend those soul-sucking, brain-draining, pointless recurring meetings. You know the ones — they’re usually filed under euphemisms like “stand-ups”, “status”, and “check ins” and happen on a daily or weekly basis.

They’re terrible. Let’s discuss why and see if we can help each other get rid of them.


They force people to meet even when there’s nothing to discuss

Ever gone to a recurring meeting only to find a bunch of blank expressions and everyone just kinda looking at each other? Welcome to the recurring meeting.

For some reason the default corporate mindset is that there will always be something to discuss, so having a regularly scheduled meeting is good because it “gives folks a chance to catch up.”

But if you really think about it, is there always something to discuss? Aren’t there just some days or weeks where things have gone smoothly or people are just doing their work and there’s nothing to chat about?

How often are these recurring meetings actually needed? 10% of the time? 50%? I have no idea, I can’t see into the future — so why do meeting organizers think they can?

A common retort you’ll hear from organizers is that you should keep recurring meetings around because “you can always cancel them”. And sure, in a perfect world, that helps a little — it gives me back some of my day. But this also assumes that every meeting organizer is super vigilant in managing their meetings. And let’s be honest, they’re not.

Beyond that, canceling an instance of a recurring meeting doesn’t fix all the other problems they cause in aggregate. Keep reading.

They create a vicious cycle of meetings and overwork

Here’s what meeting organizers do: they look at everyone’s calendar and try to find the best time for everyone.

But because there are so many recurring meetings, blocks of time are hard to come by. So organizers start scheduling new meetings at inconvenient times because those are the only times available: early in the morning, late in the evening, over lunch. All times you should be relaxing, not working.

If a majority of recurring meetings were simply off the books and scheduled as needed, everyone would have more available time and fewer meetings overall. Imagine the possibilities!

This also shows why “just canceling” a recurrence doesn’t fix everything — a recurrence is already eating a block of time that other organizers can’t schedule against, so it has a cascading effect of breeding meetings at even worse times.

They hurt your team’s work and workflow

If you know you have a meeting in an hour, do you start your deepest, most complex problem solving work? I’d venture to guess most people don’t. I certainly don’t.

It makes sense — if you know you’re about to be interrupted in an hour, why start the really deep-thinking work you need to do. You’re probably more likely to tackle a few small, easy things. It’s a subtle effect, but imagine that happening multiple times a week. How much good, deep-thinking work is lost because of looming meetings?

If those recurring meetings weren’t there, people might choose an entirely different set of work. They’d have longer stretches of uninterrupted time, which are crucial for deep thinking and problem solving — things designers and programmers need every day to do their best work.

Oh and to address the magic bullet of “just cancel the meeting” again — getting a cancellation 30 minutes before the meeting gives me the meeting time back, but it’s already screwed at least a couple hours of my day’s work.

They become a dumping ground

The recurring meeting is the dumping ground of everything you don’t want to deal with now (probably because you’re stuck in another meeting).

How often have you seen this happen — you start talking with someone, can’t make a call, and then they say “let’s talk about it at the status meeting”?

Recurring meetings are a crutch — they let you defer decisions you probably should (and could easily) just make now. Remember, decisions are temporary!

“If circumstances change, your decisions can change. Decisions are temporary.”
Jason Fried, Rework

This is yet another reason why “just cancel it” may sound good on paper, but doesn’t work in practice. People tend to find ways to fill scheduled meeting times.

They drown out the important stuff

Recurring meetings can cause serious calendar overload for many people — they can be double or even triple booked at times. There’s considerable mental overhead to look at a busy calendar and try to decipher what’s important and what’s not. Ever missed an important meeting because you got things crossed up on your excessively noisy calendar?

And from a human perspective, meetings also make people think twice about scheduling important personal appointments. Yes, of course most of the time it’s OK to miss a recurring meeting. But have you ever thought twice about scheduling a personal appointment because there’s a meeting on your calendar? Of course you have, and so have I. It may be a small thing, but even the most unimportant meeting might make someone think “I should really go to this” instead of taking care of something far more important to them.

“Yes, awesome, another recurring meeting!”

I’m half joking, but honestly, have you ever heard anyone say this? Or is it more often a deep sigh followed by “Ugh, another meeting”.

Or how about this — remember the last time one of your meetings got canceled and how overjoyed you were that you didn’t have to go?

Doesn’t that tell you something?


Alright, so we’ve established I’m not a fan of recurring meetings. Maybe I’ve convinced you they’re terrible, or maybe I haven’t.

Either way, would you perhaps, pretty please consider trying a few things either as a meeting organizer or attendee? You might be pleasantly surprised by the results.

Organizers: Try reversing your default mindset

If you’re a meeting organizer, try this for one project—reverse your thinking and assume you don’t need one of the recurring meetings you usually schedule. Instead see how things go without it, and if a discussion needs to happen, schedule a standalone meeting with the fewest people necessary to make the call.

Things might be a little uncomfortable or harder at first, but in the end I bet everything will be fine (and your team a lot happier for it).

Attendees: Ask the meeting organizer if you can skip

This might be tough because a lot of times meeting organizers are in positions of power (managers, directors, your boss, etc.) But if you’re one of the people getting killed by recurring meetings, try asking the organizer if you can skip them unless there is something specific you’re needed for. Most of the time any reasonable person will be OK with that.

This still makes you a willing participant and available, but by default you get to do your real work unless they specifically call on you to attend.

Attendees (Bonus Points): Thank the never-calls-a-recurring-meeting organizer

They’re a rare breed, but if you ever notice someone who breaks from the mold and rarely calls a recurring meeting, thank them. No, seriously. They might chuckle, but they’ll appreciate that you noticed and it’ll validate how they run things. It will give them the confidence to keep doing things their way — recurring meeting free!


So hey, it’s nearly 2018 and it’s a great time to turn a new leaf. What do you say — can we cancel any and all recurring meetings and start the year fresh?

If you enjoyed this post, please do hit the 👏 button below. Thanks!

Do you have a story of a meeting gone terribly awry? Or a time when you put your foot down on recurring meetings? We’re collecting your funniest, most memorable, and most cringeworthy meeting stories for an upcoming episode of our podcast, Rework. (If you found a way to make meetings less terrible at your business, we want to hear about that too!) Drop us a line at hello@rework.fm or leave us a voicemail at (708) 628–7850. We look forward to hearing from you!

A Kotlin long-term update: calm, peaceful, and productive


It’s kind of hard to believe, but we’ve been writing Kotlin at Basecamp for 20 months now! And with the first ever KotlinConf starting tomorrow, it felt like a good time to reflect on my time with Kotlin.

When I first started off with Kotlin, I was a bit…excitable. I was blown away by all the incredible things it could do. Compared to Java, it made my life so much easier and I was just much happier working with it. I was so excited to be learning this shiny new tech that I would tell anyone that would listen about all its wonders.

Now, almost two years in, things are different — in a good way.

The big thing is that I’m (mostly) past the initial “holy shit this is awesome” moments of discovery when you first come over from Java — finding out about all those crazy things you can’t do in Java, all the fantastic niceties that become your favorites, and all the little things that save you tons of time. Of course I’m still learning new stuff regularly, but for the most part I’m not running into any huge surprises day to day.

And so from that perspective Kotlin has become, well…uneventful. Wonderfully, lovably uneventful!

At its best Kotlin is extraordinarily reliable, unfussy, and pragmatic.

And while those words might not generate feelings of uncontainable excitement like I experienced at first, they paint an important picture of how awesome Kotlin is, deep down. They’re the things that really matter in a calm (and consequently a productive) work environment.

It’s awesome that the language is rock solid stable after upgrades. It’s awesome that every feature has been thoughtfully considered and prioritized against practical, real-world uses. It’s awesome that JetBrains dedicated 5+ years to get to a incredibly stable 1.0.

And it’s awesome that once you get the hang of it, Kotlin simply gets out of your way so you can get shit done, fast.

At this point in my Kotlin journey, my daily workflow is calm, peaceful, and productive because it’s uneventful. I may not be shout-from-the-rooftops excited about every little Kotlin feature anymore, but that’s OK. What really matters most to me is that Kotlin is a rock solid, stable foundation for my work now and in the future. And that’s worth a lot when shipping good work is the one true reliable measure of success.

Past and present aside, the future is bright too. The language is progressing at a fast clip (coroutines!), and the tooling around it is getting better every day. And perhaps most importantly, community involvement — blog posts, conference talks, Stack Overflow answers, and libraries — continues to expand rapidly too. These are exciting times!

I’ve had so much fun over the past couple of years building Android apps, and Kotlin’s been a big part of that. The progression from initial excitement to calm productivity to looking ahead at its bright future has been an absolute blast. I cannot wait to see what’s in store for us at KotlinConf and beyond!


If you enjoyed this post, 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). Check it out!

Programming languages aren’t a zero sum game


Stop me if you’ve heard these before when people get to talking about programming languages…

“These features are copied this from <superior language>.”

“Nothing new here. <superior language> has done this for years.”

“This language has nothing on <superior language>, but nobody realizes it.”

<superior language> does the same thing, but better.”

I bring it up because I’ve been reading and writing a lot about Kotlin lately. And invariably someone posts a snarky comment like one those above, carrying with it a clear innuendo: my preferred programming language is better than yours.

And every time I see those I leave with the same reaction. Who gives a shit?

Now I’m not talking about people who are having constructive conversations or even just poking fun. Hell, I may have been known to take a jab at Java every once in a while. 👊

I’m talking about a subset of programmers who treat languages like it’s a zero sum game — that for one language to succeed, another (or all others) must fail. It’s like they’re on some strange crusade to prove how they were first and best at everything.

But why does it matter if a language takes the best ideas from another language and implements them? Why does it matter if another language had some feature for years and your favorite just got it? What the hell does “better” even mean when everyone has different preferences and styles?

To me programming languages are simply about doing good work, building success, and if you’re lucky, finding happiness. Many people have achieved those with Ruby, Swift, Javascript, Java, C#, Python, Go, and dozens of other languages.

I’ve been lucky enough to find that with Kotlin. It makes my work genuinely enjoyable. I find it fun and exciting to work with, and that makes me happy. But I’m no programming linguist — for all I know, every other programming language is technically “superior” to Kotlin.

But who cares? There can be many different languages that make many different people happy in many different ways. If I’m happy and having fun with a language, why do others feel the need to shit on it? Are we so insecure and unhappy that we need to tear down another language to make our favorite look better? It’s a negative, petty stance to take that has a disheartening effect on others.

Just because a language doesn’t do something brand new conceptually doesn’t mean it shouldn’t exist. If a language takes ideas and inspiration from another language, that’s a wonderful compliment to the earlier architects. And if your favorite language is “better” than mine, believe it or not, I’m super happy for you — it’s awesome that you’ve found something great!

Programming can be hard. Finding joy in work can be hard. If people can achieve success and find joy in any programming language, that’s a wonderful thing. Why not celebrate every language that can help people achieve great things (especially their own happiness!) instead of making everything a showdown?

If you really believe in your favorite programming language, focus on its merits, not the demerits of others. Avoid the temptation to make snarky comments or tear down another language. Instead, keep it positive. Spread the word on why your language is awesome. Compare and contrast fairly. Have strong opinions and challenge each other respectfully.

Trust me, there’s plenty of room for all our favorite programming languages — even Java. 😜


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!

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!

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: