There are a number of posts and videos that claim you shouldn’t ever say “I’ve never done that” in an interview. And I get the sentiment – you want to project confidence and demonstrate a positive attitude.

But the problem with these posts is that they declare these as absolute truths with zero nuance. They post a pithy 30 second video and frame it as “Don’t say this, say this instead” and then tell you a one liner of corporate double talk you can use to claim you have similar experience. But what if you actually don’t?

There’s an extremely fine line between projecting confidence and using corporate jargon to make yourself sound more experienced than you are, and any decent interviewer will see right through it. They’ll take it as a cue to drill down further, and then when you fumble the more in-depth questions, you’re cooked.

So yes, be confident, be enthusiastic, showcase your skills, sell your fresh perspective, and show that you’re willing to learn. Of course do all those things.

But it’s also OK to be vulnerable and honest and say you haven’t done something before. The key is to not just leave it at that. Proactively take it to the next step so they don’t have to draw it out of you – tell them exactly how you would handle that situation and show you’ve put thought and effort into the role.

Show them that it’s not always about having done everything before, but that you have the potential to do it now, and do it well. ♥️

If, in an engineering manager interview, you ask me to do anything with a binary tree I’ll probably fail it on the spot.

I didn’t graduate with a CS degree and I’ve never been all that interested in the low-level mechanics of programming or languages. But I do enjoy building things and am thankful for all the frameworks, standard libs, and abstractions built on top of languages that exist to make building apps pleasant.

My entire career has been building products and figuring things out as I go. Over time I’ve built up my skills through experimentation and learning from folks who are better than me in practical, real world situations.

In my 20+ years, I don’t think I’ve ever once had to reverse a binary tree or write an extremely complex algorithm, much less have to do it conversationally or on a whiteboard. If I did, it was by accident or because an actual feature required it. But I never sat around and wrote theoretical code with no implementation need. Maybe I’m just lucky or maybe the things I’ve worked on haven’t been terribly complex, but it’s the truth.

I get that companies need weed out questions and some standard of measurement for technical competency, but I firmly believe that conceptual, low-level programming questions are never going to be a valid measure of a good engineer much less a good engineering manager.

I’m a big, big believer in the four day work week. I’ve been lucky enough to have brief periods with it (a few months at a time), and it’s honestly life changing.

Traditional thinking is that because employees have fewer hours to work that they’ll get less done, but it’s just not true. In reality what happens is that you’re laser focused on what you have to get done. You’re incentivized by the extra day off that awaits you – you wander less during the day and knock stuff out at an efficient pace. And because know you have an extra day off, you offload personal stuff to that day instead of interspersing it throughout the work week.

On top of that, you end the week in a giddy mood. Seriously. It’s hard to describe, but knowing that you have three straight days off completely changes your mindset and allows you to truly disconnect from work. Think about the last three days weekend you had – remember how good that felt compared to a normal weekend? You feel freer and lighter, with more time to concentrate on yourself and your family, not work. Now imagine having that every week.

And ultimately what’s good for employees is good for companies too. Employees are happier, less prone to burnout, resign at a lower rate, and simply do better work. For companies that all translates to higher productivity, better outcomes, and a major new incentive to help with recruiting and retaining talent that most places can’t match. Literally everyone wins.

If you want to be a truly progressive company and are looking for a competitive advantage on recruiting and retaining talent, it’s seriously worth a look.

tl;dr: It works like email, and your posts will have a much wider audience over time.

Audience / Purpose

This is a simplified primer for normals to hopefully convince y’all to use federation from Threads, so I’m going to be generalizing and glazing over details. Nerds, don’t @ me about the technical details of how federation works, that’s not the point.

The Basics

By default, your posts on Threads can only be read on one place – threads.net (or the official app). All your posts live on Meta’s servers and all your readers must go there. That’s OK, but you could also reach a much wider audience.

