Turn off those notifications

Dear new developer,

Shut off your notifications.

There are so many interruptions in your workday that it can be hard to find the time to dive into deep work. Disabling alerts from communication programs can help you stay in the zone and avoid having distractions pushed to you.

Here is a list of the software for which I’ve turned off alerts:

slack on my computer
slack on my phone (if I even install it there)
email on my computer
email on my phone
any other applications on my phone (except SMS)
discord

I know people who have disabled new text message alerts. I think that is a bit extreme, but do what works for you.

Shutting off these notifications lets you check messages in these systems on your time, not whenever someone sends you a message. Even though it feels good to respond quickly, doing so impacts your ability to ship working code (or whatever else you are trying to deliver).

Here’s a playbook for freeing up your attention.

First, think about how much time you should block out for focused work. If you are just starting, aim for thirty minutes of uninterrupted time. If you are working on a hard problem, a block of a couple hours a day will be better.

Then, discuss with your team at work. Find out what their expectations for responding to messages are, for any mechanisms used such as email or slack. This is a great conversation to have with your manager at a one to one. The expected response time will vary based on the content of the message, but try to get a broad understanding. Is it ok to respond an email or slack message within a business day? At the end of the day? In a couple of days?

One thing to be aware of is that as a new developer, you may get blocked. You need to make sure your heads down time doesn’t mean you keep banging your head against a wall if you don’t see a path forward. There’s a distinction between needing to reach out to someone for help and being interrupted by others. The former is expected, the latter is what you are trying to avoid. Make sure you discuss that distinction and have clarity around it.

Another thing to know is that decisions may get made without your input, especially if you wait a couple of days to reply. This is a tradeoff. As a new developer, however, you may be more interested in the decision as opposed to weighing in on it.

Next, make the changes to your applications. Turn off notifications for communication software such as email or slack. I find it helpful to block out time on my calendar to remind folks. You may need to close messaging clients entirely.

Also, don’t forget to provide an escalation path. If someone really needs your feedback on something, how can they get ahold of you? I always add my cell phone number to my profile and tell people that if they really need me, text me. Plan for this. It won’t happen often (at my current job, no one has ever texted me) but if you are truly needed, you want to be available.

Finally, set a schedule to check in, as informed by your needs and the team’s expectations. Think about whether you will check in daily, a few times a day, or every hour. Whatever you and your team have agreed to, do that.

Beware the tendency to check in on email, slack, etc, mindlessly.

You are avoiding the push of distraction; don’t fall into the trap of pulling distractions to you. This is a bad habit of mine. If I’m waiting for a page to render in a jekyll site or a local server to restart, I’ll sometimes idly flip over to slack or email (or worse, an online community like Reddit). Doing so defeats the entire purpose of limiting notifications.

A colleague once told me that there are three types of tasks: big, medium and small. You can think of your day as a container that you are filling with rocks, gravel and sand, respectively corresponding to the big, medium and small tasks.

If you fill your day with small tasks, such as checking your email, you won’t have time to work on the big rocks, just as if you put sand in the container first, you won’t have room for the rocks.

If, on the other hand, you allocate specific time to the bigger tasks, the smaller tasks can fit around the edges.

Turning off your notifications and controlling when you are responding to messages from others is a good way to focus on your big goals.

Sincerely,

Dan

Tips for using email well

Dear new developer,

Writing great emails is a key skill. For all the hullabaloo about slack, emails still rule the roost when it comes to cross organization communication. This is because everyone has email, it is auditable and uneditable once sent, and requires no special permission beyond knowledge of an email address.

Email is great at conveying information, but horrible at conveying context. It also can be unclear and ambiguous. Because email is asynchronous, ambiguity causes slowdowns and confusion more than ambiguity in conversation (where you can say something like “when you said tomorrow, do you mean Saturday or Monday, the next business day?”).

This post has some great tips on how to write great emails. From the post:

Avoid using only temporal adverbs/nouns like yesterday, today, tomorrow, two hours ago etc but include also the specific dates/times otherwise they might be misunderstood or require from recipients to check the email’s sent date/time to calculate the actual time.

and

Use bookmarkable links when you refer to something that would eventually require from the recipient to search for in another platform.

There are a number of other great tips for writing clear emails in this post. The author also provides before and after examples, which really illustrate the points.

Worth a read.

Sincerely,

Dan

Subscribe to a weekly link newsletter

Dear new developer,

I mentioned before the benefits of participating in an online community. If you aren’t interested in a back and forth, you can often join an email list where someone will capture interesting articles on a particular subject and email you weekly. (Examples that I’ve recently interacted with: API links, dev links, craftcms links.)

These are nice because they don’t take any effort (beyond signing up). And then once a week or so, you can get the newsletter in your inbox.

A few tips about these.

Pick and choose. There are so many of these (because it is valuable to have developers’ attention), so google around for a bit. Good terms to search for are ‘<subject area> weekly newsletter’ or ‘<subject area> email newsletter’.
Read the archives first. This will give you an idea of whether you’d enjoy the content and the voice of the newsletter.
You don’t have to read every link. It can be overwhelming. So just scroll through the links and click on any that are interesting. You can also share with an online community, your team or a former colleague if you see something interesting.
Use it to explore a new technology or area of software development. Such regular content will introduce you to both jargon and people writing about the topic.
Don’t be afraid to unsubscribe. Easy come, easy go. If you don’t use a technology any longer, or aren’t interested, don’t clutter up your inbox. You can always resubscribe if you miss it.

I find this kind of email list to be an easy way to get up to speed and be tuned into a tech community. (If you are looking for a newsletter for a topic and can’t find it, you can start your own too! Tinyletter.com is an easy way to do this. Just be prepared to spend some time finding and curating links.)

Sincerely,

Dan

PS You can also sign up to get “Letters to a New Developer” via email too, it’s in that right hand column.

Get an external email address

Dear new developer,

When you are starting at any company, you’ll get a company address: dan@company.com. You’ll want to use that for all company communications.

You may have a personal email address: fuzzyguy@gmail.com (not my real personal email address 🙂 ).

But as soon as you can, you’ll want to get an external email address at a reputable provider like gmail or protonmail and have a professional looking email address, something like danmoore@gmail.com. If your fullname is taken, then add digits or variations: dannymoore@gmail.com, dan12@gmail.com, etc.

If you want to get fancy, register your own domain name and then set up an email address: dan@danmoore.com.

There are a number of nice things about having this external email address:

You can put it on your resume when you are applying for jobs and it will look professional. Though there are a lot of means of communication, email is still the major method of cross business communication.
You can have it for life, which means in ten years when you want to reach out to that one woman who was a linux kernel specialist, you can search for the message you sent to her. I have had my personal email address for almost twenty years. I don’t often search far back, but when I do it’s nice to have one place to go and look.
You can use it in your goodbye email to your company to keep in touch with people. (You will eventually leave the company, and while I suggest you connect to everyone on LinkedIn, some people don’t use it. Almost everyone has an email.)
You can use it as the email address of record for your “developer brand” accounts. These accounts will follow you for life and you don’t want them tied to any company email address. Things like Stackoverflow, github, or your online community accounts should all be tied to this professional, external email address.

Sincerely,

Dan