Solving crashes, can that become easier?
If there's anything time-consuming while developing apps, it can be solving crashes. Sometimes, it's super hard to know where a crash happened, and you're unable to reproduce it yourself. Marking an issue as "can not reproduce" becomes tempting, although you know you will still see the same reports coming in.
It's ironic to see Bruno opening with
Closed: Cannot Reproduce in his article solving crashes. It tells us that we're all experiencing the same!
At WeTransfer, we spent a lot of time improving our processes for efficiency. As engineers, we work closely with our support team, trying to find improvement points to save time-solving issues in the short term future.
As a result of this, we released
Diagnostics 2.0 this week. The detailed logs, error reports, session filtering, MXMetric logs, and exception summaries have allowed us to solve issues much faster.
Even better: due to the detailed logs, our support team often doesn't even have to reach out to us since they know what's going on for a specific user.
I'm not asking you all to integrate Diagnostics into your projects (although you wouldn't regret doing so), but I do want to point out that it's essential for you as a developer to rethink processes over time. Teams are evolving, and so are routines. If you can save time on solving issues, you'll have more time to build excellent features.
Enjoy this week's SwiftLee Weekly!
