Clean-up Your Inbox With Retention Policies

I get a lot of email, and I can’t always keep up with it. My first line of defense is rules. Rules help me filter out a lot of noise and tag messages in meaningful ways, but I find that if I move things out of my inbox, they slip into the out-of-sight, out-of-mind void that is everywhere-except-my-inbox.

I get a lot of notifications from Azure DevOps for things like pull request reviews. These are things that I want to know about, but it’s not something I’m realistically going to get back to if I put it off for a few days. I wanted to create a rule that was something like “delete messages that match [whatever criteria] that are more than [x] days old,” but I couldn’t find a way to do it other than by moving the messages away from my inbox to a folder with a custom archiving policy (i.e. into the void where I won’t see them) or by doing some custom development.

But then I found them: retention policies.

Retention policies control how long messages messages are kept, and they’re perfect for these sorts of highly-relevant-but-only-for-a-short-while messages. You apply the policy to a message, which can be done quite easily with inbox rules, and Office 365 takes care of the rest.

Sounds awesome; sign me up, right? It took me an embarrassingly long time to figure out how to add the policies to my account and use them. I’m talking 2 or 3 sessions where I gave up, defeated. Fear not, though, friends! For I have figured out the path forward and present it to you here in just four easy steps.

1-3. Add Policies to Your Account

This was the part that escaped me for so long, and the issue is that I was trying to do it from Outlook instead of through the Outlook Web App.

  1. Log into O365 > Outlook
  2. Settings > View all Outlook settings > Retention Policies
  3. Add new policy > (add some policies)

Alternatively, you can jump directly to the following URL:
https://outlook.office365.com/mail/options/mail/retentionPolicies

4. Make a Rule

Now that you’ve added some retention policies, you can apply them to messages with rules. As mentioned earlier in the post, I want to delete messages from Azure DevOps after a few days, so I created a rule that applies the “1 Week Delete” policy to them.

When these messages come in, they can sit comfortably in my inbox and compete for my attention. If I happen to get a behind–which happens frequently enough for me to have pursued this several times and then write a blog post about it–these stale messages will conveniently self-destruct and go away all by themselves. Wonderful!

Blogging Makes You A Better Developer

Throughout my career, I’ve found that I’d figure things out, and several months or years later, I’d bump into someone else that was trying to do something similar, and I’d think or say: “Yea, I can’t remember the specifics, but I definitely remember dealing with that.” That was the original motivation for starting my blog: to build a personal catalog of things I’ve learned that I could refer back to should the things become relevant again.

It started as a bit of a hobby but eventually became part of my weekly professional life. I’d research my assignments, and I’d track the journey. Once I finished, I’d organize my list of steps into an article and publish it. The more I wrote, the more views my blog would see, and it became exciting to watch traffic grow and track statistics.

I was reading an article about the Feynman Technique and realized that this is similar to how I approached writing.

  • Start with a concept: a problem I’m trying to solve for an assignment
  • Teach it to a toddler: figure it out/make it work
  • Identify gaps: are there things I don’t understand about the solution or aspects that I am not able to articulate?
  • Review & simplify: write an article that’s concise and easy to understand

I was having a lot of fun transforming my work into articles and watching daily traffic grow, but what I didn’t realize was that this activity was actually giving me tremendous professional growth in a number of ways.

Writing Skills

Writing is an extremely underrated skill for software developers. Between email, team chats, direct messages, and documentation, I’d venture to say I spend more time writing than I do coding. In the digital age, I’m often represented by the things I type much more than the things I say or do.

The more important part of writing is how it affects people around you, though. Good writing is essential to sharing and communicating your ideas. It allows you to explain concepts to your bosses, teammates, and clients/customers. Maybe it allows a colleague to understand your perspective and snap to your approach, or maybe it helps them explain back to you where you’re wrong. It might enable you to implement a cool new feature or prevent the team from wasting time on something that’s not needed. Good things happen when you articulate thoughts effectively.

Technical Expertise

This is the big advantage that I didn’t realize until more recently. I thought I was learning things and just documenting them by writing articles, but the exercise of sharing it with the world forced me to take extra steps. I needed to fact-check claims I was making and double-check assertions. This correlates to the “identify gaps” step of the Feynman Technique. The act of publishing things I thought I knew forced me to make sure I actually knew them as best I could.

Similarly, knowing things a little better and having “practiced” explaining it makes you an excellent resource for your team. You know more things, you know them well, and you know how to explain them.

Shareable/Referenceable Content

My original goal! It’s awesome when somebody needs something, and you can just give them a link instead of explaining. It’s also fun when a co-worker’s researching something and they find you, which has happened a couple times. Sometimes you even turn up as an answer to your own questions!

Personal Brand

This is particularly good advice for people early in their career. If I get a resume from somebody with a blog that’s been active for several years, I get excited. This is someone that values learning and communication. This is someone that wants to share ideas and help others. This is someone that I think can provide a lift to the team.

Of course, if I look at the blog and it’s poorly written or has a lot of mistakes, it might work against you. This is where it’s important to follow the process. Start with your idea. Get it written. Fill the gaps. Simplify. With diligence and time, you’ll have lots of great content that represents you well.

Two Ways to Send Emails to Slack

I get a lot of emails where I want to discuss with my team in Slack, and I was really excited when the Send to Slack Outlook add-in was created. It’s really nice to click a button, specify a channel, and have the email show up.

Unfortunately, I noticed yesterday that things like screenshots & images contained in an email message may not show up when the add-in is used. However, just today I happened upon another setting in Slack preferences that allow you to generate a unique email address. When you send emails to this address, they come as a direct message from Slackbot–and images that didn’t show up in emails sent with the Outlook add-in did show up when I sent them to this email address.

The setting is found in Preferences > Messages & Media > Bring Emails into Slack.