KEY LESSONS FROM MY INTERNSHIP AT MELIORA TECHNOLOGIES
I am a product of the Meliora Academy. I joined the team with the desire to learn and help the team. The team did not fail me, I was given room to learn and the opportunity to help the team. By the time I finished my first project, I could feel the effect it had on me already. I was feeling more confident everyday. For the first time I had worked on a project from the requirements gathering phase to deployment.
The journey has been good so far owing to the support and encouragement I received from the team in Meliora. I have learnt so much from the experiences I have had while working as an intern. I will explain the 7 key lessons I have learnt over time.
1. User Requirements Come First
My definition of a good software was one that blew the minds of users with ‘cool’ features. I thought that that was what made a good software.
To my surprise, that is not even important. All that users want is for you to solve their problems. By doing user stories, I realized how much user requirements were a priority for every project.
2. Test Before Sharing
Have you ever been stuck in a loop where something is not working as expected and you can’t do anything? I can confirm it is frustrating to be in such a position.
This is what happens when you share something that doesn’t work as expected to someone who is supposed to consume it. You end up getting into the frustrating loop where the other person can’t proceed.
Never imagine that it is going to work. Always test out all the scenarios for which a failure is expected. This will prevent back and forth situations that are going to eat into time.
3. Sharing Makes You Better
A candle looses nothing by lighting another — sharing what you know with others makes you even better at it.
The Natujenge Initiative which is run by Meliora is all about sharing. It has been very transformative for me.
4. Ask The Right Questions
Ask questions — There is nothing wrong with asking questions. I learnt this the hard way. I misinterpreted requirements and did something that was completely off.
Had I taken time to ask questions, I would not have gone so off from the requirements. It is always good that you get it right from the start so that you do not do your own things.
This also calls for you to be keen in the planning and design phase. Most of the things are discussed here and if you are not keen enough, you might end up misinterpreting requirements.
5. Break Down Tasks into Sub Tasks
If you want to be effective, just get sub tasks out of the task in hand. Working on a sub task and completing it will motivate you to even complete the next. This way you will have closure on your tasks.
At times, I had tasks that took me longer than expected. This was because I was looking at them as a single task — breaking them down into smaller problems and dealing with each helped me crack them with ease.
6. Knowledge is all over, Read
You can implement absolutely anything. The trick is reading. There are resources all over the internet that can help you get an understanding of any concept.
Having gone through each page of the HTTP RFC, I have realized that so much is abstracted by the frameworks we use everyday.
7. Automate the Repetitive Tasks
Doing a task over and over again can be exhausting. It could be a database backup that you do everyday — automate it.
This will allow you to focus on other things that need more of your attention and save you from the worry of forgetting to do the task.
These are some of the lessons that I have learnt over my internship. It has been an experience full of lessons. I believe these lessons will help someone in having a smoother transition.
While still doing my internship, I also attended Natujenge Sessions. Natujenge is a program by Meliora aimed at empowering the young developers like me. Natujenge was transformative for me.
My key takeout was that even the most complex systems are made of simple blocks that work together to achieve something. Simple models work together to power the very complex models that we see. It led to me appreciating architecture diagrams.
