When I joined Leapfrog, I was familiar with most of the tools that we’d use in our projects. So instead of starting from scratch, I was able to improve the skills I already had. But I’m not going to write about the tools because you’ll find enough tutorials on the internet. In this blog, I’ll walk you through the principles I learned throughout the process and how they made me better at my job.
Following standard practices
When I was doing my personal projects, I mostly didn’t care or cared little about standards and convention. But here, we follow proper coding guidelines and we do extensive Pull Requests reviews. This has helped me enforce best practices and good coding standards in my code.
Rewriting might be a bad idea
If I encounter a functional app with code that’s not easily understood, my instincts suggested I do a rewrite. This might not be a good idea because even if the code is not good, the app might still be functional. If you start a rewrite, you have nothing. Also, end-users do not care about the quality of your code. I also understand that a rewrite might be necessary at some point but most of the time, a good place to start would be to refactor the existing solution.
Gaining familiarity in a project
Before I joined Leapfrog, I had a hard time understanding code that other people wrote. Leapfrog is a huge company and has many projects that have been going on for years. So I was really curious and somehow scared about getting on in projects with a pre-existing codebase. I think now I know enough to navigate in an existing code base and tweak things a little and get things done.
Getting familiar with a project is easy if you start with taking small tasks on hand and making changes. Suppose you’re assigned on a project with a frontend on React and you have to increase the familiarity with the codebase. In this case, you can take small tasks such as a minor text change or a small styling fix or breaking down a component into a smaller component. While doing this task, you understand the variable naming convention in the project, the way files and folders are organized etc. This approach makes your familiarity with the code incremental and this approach never fails me.
You master tools slowly
I think it is obvious that mastery in something requires hands-on experience and a lot of commitment. This is more applicable in things like Git and Linux. I have learned more about Git by accidentally pushing applications’ secret keys stored in a .env file and searching solutions on StackOverflow about these kinds of similar issues than following a tutorial or reading articles on the internet. At Leapfrog, we use git all the time for version control. The mistakes that I have made the most are branching from the wrong base branch, using improper commit messages, adding unnecessary files on a commit, etc. Over time I have known how to get things right.
Final Thoughts
Working at Leapfrog, on a daily basis, we learn many small new things and over time, they contribute to our growth. However, they go under the radar if we’re asked to list the things we’ve learned at Leapfrog. Additionally, there are many things that cannot possibly be written in a finite number of words. To know them, you have to be a part of the Leapfrog experience.
Prashant also shares his code stories in his blog. Check out Prashant on YouTube as well!
*Interested to work at Leapfrog? Learn about our vacancies from our career page!
