On the road to becoming a developer, creating your own projects is on of the best things you can do to learn by applying your knowledge. However, nothing can compare you working on a real life application. I am now a full stack web developer at a small company based in Johannesburg, South Africa called CAN Infinity. We’re currently working on an application called Earn Eezi, which due to circumstances, I’ve found myself the sole person in charge of the development, deployment and support of the application. Here’s a few lessons I learned while working on the app.
We had a little bit of a hard time with this part as the spec of the application changed as an opportunity popped up. The app went from being a type of sales platform and CRM to becoming more of a membership manager which would manage clients’ and their incidents.
This created a bit of chaos as some of the work and planning that was done was redundant, while features took a while to setup because of the initial setup of of the application.
Going forward, I would want the goals and outcomes to be defined and approved by all stakeholders, before a single line of code has been written. This will ensure that any confusion is avoided and short comings are fixed before the app goes into production.
Changes are inevitable and having the right architecture (file system, rules and guidelines) will help you react to any changes.
Once again we fell short of this as we picked the N-Tier approach instead of something more domain driven. This hindered some of the app’s scalability. It also caused issues with new updates as one change could break the whole system.
What made matters worse, was a lack of outlines to show what went where, causing a lot of inconsistencies with the way the application was written.
Rule of thumb: Automate repetitive tasks.
One of the most repetitive tasks that came up was deploying the app (backend hosted on Azure and frontend on Firebase) after changes has been made and synced up with GitHub.
We combatted this by setting up an automation on GitHub so that every time a new commit is added on the main branch, the changes would sync up with Azure and deploy that app.
This helped save a lot of time and frustration, but also prevented an issue where the main branch of our repository isn’t synced with the live version of the app.
Communication is one of the most valuable things to getting things done. Learning how to communicate progress, challenges and issues to your team and stakeholders will save you a lot of problems in the long run.
One short coming we had was with a meeting with a potential partner to work on our application. They wanted the ability to add multiple vehicles under a single product. And while this was possible, we didn’t showcase this feature in a way that they understood leading to a lot of confusion.
With a small patch being made, everything was ironed out and we cleared out everything at another meeting.
Being able to communicate both verbally and non-verbally (written) helps save a lot of misunderstanding and can fast track progress on updates and issues.
No system works on the first try.
One of the short comings I had was trying to find all the bugs and issues during development, and while I accomplished a few things, it was not match to the bugs that popped out of thin air when users started getting involved.
The users are some of the most valuable assets you have when creating an app. This is because they are people, they tend to use the application in different ways and their feedback can help you identify pain points, bugs and errors in your application.
An important thing you have to do though, is managing user’s requests and issues. Implementing a bug tracking/ticketing system can help you stay in control of everything as it’s easy to get overwhelmed with incoming requests from users.