My alarm is set for 6:45 but I often wake up before it goes off. I tend to wake up earlier during Vancouver’s long summer days, when the sun is up from 5:10am to 9:10pm and already peeking through my blinds, but it sometimes happens in the winter when it’s still dark out. Every morning starts with a hot refreshing shower before getting ready for work. I recently became a morning person and found that showering in the morning goes a long way in preparing me for a busy day ahead, especially during Vancouver’s colder seasons. In the shower, I’m often thinking about what I’m hoping to accomplish at work today. I sometimes even think of a solution for a problem that I’m working on!
I head downstairs to the kitchen to prepare a morning protein shake to kickstart my metabolism; eating breakfast is another recent change to my morning routine. After breakfast, I take some time for myself by listening to music, washing the dishes, tidying up around the house, taking out the garbage, reading some news articles on my phone, checking the stock market, and going over my calendar events. By getting some daily chores done in the morning, I can focus on work as soon as I get into the office.
By 8:15, I’m out the door and on my way to work. I used to drive to the nearest SkyTrain station and take public transit downtown, much like I’ve done for the 15+ years I’ve worked in Vancouver’s downtown core, but recently I’ve been driving to and from work every day. I managed to find some reasonably priced monthly parking close to office and Slack’s $100/month transportation subsidy helps offset the cost a bit. I live around 18 km (~12 miles) from work, which is considered relatively far for Vancouverites, but I like driving and don’t mind commuting through a bit of rush hour traffic.
By 9:00, I’ve navigated through traffic and parked a block away from Slack’s Yaletown office. On a good day, Google Maps on my Android Auto display tells me that I’ve arrived earlier than predicted. Before heading into office, I head over to the nearby Small Victory Bakery, where Slack provides its employees with coffee and tea perks. We just order and show our badge and the rest is taken care of for us. I’m sure the baristas know several of us by name now, seeing as the short walk is a great way to take a coffee break in the afternoon too. Their croissants are also some of the best in town, so I’m careful not to indulge in them too often. In the morning, I simply get my extra-hot London Fog then head into the office.
Once settled in at my desk, I open up Slack to catch up on any announcements, direct messages (DMs), and unread starred channels. From within Slack, I then check if there are any GitHub pull requests that require my attention so that I prioritize them and unblock my fellow Android engineers.
A lot of pull requests are usually sent my way since my name is attached to a lot of files’ git history. While I’m currently working as a Product Engineer on the Messaging team, Mobile Engineering at Slack was not always structured this way. Back when the Android team was a dozen or so engineers, we were a centralized group that was assigned to various feature projects. Everyone worked on the full stack, adhering to agreed upon data structures, design patterns, test requirements, and general code styles. I work most effectively when I’m intimately familiar with all aspects of a codebase, so I used that opportunity to learn about and work on all layers of the code.
Fast-forward to today, where the company has grown five times in size and the Android team three times; mobile engineers are now embedded in various pillar teams to effectively manage project resources. My focus is now on product development — more specifically, how users compose, digest, and interact with messages — where I lead Android Messaging efforts. During my time at Slack, I’ve been the primary developer for the Advanced Message Input composer that allows photos and files to be uploaded inline, the modernized message rendering pipeline that’s written in Kotlin and leverages RxJava, the Rich Text infrastructure that handles all the intricacies of displaying and storing “what you see is what you get” (WYSIWYG) messages, and our PowerPack testing infrastructure that I gave a talk about. A lot of this work serves as a foundation for us to build even better features for our end users.
To quickly touch base with my team of engineers (frontend, backend, Android, iOS), a designer, a product manager, and an engineering manager, we have a short 15-minute morning stand-up. Since I work out of Slack’s Vancouver office, the team members here dial into Zoom to talk to our San Francisco counterparts. We use this short sync to get a sense of what everyone’s working on and if there’s anything to call out for the entire team. Whenever possible, we also lighten the mood a bit with some friendly candor; it really helps reinforce the mindset that we get things done and have fun while doing it.
If I haven’t gotten into my work yet, I’m definitely nestled into an Android Studio frame of mind now. Sometimes a high priority bug comes to my attention during stand-up, so I’ll open up the Jira ticket to see if there are any repro steps or logs from the internal report or Zendesk ticket. We never want to inconvenience our users with bugs so we prioritize the really bad ones that come in from our internal testing. At Slack, we have a mobile dogfood release that all employees use as their main client. This version is distributed daily via the Google Play Store, so we usually catch problems internally before any of our users see it.
Once I’m in the clear for bugs, I’m heads-down and working closely with my San Francisco-based counterparts on the latest Messaging feature. Whether it’s making it easier to send messages or surfacing the most pertinent information at the right time, there’s never a shortage or product improvements to be made. With Slack as our collaboration tool, working in different offices doesn’t hamper our productivity at all. We’re very strategic on how we separate the work — often UI and infrastructure as a starting point — so when we coordinate our efforts over Slack, we can pretty much move in lockstep without stepping on each other’s toes. The Android team goes through design reviews before making significant client changes, so with those and pre-established patterns in hand, we’ve pretty much nailed down the approach at this point.
At Slack, there’s a lot to do so we’re always on the lookout for passionate engineers. I’ve been phone screening a steady stream of candidates lately, where I get a sense of their experience, work style, team fit, and passion for redefining how we communicate in the workplace. The Android community is a pretty open and welcoming group, so it’s always nice to see that sentiment come across in an interview. We hire for a wide range of levels and always value passion and potential. We also love bringing in new people with fresh ideas on some of the technical challenges we’ve been working on. Equally so, we love sharing our knowledge and mentoring those who might be relatively new to mobile development so that we can all grow in our careers.
While I love to cook at home and pack leftovers for lunch, Slack provides catered lunch two times a week in the Vancouver office. It’s always a surprise to find out what’s on the menu for the week, as we have a wide variety of cuisine offerings from curry, tacos, sandwiches, sushi, and everything in between. If we’re left to our own devices, I usually have a sit-down lunch with the other engineers here. There’s always someone craving ramen, so there are a few places that we like to hit up as a group. Whatever the case, I use this time to socialize with other engineers and get a sense of some of the challenges they’re facing.
The mobile engineers are particularly close, as we encounter a lot of the same things on Android as we do on iOS. We have a good representation from all pillars in Vancouver, allowing me to get a better sense of what the Enterprise, Infrastructure, or Platform teams are tackling next. We tend to talk about cross-functional Android themes, like our latest Kotlin adoption percentage, the progress of the RxJava2 migration, the code modularization effort, or the reduction in Gradle build times that our Developer Experience team takes lead on. I enjoy being around individuals who care deeply about their work, as that work ethic and culture tends to resonate throughout the team.
While we try to keep meetings to a minimum at Slack, afternoons are generally prime time for them. I actually look forward to some of them, since the Android engineers schedule regular cross-function meetings to maintain the health of the codebase and team culture.
One of these meetings is our Design Workshop. When an upcoming feature or infrastructure change has implications for other pillars, we write up a Design Doc so stakeholders have an opportunity to bring up considerations that may have been overlooked. This collaborative effort is one of my favorite aspects of the Android team since it not only leads to better and more future-proof designs, but also shows that we’re conscientious of others who work in the same codebase.
Another meeting around this time is for our Android Principles group. Internally, the Slack Android team has a reputation for being high-functioning, so a subset of us meets every other week to find ways to preserve that culture as the team continues to grow. This can be anything from improving our onboarding process and identifying more mentoring opportunities in code reviews, to making a new member feel more welcome and fostering better team rapport. It’s important to us to maintain a healthy and productive work environment at Slack and I appreciate how the Android team is very proactive about it.
Development continues and so do project discussions. Whether it’s clarification from our product managers and designers, or double-checking that I have a complex RxJava chain just right, the afternoon is a good mix of writing code in Android Studio and discussing requirements in Slack channels. The Vancouver office also benefits from seating all the mobile engineers together, so I sometimes turn my chair around and tap a colleague on their shoulder to discuss implementation details for web socket connection states, channel sync background jobs, or file upload retry logic. There are a lot of complex moving parts that go into a Slack client and getting them all to play nicely together is often rewarding in itself. Building the next thing to make our users even more productive? Even better.
I’ll occasionally check Slack to see if there are any DMs or public channels with discussions that I need to respond to, but for the most part I’m pretty focused on my tasks for the day.
It’s not uncommon for a fellow Android engineer to ask about a very specific implementation detail or request feedback on a proposed change, so to avoid a lengthy back-and-forth discussion over Slack, I often direct them to my Office Hours that I host three times a week. The purpose of these Office Hours, which various Staff-level Android engineers have, is to minimize disruption during the day and to provide a more personable face-to-face way to hash out ideas. They also double as a mentoring and knowledge-sharing opportunity, particularly for new members to the codebase (regardless of their level). Over time, I found they’re a really good way to connect with other Android engineers whom I don’t interact with as much, and are quite efficient at coming up with a solution too. I sometimes go over their code together — akin to pair programming — while other times I help brainstorm solutions before asking the individual to put together a Design Doc for the wider team. Any noteworthy decisions or discoveries are then shared back in channel, so that other team members may benefit from them in the future.
By 4:00, all meetings have wrapped up and Slack conversations have dwindled down, so this tends to be my most productive time of the day. While listening to music on my noise-cancelling headphones, I work on completing the Jira tasks that I set my sights on this morning. My goal for the day is never too ambitious, but to ensure that I feel productive and maintain a good project velocity, I put in some extra time if I feel behind. I like to put in some extra hours early on to avoid a frantic push at the end of the project when we’re trying to ship. Over the years, I found the front-loaded approach suits my work style and is one of the main reasons why work never really stresses me out anymore. It also helps when Slack encourages a “work hard and go home” culture, so the onus is on us to take ownership of our work and use our best judgement on when we need to put a little extra time in.
I pack up my MacBook Pro and head home. I always take my laptop with me so I have flexibility to work from home the next day if something comes up. I rarely ever leave before 5:30 since leaving later actually works in my favor in terms of traffic. What is normally a 45-minute commute drops down to 25 minutes when there’s no traffic, so squeezing in a bit more work tends to be the norm for me. Once home and feeling accomplished, I prep dinner and unwind for the rest of the night.
Kevin is a Staff Software Engineer, based out of our Vancouver office. As a native resident of Vancouver, he’s worked for various software companies and specialized in Android for the past 8+ years. In his time at Slack, he’s worked on a few teams, starting with the centralized Android team before a reorg brought him to the Product Engineering side of things. As a leader on the Android Messaging team, he is the primary engineer behind Android’s composer, message rendering pipeline, and Rich Text infrastructure. In his spare time, he enjoys cooking without a recipe, going to the movies, working out, being in good company over coffee/tea, and driving sporty cars. He recently joined the Android App Infrastructure team, where he’ll focus on enabling product engineers to ship features faster and more reliably. He enjoys making the lives of his fellow engineers more pleasant and providing continual value to Slack’s customers.