It’s an imperfect comparison, but the best corollary is probably email. Imagine if Gmail users could only email other Gmail users, and they all had to go to gmail.com to read emails. That’s more or less what’s happening with your Threads account. You can reach everyone on threads.net, but you can’t reach anyone else.

Of course that’s not how email works, and you can send an email from Gmail to any other email server in the world. That’s because they use shared protocols that allows any email service to talk to any other email service. They are “federated” (this is the key term to remember, which basically means different servers can join together to build one giant network).

The cool thing is that your Threads account can do the same thing, though it’s turned off by default. Instead of just posting to readers on threads.net, you can post to thousands of other servers willing and ready to accept your posts. All you have to do is flip a switch and your account will be “federated”, similar to the email example. You can also turn off federation later if you find it’s not for you.

Why this is a good thing

The main reason this is good for you as a poster is that it makes communicating with a wider audience much easier. Thousands of servers and users are waiting to read your posts, they just can’t get to them conveniently!

Your posts will go out to anyone who subscribes to you, no matter what server they use. They can read, respond, favorite, or boost your post just like they could if they were on threads.net. It exposes your content out to anyone and everyone, which is an easy way to build an audience and following.

As a consumer/reader (me), it frees me up from using threads.net and I can use whatever server and app I want to read your posts. I’m not subject to the Threads algorithm, I’m not forced to use a specific app, and I can make sure I see all your posts because I control my own feed.

It’s basically a win-win for both sides.

Why this might not be for you

There are some caveats to consider with federating your posts out:

• The biggest thing is just like email, once a post is sent it’s out there for good. The server that receives your post will have a copy of the content, just like an email. And just like email, you can’t recall, edit, or delete it once it’s been received. (Technically Threads will request a deletion, but the server doesn’t have to comply). You can turn off federation at any time to prevent future posts from going out, but any previous posts stay out there. It’s not that much different than someone screenshotting your Threads post and passing it around, but copies being “out there” is something you should be aware of.
• Threads’ moderation tools for engagement – limiting replies, hiding replies, or blocking users – don’t work on users or actions outside of Threads. So if you have a particularly popular post, while you can continue to moderate that post on Threads, you can’t control who replies from servers outside of Threads. This could be problematic and a potential source for harassment, so it’s something to be aware of as a tradeoff of having a wider audience. It may or may not be worth it to you.
• While people can favorite, respond, and boost your post from any server, as of today Threads’ ability to respond back is limited so it’s a little clunky. This will improve over time as the Threads team builds out full federation functionality.
• If you’re in the European Region as defined by Threads, you can’t use federation.

How to enable federation on your Threads account

Full official instructions here, but in a nutshell:

1. Go to settings (mobile or web, both have it)
2. Go to Account
3. Go to Fediverse sharing BETA
4. Click through the instructional prompts
5. Click Turn on sharing

Wrap up

I hope you’ll consider enabling federation on your Threads account. It really is a win-win in most situations, especially for people who want to read and interact with your content but don’t want to get involved with Threads/Meta. If you have any questions, hit me up on Threads (irony) or Mastodon.

References

• Threads Fediverse official documentation
• Threads official instructions to enable Federation

If you’re anything like me, you prefer to have complete control over your photo library files. But backing up those files on a rolling, ongoing basis has long been a pretty disjointed and painful process. How do you get photos and videos off your phone on a regular basis, keep local copies, and upload them to the cloud without using a proprietary app or service?

Every combination of software I’ve tried in the past hasn’t quite worked as smoothly as I’d hoped. But — famous last words — I may have landed on a decent solution!

For those of you who firmly believe that iCloud Photos, Google Photos, Google Drive, or Dropbox meets your backup needs, then this post is not for you (and that’s OK).

But for some folks there are many good reasons that those services might not be a good fit — you don’t want to pay the tech giants even more money, you don’t trust them with your most treasured data, you have privacy concerns, they don’t offer enough storage, you don’t want to be at the whim of their pricing changes, you have concerns about the longevity of the company or service, you don’t want to lock into a specific app/platform, there’s no good way to restore your data, or any number of other reasons.

