Your first day at work

You’ve finally reached the next stage in your journey: you’ve become a professional software developer. Congratulations! I’m certain it was an arduous journey. No two journeys are alike, but every single journey has many challenges, from the first time you wrote a constant to that offer letter you just received. In between those two events, there was plenty of learning, a decent amount of frustration and so many dreams of becoming a developer. And today it’s your first day at work!

By now, it’s likely you’ve been communicating with either your boss, HR or someone that handles hiring. You’ve signed the paperwork and are ready to start building features or squashing bugs. If you’re lucky enough to be a user of the app your company is building, I’m sure you’re eager to make it so much better. There’s likely some flow that could be improved or you’ve already noticed a couple of bugs that you’d like to fix. However, no matter if you’re a user or not, I’m certain you’re excited! You’re a paid developer! People will pay for your work; if that’s not an amazing and exciting state of affairs, then I don’t know what is.

However, your first day is likely to be the exact opposite of exciting – it’s going to be boring. Before you can even get to work, the company needs to accept you as one of their own and that means getting new accounts for many different services, starting by a new email.

Your work email is, most of the time, going to be the key to all other work accounts. There are several companies out there that won’t mind if you use a personal email, but they’re the exception, not the rule. Which brings me to the #1 rule, not only for your email but for everything that has the company name in it: you don’t have an expectation of privacy

It’s a simple rule, but quite unbreakable. Once your work email is up and running, assume your employer has access to everything in it because they do. They don’t have your password, of course, and no reputable email provider – like Gmail – would ever let the admin of an account access other people’s passwords. However, every service I’ve used will allow the admin to reset the password of any account. It then follows that your company doesn’t even need to know your password. They only need to reset your password to get access to it.

Do not use it for personal communications. Do not subscribe to any personal newsletters. Do not use it to buy personal things. Think of this email as a loaner. You’re renting this email while you work at the company. The moment you’re no longer working for the company, you will permanently lose access to this email.

To follow up on that last point: you want to have access to this email after you leave the company so you should always back up that email somewhere safe and under your control. There are many different ways of doing it but the easiest one is to log into your email using Mail and then choose File > Export Mailbox. You should do this regularly, so you have a complete backup of all emails you get. Having a backup is always important but since this email is the keys to your work kingdom, it contains sensitive information that you should always have at hand. Not only that, but once you leave the company, you want to hold on to these emails for your own protection.

So you’re all set up with your email. Once you’ve confirmed to whoever is onboarding you that you have access to your email, it’s notification time! Notifications from everywhere! Slack, Teams, GitHub, Gitlab, Jira, Trello, Basecamp. There’s so many notifications from so many services you’ll be surprised and it may be annoying for the first few days. Let’s start with the bane of your attention: instant communication. 

Instant Communication

Most companies have, unfortunately, not understood that there are very few times when synchronous communication is superior to asynchronous. Since we still live in this world, you’re likely to be signed up for a work Slack account. There are several other players in the space, like Microsoft Teams, but most services serve the same purpose: trying to organize synchronous communication in one spot.

The most important part of this section is for you to know that instant communication is horrible for your attention span. Your work as a developer is to build or fix code. As you know, this is such an incorporeal activity that you may be sitting down for hours, barely typing anything into your screen and that counts as work. Someone is paying you for your ability to concentrate, distill a problem into code and build or fix it. Your #1 asset is your concentration and the whole purpose of instant communication is to consume your attention. Hence, it is your #1 enemy.

Also, I will be using Slack in the following paragraphs, but it will apply to any similar services.

