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
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.
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.
The Art of the Workshop for the Everyday Salesforce Consultant
Congratulations! Your organisation has recently partnered with a client who is looking to you and your team to undertake a new implementation project! Sales has sent through the signed contracts, your Project Manager has forecasted …
Looking Back and Leveling Up
The small, bootstrap operation that Sean (my Co-Founder) and I set up in early 2018 is now 3 years old! And although it feels like Mav3rik has been around a lot longer given how much …