Checking student projects after working for more than a year as an Android Engineer (Part 1)
I have been working as an Android engineer for more than a year now, I can say that I have learned a lot during that time and I was promoted a couple of times. I wanted to update my Github profile with a project for a blog post that I was writing at the time and I stumbled upon my old student projects. What can I say, it is a mess and a very unpleasant code to look at. But in some way, it made me appreciate my humble beginnings and the path that I have passed ever since.
I graduated from university 2 years ago, and at that time I already had an Android internship. I knew that I wanted to work with Android, but that was not always the case.
In this blog series, I am going to talk particularly about Android development, but most of these tips you can apply to any technology.
Follow language guidelines and use code reformatting
I was coming from a semester focused on C# development, Windows Forms, and UWP. The next semester I was starting my mobile development class in university, which was about Android. Even though I had completed a Java course before, I liked the C# style of opening and closing function braces.
So every time when I started a new Android project, override a function, or write a new function I would go to the function definition and put the opening brace on a new line. I am not very proud of this, and my course instructor wasn’t happy with the formatting of my homework assignments. Luckily that didn’t affect my final grade. Follow the language guidelines of the language that you are using, there are a lot of resources online and good examples.
Another important thing is to always have a very structured code. I cannot stress this enough but it is very important to learn the code reformatting shortcut of your IDE of choice and always reformat the code before committing or posting your code somewhere. Also, another tip would be not to have many empty lines between the code. I did this, a lot of beginners do this. I have seen a lot of Stackoverflow questions looking like that, it is very distracting and people may pass answering because of that.
Done is better than perfect, but …
In our primitive minds the reward for something new is bigger than to keep improving the ongoing thing.
I have read this quote somewhere and in my experience that has been proven correct times and times again. There is always a but somewhere if you think something for long enough. And the statement that I quoted should not be the case. Finishing a project or implementing a library that you wanted to try out makes you feel great, and then you move on to the next thing. That is how I have been working till now and this it is one of my regrets. I have started or cloned more than 100 Android Studio projects. They have been a very simple idea, trying out a new library or closing and completing some Google codelab source code. I don’t have a good and solid project that is a bit more complex, that I can show to a potential client or employer to prove my knowledge and skills. That is what I have been trying to improve lately, and I would highly recommend you to start very early. Add a particular feature to an old project even if it doesn’t make sense, it is your project and you get to make the rules. Here are some of the examples that I could think of: add a weather functionality to the note-taking application that you have built before or implement a Hilt dependency injection. It will help you improve your skills and you will always have something ready to show.
Another good thing about going this way is that you will always check your old code and you can have a particular feeling about your progress. So if you learn something new or see a better way to implement that, you can get back and refactor that code. By doing this your project will always be up to date.
If it works, it does not mean that it is correct
We are all happy when we see that our solution works, but it is always good to get back in the code and check everything all over. Some solutions are hacky and not maintainable in the long run because only you understand the solution. After a while, there won’t be anyone who can understand that, not even you. So always go back and make sure everything is correct.
I saw something embarrassing in one of my projects. It was the classic weather application when you learn how to connect to an API for the first time. There were 2 screens. The first one was a list of cities’ names and the second one was the weather information for the city that you select on the first screen. You could add a city by a simple popup and when you click a city in the list, the second screen was opened. An API was called on the second screen and the details were displayed. Everything is working fine on the “happy” path, but the problem starts when you test the edge cases. Let’s say you enter some nonce like “kqwoeiqwe”, then that is added as a city, it will be added successfully. When you click on it, a second screen is opened and there is a Toast message saying that there was an error from the API. Was this solution working — YES, was it correct — I would say NO. The correct approach would be to validate the city before it is entered into the list of cities. You won’t have nonce inside the list and later end up on the details screen with an error. The error could have been displayed when trying to enter it in the first place.
Maybe my example got you thinking about the recent projects that you worked on, so you better go give them a second look :)
This is my first blog and I have a couple more sections to add. But I was procrastinating on finishing the article, so I decided to make it a blog series. Hope you find this useful and I would like to hear your feedback.
Originally published at https://davidbojkovski.hashnode.dev.
