A bit of history
During the summer of 2015, I was just a simple yet somehow seasoned developer. Seasoned enough to venture the world of CRM. At the time, I was not working on Salesforce but rather a CRM which was fully dependent on its own performant programming language. Let’s just say it was the Apex language for that system. It was old school, but performant nonetheless.
The language was the perfect niche in combination with my current skill set, or so I thought until I met a senior developer who has been working it from its inception. I was lucky enough to be working with this senior developer as she pointed out the flaws in my code style during a code review session. The feedback was harsh and unexpected, but the feeling of appreciation was there nonetheless.
Through the process, I learned the importance of optimising my code to the last character. I started to understand the significance of a binary search algorithm every time I need to manifest a query to locate my data. It is exciting. It is collaborative and eventually grew a data-centric maturity with the language by taking in feedback and always asking the question “what can I do better to enhance the current state of things?”.
Fast forward 2018-2021
The opportunity to take on another CRM has come and thus the knowledge of Salesforce has begun. The years have past but our knowledge outside of CRM has also flourish with the likes of Modern JavaScript, React and Functional Programming paradigms.
It was an exciting year to combine things, to do a conceptual remix with a then up and coming CRM that would eventually break the boundaries of modern CRM.
The interesting thing about being a developer while working on modern CRMs like Salesforce are the amount of opportunities it gives you in terms of use cases and high value clientele. At the same time, it is demanding of quality, and as a side effect of modern development practices go, there are a lot of ideas and opinions especially in code.
But how do we deal with good quality code?
The answer to that has always been with us since the beginning. Code Reviews ofcourse!
With code reviews come with coding standards or coding style guides like the one we made recently here: https://wearemav3rik.github.io/
What are these glorious and colourful texts of snippets?
Glorious Colourful Text Snippets
Coding Style Guides are guides for the developers in your team. At best, they are made public and shared across the community of developers, architects and anyone who likes to have an idea of how code is traditionally written.
They are not rules nor bibles nor walls of texts determined to scare off anyone trying to gain experience in the platform. They are guides and the purpose they serve is to guide developers in their journey.
They are also not the sole truth of how to code in the language, but merely a single path of exploration and combined efforts from developer contributions.
They can be better and there will always be something better.
A fair statement when you think about “what can I do better to enhance the current state of things?”
What can we do Better to Enhance the current State of Things?
A mentor of mine once said that there is a difference between feedback and opinions. Opinions are structures of data governed by what we read on a book, what we see on online blog posts, something from a youtube video or a recall from a past experience
Opinions can be flawed by a lot of things. They can be flawed by outdated information, fake news, or even hidden marketing strategies. They are the yangs of the yin on a session of relaying information.
Feedback on the other hand is yin of the yang. Its objective is self-less and never to the detriment of the addressee. The most effective feedbacks follow the ASK principles. Feedbacks are Actionable, Specific and Kind and yes I know, it can be some corny fluffy slogan, but truthful and effective nonetheless.
Comments in Code Reviews are more effective if the balance is achieve between Opinion and Feedback. They will be harsh and they will take a lot of your time, yet the fruits of that labour will be revealed through repetition. Repetition breathes consistency, and consistency becomes learning. I am sure humans are better than that as our kind has conjured artificial intelligence after all.
Judge, Jury and Executioner
Code Reviews are better with more developers on the team. However, a single developer on a team can be a victim of becoming the Judge, Jury and Executioner of Pull Requests.
But not necesarrily.
Sometimes you have to submit yourself to another type of review.
The better state of things is not just achieved through fancier code, but rather a feedback coming from a reputable source, like someone on the team who understands the solution. It can be a review of the entire solution or a quick demo of a feature from someone else on a team. Some form of betterment is better than the number of unexpected issues on production deployment day.
A Team that Trust is Team that Triumphs
Seek and you shall find feedback.
Code Reviews can be harsh but it is a collaborative process that not just benefits the quality of the product but a learning process for all parties.
To accept feedback is to trust your team mates and to trust your team mates is to never hesitate with their capability to review your code.
The beauty of passing the ball to a seasoned scorer is a guaranteed assist in basketball terms, but a seasoned scorer entrusting the ball to a young gun is anything but awe-inspiring.
You must log in to post a comment.