Blasphemy? Maybe.

Read on for 2 changes in your meetings to engage and include your remote workers.👇

Meetings are already a waste of time, why wouldn't you want to minimize the time we are all stuck on one?

I've been doing the remote work thing for over a decade. Bear with me on this one.

1. Expect and accept small talk

It's important to remember that remote workers don't have the luxury of water-cooler talk. There's no direct equivalent to chatting with someone in the hall.

Zoom meetings are one of their few human-focused, face-to-face interactions.

Even remote workers need an opportunity for small talk.

To build camaraderie, you need unstructured conversation. By allowing, and expecting, this to occur in your meetings you empower team bonding.

2. When the conversation diverges, give it a chance

And let's not forget the benefits of serendipity.

Sometimes an unexpected topic comes up. With devs, it's usually a bug, feature, or design decision. The original conversation prompted someone to pivot.

Allow that pivot. Let the conversation flow.

This isn't an endorsement for derailing every meeting, dodging the original topics, or dragging things out to the detriment of everyone on the call.

It is a call for intentionality in allowing the team to interact, in a human-centric way.

With their voices, expressions, and emotion. All those things missing from Slack (regardless of how many emojis you use).

TLDR;

1. Expect and accept small talk
2. When the conversation diverges, give it a chance

Making these two changes to your meeting will give your remote workers a chance to bond with the rest of the team.

Don't deny them that.

#devp #remotework #crosspost #ship30for30

Thanks for reading. If you enjoyed the article subscribe via RSS feed or enter your email in the box below 👇

When I'm giving demos to or pairing with other devs, they inevitably ask how I put together my workflows and tooling. It, usually, appears smooth and effective. Everything from mnemonic shortcuts in my terminal to instantly opening the AWS console to the right account. I can thank two habits for building and keeping my workflows going.

1. Keep a Friction List

As I'm working throughout the day, whenever there's a little hiccup or annoyance in my workflow, it goes on the Friction List. My natural inclination (and desire for procrastination) says to stop and fix it immediately. But in the spirit of GTD I send it off to a trusted system, knowing I'll circle back to it eventually.

Here's a small snippet of things currently on it:

• no auto format on save for lua
• ave should default to target1 acct
• fuzzy directory jump history doesn't sync between laptops
• nested cdk dir changes nvim file listing context
• vaulted doesn't support image sharing

Each of these has at one point or another annoyed or impeded my flow. Tiny to significant bits of friction that once removed, give back precious seconds to minutes of my day. Capturing them as they occur is a start, but it isn't enough to stave off the desire to fix them all. For that, I need to...

2. Review and improve for 15 minutes each week

Doing is critical to actually improving.

Each week, 15 minutes of dedicated AM time is spent reviewing the list and making progress on something. It could be a quick new shortcut, or planning out the next feature on a side project.

Any action is fair game, so long as it makes progress on the list.

Now it's your turn. Do you track the friction in your workflow? If not, how do you know what to improve?

This was the Day 24 #ship30for30 #atomicEssay.

#devp #crosspost

Thanks for reading. If you enjoyed the article subscribe via RSS feed or enter your email in the box below 👇

I'm an avid believer in developers always having a side project.

As a dev with ~200 repos on GitHub, many of them private, you could say I've worked on a few. Some big, some small, some were a few days effort and others have been going for years. I keep going for two reasons.

1. You need a safe space to experiment

Under heavy pressure to finish before a deadline is not the time to try out a new framework. Or deploy to a new platform. Or bring in a language you've never used.

But as a dev, you need to explore to improve.

Years ago I used to say the blog is my lightsaber. Something I'd craft myself, test out crazy ideas, and generally a thing for focused play. As the blog has become a commodity, side projects became the perfect opportunity to dabble.

2. There's more opportunities to up-level your skills

Often times as engineers we become known for specific domains or skills. A Golang, Java, Backend, React, Functional, or [fill in the blank] developer. While that's not always a bad thing, we're best served by branching out.

Gaining broader, full-stack experience makes us better at our day to day.

Maybe your place of business is an AWS shop, but you never touch anything cloud related. Why not try deploying your side project to Lambda? Or use a non-relational store like DynamoDB, when your work projects only ever use Postgres.

Each tech stack and new mental model learned in our side projects expands our ability to understand complex systems.

Take advantage of that! Be intentional with your growth. Find something that meets your Rule of 3, and give it a run while scratching your own itch.

Remember, Always Be Coding, even if it is just a toy project.

This was the Day 20 #ship30for30 #atomicEssay.

#crossPost #devp

Thanks for reading. If you enjoyed the article subscribe via RSS feed or enter your email in the box below 👇

The more you track Hacker News and [insert your favorite language / framework] Weekly newsletters, the more overwhelming the sheer amount of new tech seems. This un-ending influx of new tools, libraries, and frameworks leads to a constant need to chase shiny objects, and a time sink that is a huge hit to developer productivity.

There's just too much noise and not enough signal. One of the most important tips I've picked up to help filter the firehose is...

The Rule of 3 (trusted sources)

The “rule” states simply that I won't invest time digging into any new library, framework, or tool until it has naturally surfaced from 3 separate, trusted sources.

Applying this rule eliminates FOMO. With a good set of trusted sources, whether that is from personal twitter lists, blogs, developers you know IRL, or elsewhere, you can feel comfortable passing on the early buzz and let your sources do the first round of filtering. As you curate those sources over time, only the most useful, highest potential items will rise up from the rest of the cruft.

I've used this technique for many years, and each time I teach it to another developer they stop getting caught by the half-baked new toys, instead becoming the dev who always knows when something is worth looking into.

Remember, developer productivity is as much about not wasting time on the wrong things as it is efficiently doing the right things.

Think about what sources you trust to help apply the Rule of 3 and respond with a few in the twitter thread.

This #ship30for30 #atomicEssay was shipped with this twitter thread:

Let's get started with one of my favorite topics: developer productivity. Today's essay is all about filtering out the noise... pic.twitter.com/eUdaodBszl

— bkono ? (@bkono101010) October 16, 2022

#ship30for30 #devp

Thanks for reading. If you enjoyed the article subscribe via RSS feed or enter your email in the box below 👇