This post by Molly Graham is excellent. I’ve never really liked the blindly-follow vibe of “disagree and commit”. The original intent was to enable decision making and drive alignment, and while that’s noble, enough bad actors have abused it to the point that It’s become a buzzword excuse they can use to justify squashing discussion and getting their way. I’ve definitely seen it happen.

Molly’s take is much smarter, far more nuanced, and as a leader, far more achievable. You don’t have to feel like you’re selling something you don’t believe in, but rather can acknowledge that the team is making an educated guess that will be assessed and reviewed afterwards. That builds trust, helps everyone learn, and is much easier to get behind. So, so much better. 👏

Kind of shocking to me that the majority of job postings still list number of years as a requirement.

First and most importantly, this shows an (unintentional?) implicit bias against underrepresented groups, cutting out those with non-linear career paths and those who have faced systematic barriers (women, people of color, minorities). Diversity is so critical for a team’s overall success, as any good product should have representation of its customer base.

Secondly, years of experience is in no way a proxy for competence. Some of the very best people I’ve worked with had a year of experience, and some of the biggest duds were people with dozens of years of experience. Smarts, ambition, and attitude are what matter, not years.

When in doubt, share your professional failures. If you’ve had any level of success in your career, sharing failures shows there’s room for growth for everyone at all levels. Nobody’s perfect and we all struggle at times, so people appreciate and connect with those kinds of experiences far more than some glossy accomplishment.

So share your tough moments and your missteps. Be honest and transparent. It might be hard to do and maybe even a little embarrassing, but that little bit of selflessness is an excellent way to teach and help grow others.

The title says it all – I am so bad at interviewing.

It has nothing to do with my skills, experience, or future promise. It’s just that if you ask me a question and immediately want a response where I have to recall the details of a situation from 2 years ago, it just isn’t going to go well. My brain is not wired to respond immediately – it takes me at least a few minutes (and probably more like ten) to derive a thoughtful, coherent response.

Fair or not, it’s honestly hard to believe that in 2025 interviews still reward those who can think fast on their feet and/or lie/bullshit their way through an answer in the moment – salesperson types, basically. This is how they define “excellent communication skills”.

Given a one hour interview, if you gave me the exact same questions and 90 minutes to write out thoughtful responses, I would crush the interviews. But for the most part, nobody really seems interested in someone who can do the job more slowly but more thoughtfully – they just want that snappy answer to make them feel good about the interview vibes.

I’ve gone through a few rounds of interviews in 2025 and they’ve been a stark reminder that your performance in any given interview is max 50% (arguably less) within your control. The rest is on the interviewer and the company.

Sure, you can control your prep, your stories, and your nerves, but think of all the things you absolutely can’t control with the interviewer: their mood, their professional experience, their communication skills, their interviewing experience/quality, how busy they are that day, how much (or how little) they’ve prepared to speak with you, their biases, and probably a dozen other factors you don’t even know about.

On top of that, think of how much the company controls, in aggregate, beyond the individual interviewer: interview rubrics, how consensus is built, hiring panels/reviews, recruiter screens, hiring manager screens, scheduling/timing, the candidate pipeline, job postings, and of course everyone’s favorite, “culture fit”.

In modern interviewing you have to make it through at least 4-5 of those interviews, each with a different flow, pace, and vibes every single time. No matter how much a company tries to standardize, they can’t standardize human interactions. Every hour is different, and there’s no way that you as a candidate can predict or prepare for it. Honestly, it’s a minor miracle anyone makes it through any company’s interview process to the offer stage.

All that said, I don’t even have a good solution – hiring is very hard and every kind of evaluation (interviews, take home projects, working with a team for a week, fast hire/fast fire, etc.) has their own tradeoffs and none is perfect.

My point is simply that if you’re struggling with interviews, there’s a decent chance that it’s not you. Try to remember how much of the process is out of your control, work hard at the things you can control, and keep your head up. It’s a bummer but some of job hunting is just luck and timing, so I’m rooting for you and hoping that the right fit comes along soon. 💙

I don’t want to minimize the anxiety of being unemployed because it IS extremely stressful, but it’s worth remembering that it also provides some rare short-term life opportunities to recharge. You can take care of yourself by slowing down and spending time doing things you enjoy, to do the things you normally can’t during a typical work day.

For me that means grabbing a long lunch with my partner, hanging with the kids when they get home from school, catching up on TV and books, and taking long walks with my pal Eugene.

So yes, of course, crank on your job hunt, prep for interviews, and use the time for professional growth. But don’t forget to take a little time for yourself to recharge and reconnect with the things you enjoy so you’re in the right frame of mind to tackle the work ahead. ♥️

Two of the biggest career-altering jobs I ever landed were because the hiring manager took a chance on me. I knew I could do those jobs well and had a lot to offer, but from the hiring side there was absolutely some risk.

My work experience has always been weird and non-linear, so I rarely fit well to any given hiring profile. They more or less had to trust their gut and take a leap of faith by hiring me. I’m sure there had to be more obviously qualified candidates.

In both cases, my getting hired worked out, and both sides ultimately benefitted — I did good work for them, they took care of me, and we had fun doing it. And regardless of how those runs may have ended, I still think back fondly at those moments when those folks took a chance on me. I’m probably romanticizing it a bit, but it’s hard not to appreciate what they did for me.

I guess I would just say that if you’re a hiring manager, of course you have to consider all the objective measures — a diverse slate, interview performance, peer feedback, etc. But if you have someone in the running who might be a borderline or non-obvious choice, it might also be worth considering your gut feel. Yeah it comes with some risk, but it could also be great. 💙

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.