I’m definitely not a morning person, so when my alarm goes off, I can’t help but stay in bed a little while longer. I have two cats, Stella and Orion, who are especially cuddly in the mornings, so it’s hard to leave them and get out of bed. My cats are well known by my teammates as well as they make guest appearances in meetings whenever I’m dialed in and working from home. Because some of my teammates are much earlier risers than I am (or are in different timezones) I’ll hop on Slack as I’m getting ready to catch up with them as I start planning out what I’ll tackle at work today. I also take this time to catch up on any big releases going out or any interesting developments over the evening that might inform my work — there’s always lots going on in the Engineering org at Slack!
I’m finally out the door! I told you I’m not a morning person. I live in Bernal Heights, so I catch a bus down the hill in the mornings to the 24th & Mission BART station. I live near a fantastic shop, Black Jet Bakery, and if I’m running a little early, I’ll stop there for a pastry before hopping on the bus. It’s so peaceful in the mornings.
Made it into the office! My first stop is the barista station on the 5th floor. Ah! It’s such a wonderful way to start a workday. I get a latte in a big mug and settle into my desk, dig into Slack for real now and plan out my work for the day in my notebook — I really like writing to-dos down physically. I’ll typically review any outstanding pull requests from my teammates during this time or answer questions that have come up in my team channels — some shorter tasks that I can complete during this window of time.
Standup time! I’m on the Messaging team and we’re responsible for the core part of the product — everything from the user experience to the infrastructure about how messages are stored and formatted. We have team members in Vancouver and New York (and soon Toronto), as well as our headquarters in SF, so standup is a chance for us to all sync up on what we’ll be working on for the day and resolve any questions that arose the previous day. Our standups can be particularly silly, which I think is delightful. We often close our standups with a fun fact. Did you know that most of the things we call berries, like strawberries, are not actually botanical berries, but “accessory fruits”? Or what do you think the Japanese name for the seven sisters Pleiades constellation is? It’s Subaru! Look at the car logo the next time you’re driving around and you’ll see, although the logo only has six stars since the 7th star in the constellation isn’t visible to the naked eye.
This is the first time today I’ve gotten to tuck in and plug into coding. I was a Sublime lover when I first joined Slack, but I’m a full VS Code convert now. At Slack I mostly write in Hacklang (which was new to me prior to joining) and the tooling with VS Code is :chef’s kiss emoji:! That and the awesome support from our Internal Tools team make it so easy to get up and running in a new language. My newest favorite plugin I’ve discovered is the Bracket Colorizer 2. It’s a super simple concept — it just colorizes the brackets so each pair is the same color, but in a complex codebase it helps simplify what you’re looking at so, so much.
One of the projects I’m currently leading is a very exciting, cross-functional project to migrate the messages table to our Vitess cluster. Slack has been in the process of migrating some of our most important tables to Vitess to increase our ability to scale with our largest customers (more information about how we chose Vitess and it’s impact here). As a product engineer it’s so different to have the goal of a project be, “Users notice nothing”! Because of the sensitivity and importance of the data we’re migrating, and what a big undertaking this is, we have worked as a team to make very calculated decisions, building theories about any unexpected things we see and using our different domain knowledge to bridge the gaps and cover the entire message sending, persisting, and rendering stack. I am really enjoying getting to learn more about our infrastructure at Slack, and getting to go into the weeds while still working out of a core product team. It has been extremely rewarding to partner with our Infrastructure team and create a group that can bring both the Vitess expertise and the product knowledge to this migration. While we still have some of the final climbs to go, it has been gratifying to look back and see how far we’ve come since we set off on this project together.
Lunchtime! The Composition team is part of the larger Messaging engineering pillar — we have a great group of backend engineers and it’s wonderful to feel their solidarity and support. A rotating subset of us will often get lunch together, which is a nice way to connect outside of a code review and pair programming context. Any interesting topics that warrant source materials or further discussion get posted to #lunch-action-items. The last post was Blair Braverman’s twitter thread describing her sled dogs!
The Messaging backend team is actively hiring! Some afternoons I’ll serve on an interview panel, helping our recruiting team interview potential new teammates. I’m particularly proud of the continuous work the backend engineers across Slack put into trying to make our interview process the most representational and least stressful it can be. Interviewing also reminds me how many people are excited about the product we get to work on every day. It’s sometimes easy to get focused on the minutia when you work so closely to something and to lose sight of your own appreciation for it — being asked questions about Slack by our candidates helps me zoom back out and remember the positive and widespread impact it has.
Back at my desk! And back to proselytizing VSCode! One of the biggest contributors to me switching over was the debugger, which my teammates at Slack have hooked up to our development boxes . It’s crucial to the way we add to — and debug — our codebase, and has made figuring out and fixing bugs in our system much easier. As the Messaging pillar, we own so much of what makes Slack Slack — messages, file uploads, custom emojis, emoji reactions, threads, and the list goes on! This is incredibly exciting because our product development in these areas affects the core of the application. But it can also be a double-edged sword — since this is the very heart of the application — it’s not terribly uncommon to come across pieces of code that were originally written 4 or 5 years ago.
My afternoons are my main heads-down, glasses-on, headphones-on time to code. The product teams at Slack work hard to balance our technical time spent between new feature development and maintaining technical health and quality. One of the features the Messaging team just released is WYSIWYG, or “what you see is what you get”. This feature allows you to format your message as you type it — if you bold, it’ll be bold in the input before sending the message! Previously we stored messages as simple strings using markdown format. But for WYSIWYG we wanted to give the user much more control over the message formatting, including formatting that cannot be represented by markdown, such as intraword formatting. While this feature at face value seems like it could be only client work (and don’t get me wrong, it has involved a heroic amount of client work — shoutout to the incredible frontend, Android and iOS engineers I work with everyday!) — it involved a good amount of backend work as well, as we changed the format of how messages at Slack are stored.
Two other interesting pieces of this project that we considered as we were designing were maintaining backwards compatibility and thinking forward to simplifying the code in the future. When designing for a mature application which already has hundreds of billions of messages and millions of users, there are a number of inherent constraints. To continue to support those billions of older messages, we designed the WYSIWYG format to be backwards compatible for devices which don’t yet have our new code. Older applications must still be able to receive, read, and best-effort render the newly formatted messages, as well as still be able to send the old format of messages. On the other hand, we also don’t want to support two different message formats across all clients in perpetuity. For the efficiency and sanity of the engineers across all the codebases, we wanted to design and think through how to get back to only supporting one message format by building a translation layer on the backend, and a plan to migrate all older messages through it. I am so, so proud of this team and all the hard work that went into this feature!
Time to head home! There was probably a Susie Cakes appearance during the day that I’ve left out (my team has such a ridiculous sweet tooth and I am here for it!) and perhaps someone dressed in a T. Rex costume. Most likely a few informal in-person discussions about a product question, a PR comment, or a new Hacklang discovery. Something I reflect on while writing this is that: while I love problem solving and writing elegant and high quality code, it’s really the people I work with and the team collaboration that makes me excited to come back every day. That isn’t to say that there aren’t super exciting technical challenges that we’re solving, but to me it’s about how the team together has an impact.
And with that I head home to recharge, watch some Queer Eye and get ready to come back tomorrow for another day.
Madeline Shortt is currently a Senior Software Engineer at Slack on the Composition team within the Messaging engineering pillar. The Composition team works on the experience of composing a message, from formatting to uploading files to custom emoji. Before coming to Slack, she was at Ripple leading a team building payment APIs for financial institutions. She double majored in Physics and Computer Science at Mount Holyoke College in Massachusetts. She currently lives in Bernal Heights in San Francisco with her two cats, Stella and Orion and rides ponies when she finds the time.