So after much experimentation and research I rolled this simple solution.

It’s cross platform (Android, iOS, Mac, Windows), doesn’t require a ton of additional expensive hardware or software (though you do need enough local storage capacity to hold your files), its monthly service fees are as cheap or cheaper than the major services (and doesn’t feed the tech giants), and doesn’t require me to do anything with the command line (I get enough of that during work hours).

Required hardware

A “server” — any computer running MacOS or Windows. Very little horsepower required.

Required software

• The PhotoSync server (free)
• The PhotoSync Android or iOS client ($6.50 a year)
• Cloud backup software of your choice for your server — I use Arq and can recommend it, but there are many choices out there.

Optional hardware

A boatload of storage connected to your server since you will be keeping a local copy of all your files.

Setup

I’m not going to run through the whole process step by step and rob you of that fun. But the basic gist is:

• Install everything.
• Pick a disk location on your server (or external drive) and point the PhotoSync server app to that directory
• Setup your PhotoSync Android or iOS client with a connection to your server. It should auto detect the server or you can directly hook to an IP.
• Setup an automatic job on your PhotoSync Android or iOS client to sync on whatever schedule you want. I have mine setup to transfer each night while I’m asleep, then delete those files from my phone. Setup a schedule on your cloud backup software to back up those local photo/video files.

That’s it! Those are just the broad strokes, but there’s really not much more to it, and it’s all point and click.

In the end your phone will automatically unload/sync your photos and videos on a predefined schedule, you’ll have a complete local copy of every photo and video file, they will be completely free from lock in to Apple or Google etc., and everything will be automatically backed up to the cloud.

If you’re writing anything of consequence, the sad reality is that you’re probably going to get shit on. Whether it’s a short blog post or a 10,000 word essay, someone will find a way to object to your ideas or question your motives in a not-so-friendly way, no matter what you intended. I know from both giving and receiving said shit.

The best thing to do? Just. Keep. Writing.

Spending time writing about things you care about is a net good thing, and you’re never going to be able to control what others think. If you’ve said anything remotely compelling, there’s a very good chance someone will misinterpret what you meant (or twist your words on purpose).

But it’s much better to have strong opinions about the things you care about than watering down your writing in an attempt to please as many people as possible. Tiptoeing around the edges won’t get people thinking, but opinionated writing can.

Now of course this doesn’t mean you aren’t responsible for what you write — you should still do your best to be considerate, thoughtful, respectful, and thorough. But you can do that in a way that’s also opinionated, convincing, and confident.

Bottom line — fighting off your inner critic before publishing is hard enough, much less trying to fight off every critic in the world in advance. Sometimes you just gotta hit send and let it fly.

Jeff Bezos is generally one those people whose ideas and thinking make a lot of sense to me. He’s a billionaire so he’s always going to be an out of touch weirdo, but some of his ideas click with me.

So when I recently came across a fantastic interview with Jeff Bezos, I jumped right in. The entire interview is great and I really think watching the whole thing is worth your time. But there was one section that really stuck out to me: his prioritization of sleep, calm, and quality.

Here’s the basic gist:

• 8 hours of sleep a night. He goes to bed early and wakes up early. He thinks better, has more energy, and his mood is better when he gets the right amount of sleep, all of which contribute to making him an effective decision maker. The opposite can hold true too — being tired or grouchy can lead to bad decisions.
• Puttering (yes, this is an official Bezos term). Bezos’ morning routine isn’t manic or hectic, it’s quite the opposite — he putters around, taking his time and slowly ramping up. This is his time to read the paper, have coffee, and eat breakfast with his kids. It’s really important to him that he have a slow, calm start to the day, which is also why he insists on no meetings before 10 a.m.
• High quality decision making. He likes to do his “high IQ” meetings before lunch because that’s when he’s sharpest, and he knows by 5pm he’ll be wiped. Anything that’s important that pushes late into the day gets rescheduled for 10 a.m. the next day. He recognizes that he “only” needs to make a few key decisions a day, not thousands of small ones. If he can make three high quality decisions a day, that’s plenty good.

