Fernando Cejas, Android Developer at SoundCloud

As part of the core engineering team, Fernando opens up the heart of SoundCloud technology and gives us a rare glimpse into how the berlin startup develops mobile apps. In detail, he explains the process developing an internal tool for real time measuring performance stats on mobile apps.

So, Fernando, what do you do at SoundCloud?

Officially, I’m part of core engineering, which means that most of the time, I don’t develop user-facing features. I develop tools for developers, and maintain our clients, which include mobile apps and web. The team is called core clients.

Can we start by talking a little about your background? Where are you from?

I’m originally from Argentina, from a town called Las Parejas. It was there where I began working on hardware, when I was around 16 years old. I’d always enjoyed setting up networks and comparing computers, and my first job — in Las Parejas local hospital — was to maintain their network and system. It wasn’t an official position. I was an apprentice alongside my school studies.

Later, when I turned 18, I moved to Rosario, Argentina’s second or third city, for university, where I studied software engineering. After a couple of years, I started working for a national beauty store, where I created their system for data, stock, and invoicing. That was a big challenge as a first project because I didn’t have much experience.

And you built that from scratch?

Yes. It was an interesting project, because there were so many moving parts involved. For example, there was a very old system in Cobol, which worked in both Unix and DOS, that we needed to migrate. Even with a partner, mistakes were made. And, because it’s Argentina, everything runs on Windows rather than Mac or Linux. The project presented so many challenges, and by the way, this was a long time ago, before agile methodologies. So we took a waterfall approach, which meant only having something to show at the very end of the project without continuous improvement and feedback. Today, there are many more iterative stages, which makes things more productive and easy.

These were the main challenges we faced when developing this desktop application in Visual Basic: any invoice or update would need to be reflected in all the stores in real-time across the country, which meant we needed to develop a system to replicate this massive amount of megabytes. At this time, the internet connection was very slow and we needed to compress the data — the logic of that was by far the toughest challenge, more than the UI.

Did you ever get your system to work?

It took a year and a half, but yes. When I felt that there was no longer room for improvement, I moved to Barcelona, where I lived for almost eight years. It wasn’t easy to leave Argentina, but we are very far behind in terms of technology. I hope this gets better in the future. In the meantime, I do not have plans to go back, although I try to contribute and collaborate with communities over there as much as I can.

I also worked for a couple of big companies in Barcelona, but soon realized that I liked working on startups. I joined a new venture, which took me to San Francisco for a year. I had very mixed feelings about the Valley, and I went back after the project did not go well. But I also have to say that I learned a lot (humans learn out of failures, not success).

Later on, I had the opportunity to join a startup around NFC technology called Flomio. So I moved to Miami for a few months. Things did not work out after investing time and money, so at some point with my pockets empty, I decided it was a good time to get back to Barcelona.

I needed a stable job, so I started working for a company called Tuenti. It was meant to be the Spanish Facebook, but it was impossible to compete with such a big player. We were eaten alive. Today, Tuenti has changed its business strategy and turned into more of a mobile operator with social features. It works well, and I still have many friends and people I love working there.

When I started to feel a little restricted by the work, I decided to go traveling for a few months. Right in the middle of my trip, I was approached by SoundCloud. I knew I liked Germany and music — I even used to be in a hard rock and metal band — so I flew straight from Japan to Berlin. Two years and eight months later, I am still here.

How did the kind of work you were doing change at SoundCloud?

I started as an Android developer, developing user-facing features, but over time I became more intrigued by deeper engineering. Now I develop tools, libraries, and frameworks for other developers, and my work is, in a sense, purer. It’s also beneficial that I share an office with the users, which are in my case other developers, so I can easily ask for feedback.

What project are you working on at the moment?

At present, there are restrictions on measuring performance on mobile clients. There are not many tools out there and real time performance stats collections is almost impossible. With that being said, we wanted to develop a tool internally that everyone could use to gather performance data, so we started working on this together with Google a few months ago.

We’re using Google Firebase, in order to achieve this. It does a lot, including analytics and developing your own APIs. It’s a good starting point, and much easier, so you do not have to create an entire ecosystem from scratch.

At first, we used a monitoring system called Prometheus, which began at SoundCloud. It is open source and we are using it to monitor our microservices infrastructure. Many other companies bet on it with the same purpose of collecting metrics coming mainly from microservices, but we couldn’t find a way to use it with mobile. Instead, we opted for Firebase, so we started partnering with Google.

And I suppose Google can use that data to improve upcoming Android versions, too.

Exactly. Their feedback is going in both directions. We have a big user base, which brings up big challenges in terms of data collection at this scale. Plus, this saves us time since we do not have to create an entire monitoring system from scratch.

How have you used it so far?

It’s all still in beta, and we’re only about halfway through the project. But we’ve already started measuring our app’s performance, and we are seeing some really interesting data around playlist length. One good example is the playlist loading time: We started to send a performance event to measure how long it takes to start listening to a playlist at a lower level, this means that we time stamp (start measuring) when the playlist is opened, and stop when the first song starts to play. It usually takes less than a second to load, which is pretty good in terms of user experience. But of course there is room for improvement, especially within edge cases of users who own super large playlists.

How are your team and processes structured at SoundCloud?

