Embracing errors and bug fixes as part of your projects (Yes you did not fail … unless you stop)
Published: 2021-03-19 07:28:38

One of the reasons many take time to learn programming is they are learning alone. If you check the stats…most self-taught programmers take longer to become proficient enough to get a job. It’s faster if you have a personal mentor. That being said, learning to work your way through bugs is a vital skill every developer needs.

So you’ve started working on that project that you think will help you build your skills (and yes they do help you learn faster than watching tutorials). Perhaps you got the project ideas from a suggested project online, or you thought of a problem you’d like to solve. You excitedly started you project and set a timeline of when you will build features (Or perhaps the estimated time to complete the project was suggested for you). All too soon the reality dawns on you, you just can’t keep up with your schedule. You ran into build failures from your very first build after creating a new project even before writing any line of code. (Yeah, we’ve all been there). But the positive side is you learn from your error and may be moved to research deeper into things. Let me give an example.

I published some personal projects (android apps) to Google Play Store sometimes last year and the learning curve was phenomenal. But the major learning points came from bug fixes. I decided to build a Travel app and use Trip Advisor API for getting places data. Yes, you guessed it, I had to fix several bugs along the way as I tried to implement concepts I had learnt like dependency injection with Dagger and UI testing with Espresso. 

After a month and a half of labor and toil (..wipes sweats), I thought I was ready to publish the app (Yeepee!!). But as expected came upon a new issue I could not have known about if I did not publish the app…Make way for Proguard and R8. 
What’s that??
According to the developers' guide:
 “To make your app as small as possible, you should enable 
 shrinking in your release build to remove unused code and 
 resources. When enabling shrinking, you also benefit from 
 obfuscation, which shortens the names of your app’s classes and 
 members, and optimization, which applies more aggressive 
 strategies to further reduce the size of your app.”
In short...Android studio uses Proguard (now replaced by R8) to remove unused code from your project, thus reducing the size of your app. Also, it does code obfuscation, which shortens the names of classes in your app.
So what happened to my project?
Proguard was removing useful classes from my project’s release build. When I published the app, the release build kept failing even tho’ the debug build worked fine.
Long story short, I had to modify the proguard rules file. ( I had never worked with that file before then). 
So if you’re following the suggestion to build projects to learn, expect that most times things don’t go as planned, but embrace it as part of the process
If you want more to learn more about Proguard and R8, check out the developers guide [here](https://developer.android.com/studio/build/shrink-code) 
Speaking of project ideas to work on..check out DevProjects by [Codementor.io](codementor.io) . 
Also check out my projects on [Github](https://github.com/jtoguntoye)