Over 70% of the files uploaded on Slack are images, and over 75% of those images are screenshots. What this tells us is that though images are ephemeral, screenshots are often used as a quick way to provide extra detail and context, and typically gain a high level of engagement over a short time period. Currently, a user must leave Slack and use another program in order to make small modifications to their image, resulting in valuable collaboration time being lost to context-switching. To help remedy this, we decided to create an image editor capable of rotating, cropping, and flipping an image in order to make sharing images faster, simpler, and easier.
This post covers the lessons I learned while developing this feature during my internship last summer, and how the experience helped me become a more experienced coder.
Being a product-oriented engineer
As a product engineer, it is important to stay focused on the end-users and not get lost in the technical implementation details. Here are a few tips I learned from talking to people heavily invested in Slack’s product strategy on how to be a product-minded engineer:
- When thinking about a decision, always go back to the problem you’re solving. It’s easy to get so invested in your solution that you lose sight of that. Consider how users engage with your product and try to empathize with what they might be experiencing as they use your product
- When in doubt, test it out. When you’re trying to make a design decision and aren’t sure about what tradeoffs to make, it’s often useful to A/B test multiple options and observe the data.
- Back up your decisions with data. Logs can help you find out how many people are using your feature, how consistently they’re using it, and what kind of people are using it.
Developing and releasing features
We decided to target a relatively simple feature first so that we could quickly add value to our product. My goal was to implement a rotation button in the image viewer. Once I got to actually programming the feature, I realized the difference between writing code in your own codebase versus contributing code to a shared codebase. Something that seems really easy to code from scratch could take significantly longer if you want it to mesh well with previously written code.
My biggest takeaways were:
- Adhere to already written interfaces. Keep code consistent with what’s already been written to avoid future code conflicts and confusion.
- Write future-proof code as much as possible. Make sure that others can easily read and understand your code, and write your code to be easily expanded upon with potential new features.
- Reuse code through functions or objects whenever possible. This allows future issues to be fixed in one place rather than several.
- Build with the user in mind, and make sure all your users can use it. Ensure all strings you use are translated to as many languages as you support, and that your feature is accessible.
- Wrap your code in an experiment or feature flag. This allows you to turn your code on and off easily in case something goes wrong. It also lets you release your code gradually to different groups of people, so you can monitor how it’s being used.
It took me several tries to transition from my hacky coding style to coding like a Slack engineer, but my mentors were super patient and taught me a lot during the mandatory code reviews that we go through before merging your code. In two months of constant trial and error, small victories, while learning two new languages, we were finally done with our first take at the image editor. Throughout the journey I was surprised to see that a lot of my thoughts and struggles were less related to code and more about maintaining the fine balance between security, privacy, and compliance. Users that are cropping images probably don’t want old cropped portions to be publicly accessible. Additionally, when exposing an API endpoint to the public, it’s always important to make sure that no matter what they input, a user cannot overload our servers or access information they don’t have access to. During this period of time I realized exactly what my manager meant when she said “a good software engineer is defined by how well they make decisions and evaluate tradeoffs rather than their pure coding ability”.
Conclusion and final advice
After making the final merge and deploying my code to Slack’s instance of Slack, I felt a sense of fulfillment that reminded me of why I wanted to get into tech in the first place. The ability to make an impact on millions of people with just a laptop is what gets me through all the nasty bugs, and edge cases.
To all future interns reading this, my final advice is to make mistakes, ask questions, meet new people, and have a blast. If you’ve found a company with people you love, a mission you’re proud of, and engaging daily work, that’s the place to be.
Thank you to everyone at Slack for teaching me so much and giving me the opportunity to contribute to such a great product! If you’re interested in becoming an intern at Slack next summer, check out our University Recruiting page.
