πŸ’ƒ Before You Start Coding ... πŸ•Ί

Maybe Your Lead Will Like You More If You Avoid These Things

Good morning, Salesforce Nerds! Thinking of striking out into the great unknown of Apex development? Before you do there are a handful of things to avoid at all costs! Unless you're goal is drive your lead up the wall we humbly suggest you keep these core Salesforce development principles in mind!

salesforce developer

Agenda for today includes

  • Before you start coding ...

  • Daily Principle

  • All the Memes

Before you start coding ...

The stage is set. You've had your eyes on dipping your toes into the proverbial Apex pool for months now. You just need to pluck the right user story. Suddenly, out of nowhere - BAM! You see the perfect story on the board and pull it into development. Your time has come, Neo. All that's left is to follow the white rabbit. πŸ‡ Just don't follow it down that rabbit hole.

Using Magic Strings | String values that are specified directly within application code that have an impact on the application's behavior.

Rule #1 for all development (I don't care what platform) is don't hard code stuff. Just don't. I know it's easy and you want to impress your Product Director with how quickly you can turn out your first Apex story. But, seriously, what do they REALLY care about? Scalability. Trust me, hard coded magic strings will not scale and you're lead will probably pull your voodoo doll out of their drawer and poke it in the eye.

Not Bulkifying Apex Code | The term 'Bulkifying Apex Code' refers to the concept of making sure the code properly handles more than one record at a time.

We already know about Salesforce Governor Limits. If not, step away from the IDE now and study up on this. Even for dev converts from different platforms - this is arguably the most important thing a Salesforce developer must understand. Don't perform DML in a loop, don't try to write your code in a manner that only works on a single record at a time. Everything your write must work on a collection of records. Period. If it doesn't you won't pass your code review and your lead will give you the side-eye.

One Object, Multiple Triggers | Having only one trigger gives us the power to control flow of execution, which in turn allows for easy management.

This can be an easy one to overlook or not know how to handle if you're new to Salesforce development. Do yourself and your team a favor here by doing a bit of research into how your organization writes/maintains their trigger handling mechanism. Then, follow suit. If you place multiple triggers on an object, just know there is no way to control which trigger (and therefore it's business logic) fires first. If you have questions here, ask your lead. Just don't go rogue.

Not Planning | First think, then code. That seems to be obvious. Do at least a little bit of design before coding.

A little bit about me. I'm a lead, myself. I've had countless devs send me a pull request to review that does address the business requirement, but the code is written in the most complex & convoluted way possible. All because they didn't stop to plan first. Someone who wants to build a house would usually not just start off by putting stones on top of each other without a plan. The same is true in software development. Remember, the best code is written away from the keyboard, so plan first. Just think of your leads face when you turn your story in with diagrams & wireframes to support your work!

No Development Standards | The important thing to remember here is that there is no good or bad set of styles, but only what works and what doesn’t work for your team.

Admittingly, if you're new to Apex development you're not going to be setting coding standards for the team. But, you're lead will be expecting that you follow the teams standards. This may take a bit more time, but check out the rest of the code base during your planning phase. If you're writing a trigger, what trigger handling mechanism does the team use? Find one or two examples then follow the standard in your story. Same thing if it's an Apex controller or a front-end LWC. Don't deviate and try to do your own thing. That will just create tech debt for your lead to deal with later down the road.

Daily Principle

β€œYou never change your life until you step out of your comfort zone; change begins at the end of your comfort zone.”

Roy T. Bennett

and now....Your Daily Memes

But First - refer a friend in the link at the bottom of the email and receive a Salesforce Salary Guide that includes salary ranges from 2019-2022 and how they may shake out in 2023!

salesforce developer
salesforce developer
salesforce developer

What did you think about today's newsletter?

Login or Subscribe to participate in polls.