I have yet to join a company that has a Slack workspace and is careful about creating channels. Since instant communication is the human default, it is pervasive across company culture, regardless if it’s remote or not. This means that any Slack with sufficient activity has a tendency to have as many channels as users. Many channels will either have too general a purpose (e.g. the dreaded #general) or they will be obscenely specific (e.g. #project-collaboration-demo for a 2-week project between several devs). Not only that but then you have to also consider that  there are many different levels of importance.

There’s two criteria that will help you understand whether to mute a channel or not.

The first one is the signal vs. noise ratio: how often people interact in it, and whether those interactions are important to you. Sometimes active channels are important and you should be aware of everything that happens in them and other times they’re unimportant messages.

The second criteria has to do with attention. Some muted channels will be important to you and it may be worthwhile to check them once a day. Let’s go over the following examples.

Primary team channel
Enable all notifications, check multiple times a day
This is your main channel and where you’ll spend most of your time and communication. Never mute this channel in any way. Usually this is something like #ios-devs or #apple-devs or something similar.  Your whole team will be in it and they will be active during their work hours. Conversations will usually be technical in nature with some banter on the side. If you’re lucky, this channel will have no bots in it so all messages will be somewhat relevant to you, either because they are work related or because they help you keep the pulse on what the team is chatting about.

There’s a few caveats. First of all, if this channel has bots, I’m very sorry for you and you should bring it to your lead’s attention. Having bots in a channel with humans can add an extreme amount of noise to the channel. If so, it’s going to be frustrating because I recommend you do not mute the channel either way.

Secondly, in some occasions, there may be a general “team” channel and one channel per app. In this case, unless you’re specifically assigned to one app only, you should consider all of these channels primary.

This team channel is your main candidate for snoozing. Depending on etiquette, which we’ll discuss later, you may have to announce that you’re going into a coding session (e.g. “bb60 coding”) so that your team knows you’re working but won’t respond to mentions or DMs.

Secondary team channel
Enable mentions only, check once a day

This happens less frequently but there may be other channels where your team will interact but is not as important as the primary channel. For example, something like #mobile-dev which is shared between your team and an Android team. You should mute regular activity in this channel, but leave mentions on. However, having notifications doesn’t mean you don’t check your channel. Since your whole team is in this channel, you should try and catch up daily. It’s not critical that you do so, but it allows you to be aware of conversations that may be important to your team even if important directly to you.

Dev/General channel
Enable mentions only, check once a day
This time we have a very general channel. My naming may be off and it may be something like #programming, #development, or #tech but it will have the entirety of programmers in your company. This channel will, in turn, be very general and its importance may vary wildly. Some #dev channels may be all about sharing interesting programming news or paradigms, while others may be much more oriented towards how the company manages development. On average, you’ll find 70% banter/off-topic technical chatter and 30% important conversations about the company from a dev perspective.

You should enable mentions here because your CTO/VP will use this channel to announce important messages such as outages in your git provider, schedules for all-hands meetings and other company announcements. I would recommend that you check here at least twice a week. If you want to be active, once or twice a day is enough.

Other team’s channel
Enable mentions only, check once a week

There are other important teams in the company that may be worth of your attention if pinged. For example, your team lead may be chatting with someone at marketing and tag you to ask you a question on a ticket related to a feature or a bug fix. Or the Android team may have a technical question and they tag the whole iOS team. You want to be able to react to these notifications, but they are usually not super important. Other teams have other priorities and when they align interaction will usually not be heavy on instant messages, it will happen in meetings and the ticketing system that your company uses.

If you’re curious, you may go around to other channels once a week. It helps keeping a pulse on how other teams work and important topics across the company. I would not usually interact in these channels, even if a conversation is ongoing and interesting to me. However, your mileage may vary. 

Company announcements
Enable notifications only, check sporadically

It’s likely there will be a single channel where important announcements are sent. In my experience, 99% of these announcements will either tag @channel or @everyone or something relevant so it is safe to mute except for notifications. I would still check sporadically just to make sure you’re not missing anything but it’s not terribly important if you miss any because if something important happens, you’re team lead will let you know. 

Mute completely, check once a week

There will be a ton of channels that will be extremely good at taking time away from work. Some of these are #cooking, #pets, #music, whatever. These channels will usually be created when someone has the great idea that they want to share their hobby and they create a new channel which only receives updates sporadically. Some of these channels have weekly reminders like “what did you do this week?” Or “what did you cook during the weekend?”. Mute these channels judiciously unless you do want to participate. If you want to participate, definitely be active in them during your downtime.

Even though these channels are horrible for your productivity, they are an amazing place for bonding with your team. You get to chat about topics they are interested in so don’t immediately jump to the conclusion that they are useless. I consider these types of channels the complement of Other Team’s Channel because you should feel encouraged to interact in them, especially if a conversation is ongoing.

Mute completely, check sporadically

The bane of my existence. I will mute these channels and completely forget about them. Once every full moon, I’ll come back to see what I missed and it’s usually nothing.

That’s it for human channels. Now, let’s get to the bots…


That’s the beginning of the book! Did you like it? I will be sending an excerpt every week along the weekly exercise to everyone in my mailing list. These will be first drafts and may be rough around the edges, but I am certain you will find them useful in your journey, even if you’re only starting. 

If you’d like to preorder it, you can do so on Gumroad here This will be an introductory price for people in the newsletter but for now I’ve decided to open it to 25 people in my Twitter and blog. The book will go out November 1st.

As always, thanks for your support and I’ll see you around!
– Fernando