Memory leaks are a common problem when writing iOS applications, and while we all know we should be on the lookout for them, it’s often too easy to miss a vital weak reference. By leveraging integration testing, we can catch these issues and spend more time actually building features.
In 2017, our team of six engineers wanted to try out a clean architectural pattern and decided to use VIPER. In the text below, I’ll cover how the team worked on this.
We revisited our distributed tracing setup and incorporated Kubernetes pod metadata into it, significantly enhancing our engineers’ ability to troubleshoot problems that cut across microservices.
At SoundCloud, we follow best practices around continuous delivery, i.e. deploying small incremental changes often (many times a day). In order to improve the user experience, we’ve been exploring different ways of reducing the impact and the Mean Time to Recovery (MTTR) of faulty deployments. Enter canary releases.
Nowadays, it’s rather common to encounter Apache Spark being utilized in a lot of companies that need to process huge amounts of data, and things aren’t any different here at SoundCloud — as one can imagine, we have lots of data to process all the time.
Sometimes, an important team that’s part of an otherwise healthy company culture starts tanking and the people on the team get frustrated and even quit.
In this article, I want to share what I learned when I started to manage a team — referred to as the R Team from here on out — that had huge problems when I took over as Engineering Manager, as well as explain how I got it back on track.
Agile retrospectives are a widely used practice within engineering teams. They provide teams with a way to reflect on how they work and become better at what they do. One of the main benefits of retrospectives is that they empower teams to define and make changes by analyzing what happened in an iteration and by determining what can be improved moving forward. Here at SoundCloud, we hold retrospectives at the end of every iteration (every two weeks), and we often do them at the end of projects as well.
Or, how to raise a project from the dead with tools you probably have lying around at home.
An absolutely crucial part of the experience of being an engineer at SoundCloud is learning and growing as a person. Pretty much everyone we hire mentions this aspect as one of their main motivations for joining the company. And while retaining highly talented and motivated people and helping them develop is naturally valuable for SoundCloud as a company, it’s also profoundly beneficial for the employees themselves.
Track play counts are essential for providing a good creator experience on the SoundCloud platform. They not only help creators keep track of their most popular songs, but they also give creators a better understanding of their fanbase and global impact. This post is a continuation of an earlier post that discussed what we do at SoundCloud to ensure creators get their play stats (along with their other stats), both reliably and in real time.