For all we hear about how awesome it is that people are constantly “hustling”, working 20 hour days, sending 50 emails from bed, and squeezing every minute of the day for max productivity, we have in front of us Jeff Bezos — one of the most successful business people in the world — puttering.

Sleep. Calm. Prioritizing. Quality over quantity. Recognizing limits. These are the kinds of principles that have made him a success in the long run.

I know this feeling isn’t unique. In fact you might be feeling today how I did years ago — coming home from work tired, uninspired, unhappy, and even angry. It’s not a good look.

But change is within your grasp. It won’t be easy, but you can be damn sure it’ll be worth it. I speak from personal experience.

When I eventually reached my job-hate breaking point, the first order of business was to quit said job. I have to admit it was kind of exciting and liberating. But it was also intensely scary. I was walking away from a good job working at a stable, respected company — a company where I could’ve had a prosperous (albeit miserable) career. I voluntarily went from having a very generous salary to one of literally $0.

Oh and by the way, as I took on this adventure of rebuilding my career I still had some huge responsibilities back at home: namely my twin infant sons and all the adulting required to keep them happy and healthy. So you can imagine the unsettling feeling of self doubt I felt early on. More than once I wondered, “Did I make a huge mistake??”

But ultimately I realized what scared me the most was the long-term prospects of doing nothing — not just being unhappy for one year, but allowing that misery to fester over three, five or even ten years. We spend an inordinate amount of our life at work — somewhere between 20–30% of our waking hours. How could I standby and let all those hours be filled with misery, only to bring that misery home with me every day to my family? No, if I was going to spend that much of my life doing something, those hours better be happy ones.

So I pushed aside that doubt, put my head down and got to work. I joined The Starter League and got my brain and attitude in the right space. I was learning tons and meeting great people. I felt professionally energized and excited for the first time in a long time. I finished up my classes there and soon after I mustered up all my courage and took a long shot: I reached out to Jason Fried to ask if there was anything I could help with. We got to talking, and a few months later he invited me to join 37signals.

What an unbelievable turn of events. Going from the the worst job I’d ever had to working at 37signals wasn’t anything I’d ever expected. Fast forward 4+ years and I’m doing the best work of my career and I’ve never been happier at a job.

Now look, I’m not recounting this story as some kind of humble brag or to make myself look like hot shit. Anybody who knows me I am the furthest thing from hot shit. I bring it up because I hope it shows the kinds of crazy, unexpected, wonderful things that can happen to anyone’s career if you take a chance. I’m not special — all I did was acknowledge my unhappiness, embrace the uneasiness of change, and got to work. Yes, there was some luck involved, but even if I didn’t land at my first choice of jobs, I still would’ve been happier and better off for having tried.

Of course it’s really important to remember that everyone’s situation is different, so don’t take my story as gospel. I was fortunate to be in a position to take a chance like I did. I had years of work experience to help me recognize when to get out of an ugly situation. We were financially secure — it was a moderate risk, but I never put ourselves in any kind of precarious lose-it-all situation. And most importantly I had wonderful, incredibly supportive people around me — family, friends, teachers, colleagues, and so many others. I recognize not everyone gets the deck stacked in their favor like this.

It’s also worth noting that life wasn’t all roses and sunshine afterwards either. It took a long while to get everything back up to speed — to rebuild our finances, to re-establish my career direction, and even smooth out our family life and routine. But in the end was it worth it? Absolutely, positively, hell yes.

If you hate your job, I’d really encourage you to consider taking action. But first you’ll need to evaluate your career situation, then decide what’s best for you and your family, now and in the future. It’s natural (and healthy) to feel scared, worried, and hesitant. Take your time, consider deeply, and take action when it’s right for you. But no matter what your situation is, if you’re in a rough patch in your career I hope that my story gives you a spark of hope, something you can hang onto — the belief that better times await you when you’re ready.