We don’t use any kind of agile framework. In my opinion, you shouldn’t play by the framework’s rules. Instead, the framework should adapt to your way of working. If you strictly follow what the framework tells you, you lose flexibility. The whole point of agile is to be flexible. Instead, we pull in elements from different process methodologies, let’s say scrum and kanban for example.

You shouldn’t play by the framework’s rules. Instead, the framework should adapt to your way of working.

We have planning sessions where we prioritise our tasks. Each platform — iOS, for instance, or Android — has its own tech lead, who will know which tasks to prioritise and to whom. They look at the big-picture. We also make sure we meet every week in order to be synced and know the need at a code level.

What are the steps in creating a new framework?

We usually create a document, called an RFC, which contains a technical proposal. This will include things like the context, the reasoning, as well as more technical aspects. We share it in Google docs so everyone can comment on each line. We’d perhaps share this document within a team or two, or maybe even within the whole company.

So everyone gets a chance to offer input?

Yes, everyone’s feedback is valuable but sometimes we want to keep the participation not very wide and only scoped to those most interested. We also have, what we call, collective sync meetings each week and it is split by platform (Android, iOS and Web). Any topic can be brought to the table. These meetings also offer the chance to gather feedback, listen, and generally catch up. This degree of transparency and communication is important.

So what happens after you get the green light to go ahead?

After planning, we create a list of tasks and get to work. We usually work in one-week sprints — two weeks tend to be too much for us, because of the pace. One week allows you to have something up and running, even if that’s just a simple API that other developers can use.

Who makes up your five-person team?

We have an engineering manager, who’s coding as well because he misses it so much. He used to be an iOS engineer. We also have someone who is maintaining our mobile API in Scala, but he can also code iOS and Android. He’s very multi-purpose, and very experienced. There are also two iOS developers, and me — I’m an Android developer. We might also pair with people from other teams, what’s called pair programming.

How do you find somebody for pair programming?

I’d informally ask around, maybe using the Android channel on Slack. Most of the time someone is free to pair. I prefer to do it informally because it means someone can join me later if they’re busy, and I can make a start by myself. Sadly, I’m too busy at the moment to answer other people’s requests.

What kind of problems did you stumble upon when you started coding?

When you’re working alone, you sometimes don’t see problems immediately. Before we commit any code to our master branch on GitHub, it needs to be reviewed by two other people. This means you might not get feedback on your code until much later. That’s another reason pair programming is good — each programmer will have their own keyboard, but share one screen. You constantly get feedback and solve the problems together.

What kind of tools do you use?

I use Android Studio, Intellij and Sublime. While Android Studio is the official IDE for Android development, Intellijel is more multipurpose. I use Xcode when dealing with iOS code, which is the official Apple IDE. I also use Slack a lot as a communication tool. But the most useful one is the browser — almost all of my tools, like JIRA, the Google Apps, Gmail, are web-based.

Is the performance measurement project open source, or are there plans to make so?

For now, it’s internal because the API is so specific to us. But this may change in the future. Everything usually begins as an internal project, and it will only be opened up if there’s potential. It’s happened before. But that will be a long way off, because we’re only doing the basics right now. We also want to provide other tools for other types of measurements.

What’s your workday like?

I have a pretty flexible job schedule. So, for example, on a Monday or Wednesday I’ll come in early, at 8.30am, because I have German classes. Otherwise, I usually come in at 10 am. It’s not fixed, but I always aim to be here for our morning stand-up meeting at 11 am. If I’m remote, I’ll call in with a tool called Blue Jeans. Before the meeting, I’ll usually review PRs, pair requests and other people’s code. Afterwards I’ll catch up on emails and start coding by picking up planned tasks and user stories.

Do you often work remotely?

I’m much more of a team player. I’d rather be around people. I like the atmosphere at the office, and how everyone’s playing music. For two or three hours of the day, I try to work at a standing desk. It’s pretty uncomfortable if you do it for a long time, but a few hours is healthy and good for your back. I don’t need much more: my Mac, an extra screen, and a few cables. I also like to drink mate at work — the real mate from Argentina, with a cup and a straw. No Club Mate for me, though. It’s too sweet and very far away from the real one.

What important trends and developments are you seeing right now?

I think that scalability is pretty important. It’s not something people think about in startups. That’s even important at SoundCloud: we face a lot of challenges related to scalability because we have millions of users. It’s important to have solid architecture, code consistency, and smooth team working if you want to scale effectively.

What would you say to students or graduates who are trying to get to where you are?

It’s easier than ever to find out about new technologies online. For example, GitHub is full of open source projects. You must read other people’s code, but also contribute and open source your own code when possible. This might be daunting, but getting feedback from other people is the best way to learn. Even if you send a pull request that is never merged, you’ll still learn something.

Getting feedback from other people is the best way to learn.

I also recommend Twitter for communicating and sharing technical information, and the Android Weekly, a weekly newsletter. In terms of books, I recommend Clean Code, and an old one called Pragmatic Developer. This is Microsoft’s book, and offers advice on problem solving.

But, most importantly, you should have a good work-life balance. Although I’m very passionate about technology, it’s also vital to communicate with people and have friends, because we developers can be pretty introverted. Traveling, especially, was a real game-changer that benefited me both professionally and personally.

Fernando, thank you for the interview!

This interview was held on 4th of July at the SoundCloud Office in Berlin.