5 Mistakes I made with uClimb
In today’s article I’m going to present some of my mistakes in my social climbing app uClimb, which I published about a year ago. I’m going to dissect my mistakes but also mention how these can be solved and avoided.
1. Repetition
When developing uClimb I had very little experience in clean code. If I wanted to retrieve data from my Server, I would create a new method unnecessarily multiple times. This led to confusing code that I am not able to understand even with my current knowledge. The solution to this small but at the same large problem is to plan your code in advance and build relationships with other classes. One could create Repositories and Managers to channel requests from the Frontend to the Backend. For instance, if a fragment requests a List of updated exercises it would have to use the Repository which then again passes the request further to the manager which extracts the information from the Room Database. By doing this, one avoids chaos and aids the future developer at their job.
2. I was too fast
When one is young(which I still am), one wants to finish things as fast as possible. In my case, I was the living proof of this theory. My code was messy, my app slow and my app performance was terrible. I was too focused on finishing the product, ignoring the fact that I was not building this to be fast but to make a cool social climbing app. This led to the fact that there were lots of bugs when the app was published. Furthermore, if I would want to continue that app, I would have to rewrite the entire code base due to the reason that It would be more work to refactor it. The solution: Don’t be young… Just kidding. The solution would be to experience this mistake first hand and not to avoid it. It’s inevitable that every coder must experience this mistake. This isn’t a typical solution, but it would be a bigger error not to learn from this mistake first-hand.
3. Structure your modules
I didn’t do this as bad as with the other flubs, but my directories were badly named and not quite correctly sorted. I had folders named “Adapters”, “Fragments” and “Main” but these aren’t well-thought-out titles for such classes. One should begin with more specific folders for the front- and backend of an app. I learned this from my past job at the startup Blloc(Develop incredibly aesthetically pleasing apps) who taught me a lot of my current knowledge about Android development.
4. Be a perfectionist
When one competes with approximately 2 million other apps in the Playstore one has to make the app as pleasing as possible to the user. This is the reason why one differentiates between UX and UI. One can have a nice design as Frontend but the interaction between the user and your app may still be very bad. For example, in uClimb I had a small bug that made it difficult for some users to login. My target group are German people who like to boulder & climb, naturally they would select Germany as their country. However, this wasn’t possible and made lots of users deinstall the app. For some unknown reason, which I didn’t care about when publishing the app, Germany wasn’t displayed to the user at login. This bug would have been very easy to fix if I had put a little more effort into the app at the finale coding marathon. Be more precise than I was, be a perfectionist.
5. Nobody cares about your app
I’m exaggerating a bit with this title but hear me out. Of course, my parents and other family members were incredibly impressed of this app. Nevertheless, they weren’t my target group and didn’t have any reason to install my app. Something that I did well was that I printed out two small posters with QR codes and stuck them onto a board at a known climbing gym in Berlin. These posters were somewhat efficient when gathering users, but I should have cared more about marketing and prepared more in advance. I could have easily gained more users if I either had welcomed another member proficient in marketing or studied more about that subject. Prepare yourself well in advance before making bad miscalculations.
I hope you liked this article and give me a quick clap. If you have any questions about my experience, code-base or some remarks about this article please write it in the comments.