There’s something great out there for you and your career. You absolutely deserve the happiness it can bring — go on and get it.

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 cares??

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.

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.✊

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.

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.

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. 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.

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.

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 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.

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

Who, specifically, am I writing this for?

• 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…

• I’m writing this for Ruby programmers
• 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!

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!

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.

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 ¯_(ツ)_/¯.

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.

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.

Being pragmatic is engrained in me. I’m at my best being practical and boring.

Here’s the problem — experience has taught me that you’ll never do your best work through sheer pragmatism alone. While I’m good at weighing options and making decisions, I’m not that visionary who can conceptualize grand ideas. While planning comes very naturally to me, I find it difficult to inspire others. And though I’m good at shipping, I often do so using following established conventions.

So while the incremental, risk-averse nature of being pragmatic can be good for many aspects day to day of work, it’s not everything.

What you’re good at and what’s good for you aren’t always the same thing.

To make long-term, deep progress in your professional growth, you need to think big sometimes. You need to try things that don’t have predictable outcomes. You need ideas and ways of thinking that inspire innovation. You need to stretch way beyond your comfort zone.

But as a pragmatist, how can you do all this when it’s so foreign to you?

Surround yourself with the “wilder” folks

Look for opportunities to work with people who are the opposite of you — the dreamers, big thinkers, and contrarians. These will be the people who will push you toward bigger and better things.

Yes, it’s going to be very hard and uncomfortable for you. You’re going to feel like you’re on a bizarro planet where everything is backwards and nobody thinks like you. This is a generally good thing.

Having people challenge your baby-steps thinking with big-leaps thinking is a good thing. Not understanding what the hell one of your colleagues is thinking (at first) is a good thing. Having healthy discourse around big ideas is a good thing. And shaking hands and finding compromise is a great thing.

Their thinking will seem far out there and executing their ideas will seem impossible. But in end you’ll pull it off — not in spite of you, but because of you. You’ll be better in every way because you stretched well outside your comfort zone. And really, what’s more rewarding for a pragmatist than shipping something you didn’t think was possible?

According to Marissa Mayer, long hours and weekend work (in person) will lead to success.

Yesterday I read this article about Marissa Mayer. This quote infuriated me (emphasis mine):

My husband [the venture capital investor Zachary Bogue] runs a co-working office in San Francisco…And if you go in on a Saturday afternoon, I can tell you which startups will succeed, without even knowing what they do. Being there on the weekend is a huge indicator of success, mostly because these companies just don’t happen. They happen because of really hard work.

I read my fair share about the tech world. I haven’t encountered statements this utterly arrogant and silly in a while.

Let’s break down that quote. She’s saying…

• Weekend work is a leading indicator of being a successful company
• She can predict success based on the people who are physically in the office on a weekend
• She can predict success without knowing anything about a company’s business

What in the actual fuck?

This idea that someone could “tell you which startups will succeed, without even knowing what they do” is so comically arrogant, I honestly can’t tell if she was being serious.

I guess this kind of thinking from Mayer shouldn’t be all that surprising.

After all she’s the CEO who banned remote working. To her, working together in person, in the office, is the only way to do great work.

As a refresher, here’s a snippet of the leaked memo Yahoo! sent to its employees:

To become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices. Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings. Speed and quality are often sacrificed when we work from home. We need to be one Yahoo!, and that starts with physically being together.

Because let’s not forget — being physically present means you are doing your best work! Speed and quality can only happen in person! Never mind that many other companies have been successful with remote teams.

So maybe that helps explain why Mayer believes she can walk into an office on a Saturday, survey who’s there in person, and can declare the winners.

Because to her, if you’re not there physically, you’ve already failed.

In the same article, Mayer talks about her experience at Google:

