The Crash That Taught Me Perseverance

My first full-time job after university threw me straight into the deep end. The team was working on a mobile SDK that would allow remote screen sharing and interaction — something like TeamViewer, but built for Android and iOS. I had written a few Android apps before, but this was my first enterprise software job.

My colleague who started the project and was leading the iOS side went on vacation the day before I started, and for the next 4 weeks I had to dive in what has already been implemented on my own. I ramped up the Android part and the integration mostly by inspecting his iOS code. It wasn’t easy without any intro, but I could figure it out soon. We were using WebRTC, which had to be compiled from source, and I had no prior experience with JNI or native Android builds.

The build process itself became a project, that was unexpected. No precompiled jar worked out-of-the-box. So, I set up a dedicated Linux VM on an old PC to compile WebRTC for multiple ARM architectures. A full build took over 10 hours — and many attempts failed due to space issues (if i remember correctly, the build files took 130GB tmp space), network drops, linking errors, etc. I even hat to build the build tools…

During daily standups, I kept reporting: “Still compiling.” I could see the doubt in people’s eyes. It felt like they thought I wasn’t up to the task. It took me weeks to produce a working JAR.

A Simple Question, A Difficult Answer

Alongside that, the company wanted to grow quickly. I was asked to help with hiring junior developers. I remember preparing a small Java project with an intentional exception in the main() method. The task was simply to run it, read the stack trace, and fix the error (i.e. removing/commenting the throw()). Far from any leet-code, design talking, problem solving, etc. Many couldn’t even open the IDE properly. It was humbling — I was told to stop being so “unrealistic” in my expectations — even though this was the most simple challenge I could think of.

One junior joined our team and introduced many libraries to speed things up. The APK size grew to over 300MB. We talked about it, and I showed how we could replace much of that with handwritten helper methods. We got the build down to 15MB — much more suitable for low-end devices. Years later, that colleague told me I was the one who taught him “the difference between coding and engineering.” That stuck with me.

The Bug

But the part that stayed with me the most was the screen rotation crash.

Whenever the screen was rotated, the app would crash. It took me a long time to isolate the issue. I traced it through Java, JNI, and into the native WebRTC code. Eventually, I found a memory leak in a fragment shader — the old shader wasn’t properly cleaned up, which caused a segmentation fault on rotation. It was deep inside Google’s WebRTC code.

I patched the shader cleanup in C++, recompiled WebRTC, and the crash was gone.

I was proud of that fix — not just for solving it, but because I didn’t give up. I even opened a bug report in the WebRTC issue tracker (Edit: yay, I’ve found the old ticket! Check here: https://bugs.chromium.org/p/webrtc/issues/detail?id=6956 / https://issues.webrtc.org/issues/42232043). It was marked “Won’t Fix” years later, because a new version of WebRTC took a different rendering approach.

After that, I gave a postmortem presentation. I explained the root cause of the crash, how I tracked it down, and how I fixed it – and why it took me so long: it was really hard to fix. Unfortunately, most of the room did not understood the technical depth, even after I explained it. And my boss did not realize the difficulty, so he continued thinking that I’m just incapable and slow. That was hard — knowing you did something meaningful, but feeling like it didn’t land, and get no support.

The Test

At the final project demo, the app was tested on a very low-end Android device. In contrast to iOS, Android apps need to cover a much wider hardware spectrum – from cheap to high-end. Someone rotated the screen repeatedly — to see how far it could go and if the former bug is truly resolved. It would have even been hard for a high-end device (every time, the streams need to be stopped, shaders, etc. need to be deregistered, cleaned up and reinstantiated and finally the streams need to be resumed). These actions were the most processing-intensive. It had crashed before. Now it didn’t.

Eventually, the phone itself began to slow down, and system messages appeared notifying the user of app crashes. For a few minutes, we saw nothing — until the stream suddenly recovered. My app had survived. Every other process had crashed. Mine hadn’t. And it recovered and kept streaming.

There was a quiet moment in the room. With iOS, you usually don’t have these challenges, bc. the hardware is usually decent. I’ve found that time, that I might not be as incapable as assumed.

What I Took From It

The project never launched. It was handed over to the sales department, and for various reasons, never made it to production. That part was disappointing. But what I took from it stayed with me much longer.

I learned how to debug across layers of abstraction. I learned how to deal with the unexpected and clearly the unknown (debugging an fixing google code in my first year after graduation was clearly nothing I had expected to do. Plus: actually, thinking of it today, I’ve spent a lot of the time it take to fix the issue und doubting myself that I must have misunderstood sth. bc. there can’t be a bug in google code). I learned to keep going when no one else sees the problem yet. I learned to write software that doesn’t just work on sunny days — but recovers, survives, and endures, even through stormy seas.

It was the first time I realised that perseverance is as much a part of engineering as skill. I learned to dig deeper. To trust what I see, even when others don’t believe me. To stay calm when nothing works, and to take pride in quiet victories.

Even if it never launched, I’ll never forget that feeling: seeing my code survive when everything else crashed. And that sometimes, your code will speak for you — long after you’ve stopped defending it.