Reflection on This Past 3 Months
Cause seriously, I don’t know what I should write right now
Unlike my usual blog, I won’t really write anything technical related to MeetU-Engineering. I’ll try to write what I’ve experienced this past 3 months. Those sleepless, tiring, but enjoyable times. I hope that my experience in somewhat being not-really-official lead hacker can be interesting.
Before MeetU-Engineering
Well, I have no experience in developing any mobile app, so basically I don’t know anything about it. I also don’t know anything about CI (Continous Integration), other than it is very helpful in doing development. My knowledge in software development is very shallow, it’s only based in my experience in previous internship.
Now?
Well, now I know that I still know nothing.
The world of Software Engineering is very fast. I mean, it’s a constantly evolving world, where when you struggle to learn new stuff, something cooler will came out. However, it’s also a very fun world, as we have the opportunity to explore unlimited ideas.
With MeetU-Engineering
One of my very first task to do was making the CI script for our project. Okay, at that time, I don’t even know what .yaml is. In the end, I looked for example .yaml script, and edit it to conform with our project. Then, I tried to understand it, and phew, now I think I can write a better CI script.
Next thing I handle was backend-ish thing, as I hate frontend. I wrote things in Django for making Time Recommendation, etc. As our product, MeetU, is more UI-heavy, I have to “change direction” to frontend. At first, I disliked doing it as I found it mostly boring, especially doing .xml stuff. In the end, after having to do it for 3 months, I think doing frontend is not really bad at all; In fact, it is amusing when I have to think the best way to make users not angry with our application.
Okay, let’s talk about me being being not-really-official lead hacker.
Despite having 0 experience in Android app development, I somehow become not-really-official lead hacker. Probably because everyone else also have 0 experience. What did I do? Well, study, study, study. Basically, most of the time it is something like this:
We have to implement something
Crap, no one in the team have done it
Damn, I have to do it
Then I researched, finish the task, and after that, similiar tasks will be solved in similiar pattern as I did it.
Basically, I have a major responsibility on exploring how is the best way to tackle some problem. The good thing is, it gave me opportunity to explore a lot of things, so I had a lot of fun.
Next, let’s talk about Code Review and QA Testing
One of the requirements for the task to be called done is when 2 other members reviewed your code. Let me tell you, it’s ANNOYING AS HELL when your work is blocked because no one reviewed your code. As I don’t really want others to experience that, I’ve always tried to review almost every merge request, that you can see that I appear in almost every merge request.
Okay, we don’t have QA testing in our requirements, but it turns out to be important. I meant, some code passed review. Really, they looked good. When I tried it? Boom, not working as expected. Damn, I have to fix that. A major example is when we have an unscrollable list, and I have to fix it, then notify everyone in the team to test everything that may “break the screen”.
In the end, usually I ask Luthfi to do testing thoroughly, report it, and let someone fixes it. It works rather well, these kind of commits shown above doesn’t happen again lately.
Next, let’s move on how to maintain the productivity on our team.
As I’ve said before, in PPL course we have to use physical scrum board to maintain our progress. Ugh, disgusting. It’s very annoying when I found a problem, or idea that is on lower priority, yet can improve our product, yet I can’t put it in the board. Or, as the board is left in the campus, it’s rather hard to take care of it. So, I maintained gitlab board for that. You can take a look here, it’s much more helpful than the physical scrum board that I wish I can burn.
In Sprint 1 to midway of Sprint 2, usually we “struggle” to get some task so we can get points for part B of our individual review. However, midway of Sprint 2, and on Sprint 3, I said “let’s try to maximize our potential”. And so, for example
- Ricky only handled backend
- Luthfi only handled most UI-related stuff
- The rest handle frontend-related stuff
Focusing like this actually make our work faster than before, to be honest.
Last but not least, one part that is very important is communication. Though, I’m very lacking in this department :(( It’s important to communicate properly, so your colleagues don’t get the wrong idea. One example is this commit
I think after going through MeetU, my communication skill increased slightly.
Conclusion
Developing MeetU is a very long journey. There may be ups and downs, sleepless nights, burnouts, etc. However, all of them has been a very important experience for me, that I think can help me a lot in the future.
Thanks PPL course for the opportunity, I hope the course can get better next year :) Also thank you for MeetU Engineering team, for having someone like me in the team :”)
Ciao!