The other piece that gets overlooked in the Google story is the value of hard work….The actual experience was more like, “Could you work 130 hours in a week?” The answer is yes, if you’re strategic about when you sleep, when you shower, and how often you go to the bathroom…For my first five years, I did at least one all-nighter a week, except when I was on vacation — and the vacations were few and far between.

While that might sound crazy to most of us, I don’t really have a problem with it.

She was making a decision for herself. She decided to work long hours, pull all nighters, and eschew vacations. That’s her call. ¯_(ツ)_/¯

But it’s not OK to imply that kind of work/life imbalance is a key to success for others.

Hey, if someone wants to work themselves into the ground, that’s up to them.

But spreading the message that hard work and success can only be achieved through long hours and weekend work — that’s not OK. It’s patently false, and it’s already far too pervasive in our industry.

Look, I get it — by every objective measure of Ha Ha! Business Success™(financial, title, industry stature), Mayer is insanely successful. She has achieved far more in her professional career than I ever will.

But I also don’t work weekends. I don’t work 130 hours a week. I don’t commute to an office.

My measures of success are way different. I goof off with my kids a lot. I read. I watch movies. I eat donuts and pizza. I occasionally travel. I sleep 8 hours a night. I’m rarely stressed. I revel in being boring and old.

And I do that all while genuinely enjoying my job and the people I work with (who I rarely see in person).

In Mayer’s world, I could never be a success.

I’ve never been so fucking happy to be a failure.

Life as an impatient programmer

I have to admit — patience has never been one of my strengths. My parents tell me over and over, “Try to be more patient!”

It’s never quite stuck.

I get why they harp on me. Impatience is by definition pretty negative sounding:

having or showing a tendency to be quickly irritated or provoked.

But is being impatient always such a bad thing? Consider the alternate definition:

restlessly eager

“Restlessly eager”. I love that!

Said a different way, it means you’re enthusiastic, dedicated, and ambitious. You just have a little trouble directing all that energy.

But what if you could harness all that enthusiasm?

The positive results of impatience

It may sound strange, but being impatient has helped shape my programming career in a positive way.

If you’re like me, being impatient can help you become…

• A better programmer. You won’t wait for someone else to fix a bug or an annoyance. You’ll create that app you need because it doesn’t exist yet. You’ll build systems and shortcuts for your daily work. This process of constantly building, learning, and tweaking keeps you sharp.
• A well rounded professional. You won’t stay in dead end jobs that don’t challenge you. You’ll want to learn new things. You’ll want to improve stuff as fast as you can. This builds an arsenal of rich experiences that you can carry forward forever.
• A better student. You’ll be an efficient learner. You’ll learn the stuff that matters and ignore the fluff. You’ll develop systems to learn faster and smarter. You’ll focus and work hard because there’s nothing worse than wasting time.
• A better teacher. You’ll have spent so much time learning, you’ll already be a great teacher. You know what matters and what doesn’t. You’ve experienced success and failure in a wide variety of situations. You’ll want to pass on these experiences onto others.

Hey, being impatient doesn’t sound so bad after all!

Harness your impatience

I know, I’m making it sound like being impatient is all roses and it’s the key to success.

Of course it’s not that simple. Harnessing your impatience into positive energy is easier said than done. I’ve fucked up plenty because of my impatience.

Over the years I’ve found that, like many things, balance is the key. Not everything can be the ire of your impatience.

Try to pick your battles. Try not to get worked up about minor bullshit. Try to direct that energy at the important stuff.

Ask yourself lots of questions. When do you get impatient? When did you turn that energy into a success? When did you fail? What’s worth spending that valuable energy on? Who on your team can help keep you in check?

If you can answer those questions, you’ll be on your way toward harnessing your impatience.

You’re lucky. Not everyone is blessed with impatience. It’s a powerful motivator and a great source of energy. Use it to your advantage!

If you liked this article, I’d really appreciate if you click the heart button down below. Thank you!

We’ve been hard at work making Basecamp 3 and its Android app the best way to run your projects and small business. Won’t you give them a try?

When a teammate asks me a question, one of my favorite responses is “It’s your call.” It’s such a simple yet powerful phrase. In just a few words it conveys…

Trust—Confidence—Respect—Autonomy—Ownership—Empowerment— Responsibility—Decisiveness

How can such a simple phrase mean so much? Take this common scenario — a team discussing what to work on next. Here’s one version of that conversation:

Julie: What should I work on next?

Shelley: How about a native homescreen?

Melissa: I’ve always wanted breadcrumb navigation!

Sara: Another option would be to squash some 🐛

Erica: File upload feature would be cool

Now there’s absolutely nothing wrong with a back and forth like this. Julie has opened the door for feedback, and the feedback provided makes total sense. But imagine the same opening line with a single response:

Julie: What should I work on next?

Shelley: It’s your call 😀

Immediately the whole tone of the conversation has changed for the better. Instead of asking for permission and being given specific directions, Julie has been empowered to make the decision herself. She now has complete ownership. She’s free to explore and make her own choices. She’ll assess all the open tasks. She’ll drum up her own new ideas. She’ll decide what’s next based on her own criteria of importance.

More importantly the team has expressed sincere trust, confidence, and respect in her and her abilities to do everything. They’ve said “whatever you decide is cool with us.” Full autonomy like this has significant long-term benefits to teams —no managers, increased motivation, time saved, sharper assessments, faster decisions, happier people, improved independent learning, better teamwork and so much more.

All of that accomplished by just saying a simple phrase.

When it comes to software development, conversational opportunities like this come up pretty frequently. Keep an eye out for questions about:

• What to work on next
• How to implement a feature
• What tools, APIs, or libraries to use
• How to manage/keep track of work

Of course when you’re asked for your opinion, you can certainly give it — you don’t want to leave people completely hanging. But before you do that, consider challenging the person asking the question by simply saying “It’s your call.” You’ll be pleasantly surprised by the outcome, and the long-term benefits are well worth it.

For a while now, interest in programming has been skyrocketing. So there are a lot of beginners out there starting their careers — and that’s a wonderful thing!

If you’re one of those beginners, eventually you may start thinking about the long-term prospects of your new skills: How do I take a new skill like programming, grow it, shape it, and tune it over time so I can achieve longevity in the industry?

I asked myself that same question early on in my career. Now, a mere 15 years into it, I’m hoping I can give you some answers.

Below are a few general strategies that have helped me become (and stay) a successful programmer over the long haul.

1. I try to surround myself with programmers who are way better than me

Over the course of my career, I’ve always tried to pick work where the people I’d be working with are exceptionally talented. To put it more bluntly, I try to put myself in the company of programmers who were way better than me.

This is crucial, because the best way to improve (at anything) is to learn from people better than you. It might be a nice ego boost if you know more than everyone around you, but you’re otherwise just flat lining your actual progress.

When I’m around these talented programmers, I constantly keep my eyes and ears open for nuggets of wisdom. I watch how my fellow programmers carry themselves, how they breakdown a problem, how they talk to each other. I look at their code for patterns and style choices that I can mimic. I remind myself to talk less and to listen more.

Unless you’re the Michael Jordan of your respective field, there should always be someone better than you — this is a good thing!

You have nothing to lose and everything to gain in such a situation. Take advantage of it.

2. I occasionally leave my comfort zone

I’ve found it beneficial to leave my programming comfort zone once in a while. It helps me think differently by challenging a bunch of established ideas I already have.

For sure, you don’t want to do this constantly because it can be hard to get into a rhythm with your normal area of work. But in moderation it can really open your mind to new ways of thinking.

My comfort zone is Java and Android. But over the last year, I’ve taken on stuff well outside that zone. But what’s important to remember is that none of this stuff was particularly easy or comfortable for me. In fact much of it was downright uncomfortable, nerve-wracking, and filled with doubt. At times I literally felt like I had no idea what I was doing.

But as challenging as they were, I did them anyway because I knew how valuable those experiences would be . They gave me the opportunity to work with a variety of the programmers, let me reacquaint myself with technologies I’d fallen behind with, and let me learn brand new stuff that few others in the company got to. All of that made me a better programmer.

So find a programming task that takes you out of your comfort zone and make it your next project. Then watch it pay off in spades.

3. I value being independent

When you’re just starting out, you’re going to have a lot of questions. That’s OK! What’s most important is how you choose to find the answers to your questions.

One philosophy that’s always served me well is to be independent. Usually this means that I’ll try to do most things myself first, and only when I really get stuck, I’ll ask for help.

Being independent has tons of benefits, but to name just a few…

• You learn how to be resourceful. Finding answers may just be one Google result away, or it might take a dozen different queries. You might have to patch together 5 different solutions that you’ve found to work together. Who knows. Finding the answers you need on your own is a skill that’ll serve you well for years.
• You earn respect by being courteous of other people’s time and work. When you prioritize your independence, working with other programmers is easier. They’ll appreciate that you’ve done a lot on your own and have taken it as far as you can before asking for help. By respecting other people’s time and work, you’ll earn respect back. And mutual respect is the cornerstone for trust and solid teamwork.
• You start developing your creativity. When you need to come up with answers, you’ll find yourself coming up with creative solutions you hadn’t considered. You’ll try things that seem crazy and out of the realm of possibility. Some will work and some won’t, but you’ll begin to develop a palette of creative solutions that you can draw from many times down the road.

The next time you have a burning question, see if you can answer it yourself, even if it takes a little longer than asking someone. It’ll be worth it.

Becoming a successful programmer is, like anything worthwhile, hard work. But these strategies have always served me well in the long run. I hope they can help you get to where you want to be, too.

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

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

What made this vacation truly wonderful wasn’t just the fun activities and family, but that I got to enjoy every second of it without a single bit of stress from work. Work was the furthest thing from my mind. I was focused solely on relaxing, recharging, and spending time with my family.

The sad state of today’s “vacations”

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

Sadly — no, not really.

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

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

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

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

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

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

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

So, to recap:

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

Wow, American vacations sound fucking horrible!

Take control of your vacation

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

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

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

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

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

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

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

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

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

Building companies that respect vacations

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

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

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

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

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

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

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

Some notes about the code examples:

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

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

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

One of my absolute favorites.

// Java
if (firstName.equals("Dan")) {
    person.setTeam(programmers);
} else if (lastName.equals("Dihiansan")) {
    person.setTeam(designers);
} else {
    person.setTeam(others);
}

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

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

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

// Java
switch (firstName) {
    case "Dan": person.setTeam(programmers)
        break;
    case "Julie": person.setTeam(programmers)
        break;
    case "Andrew": person.setTeam(designers)
        break;
    default:
        person.setTeam(others)
}

// Kotlin
when (firstName) {
    "Dan", "Julie" -> person.team = programmers
    "Andrew"      -> person.team = designers
    else         -> person.team = others
}

I swear, this alone is worth writing Kotlin.

2. Beautifying even the ugliest click handlers

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

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

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

// Kotlin
view.onClick {
    println("WAT")
}

3. No more view binding

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

// Java
EditText composer = findViewById(R.id.composer);
composer.setText("Allo!");

// Kotlin
view.composer.text = "Allo!"

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

4. Functions in one line

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

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

// Java
public String fullName() {
    return getFirstName() + " " + getLastName();
}

// Kotlin
fun fullName() = "${firstName} ${lastName}"

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

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

5. Convenience methods built on top of familiar objects

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

Take String comparisons for example:

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

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

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

6. Reducing the need forif (whatever != null)

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

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

// Java
if (message != null) {
    System.out.println(message)
}

// Kotlin
message?.let { println(it) }

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

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

7. The Elvis operator

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

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

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

// Java
if (people == null) {
    people = new ArrayList();
}
return people;

// Kotlin
return people ?: emptyArrayList()

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

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

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