This year I started exploring Salesforce APIs—specifically the REST API—and it opened a whole new world of integration possibilities.

Even if you’re not writing full-scale integrations yet, understanding the basics helps you:

• Test endpoints with tools like Postman

• Support third-party vendors connecting to your org

• Build smarter automation using Named Credentials and External Services

One of the things that sets Salesforce development apart is the concept of governor limits—and once you understand them, you start to see the platform differently.

These limits aren’t there to punish you—they’re there to ensure the multi-tenant platform stays stable and fair. So now, instead of fighting the limits, I write code with them in mind from the beginning.

As I write more Apex, I’ve started building utility classes to keep logic reusable and easy to manage.

These classes don’t represent data—they represent functionality. For example:

• DateUtils for date formatting or calculations

• EmailUtils for sending templated messages

• ValidationUtils for checking business rules

By now, I don’t just write Apex that works—I write Apex that scales. That means one thing above all: bulkification.

Salesforce doesn’t like it when you loop through records and perform DML (like insert, update, etc.) inside the loop. So I always structure code to:

• Collect data in a List<> or Map<>

• Perform logic in bulk outside the loop

• Use Set<Id>s to query efficiently

Salesforce added switch statements in Apex, and I’ve started using them in place of long if-else chains. It’s made my code cleaner and more readable—especially when I’m dealing with picklists or status values.

One of the cleanest ways to make automation more flexible is by leveraging Custom Metadata Types.

I use them to store config-driven logic that would otherwise live in a Flow or Apex class. For example:

• Routing rules based on Record Type

• Default values by user role

• Display text for emails or UI components

Writing test classes used to intimidate me—until I realized they’re not about perfection, they’re about protection.

Now I see test methods as the gatekeepers that keep bugs out of production. For any class I write, I immediately create a test method that:

• Inserts test data

• Calls my method with known inputs

• Asserts the expected output

One of the questions I get from admins starting to write Apex is: What’s the difference between a class, a method, and a sub-class? It’s an important distinction that’s easy to miss when you're focused on just getting the code to work.

Here’s the breakdown:

• A Class is the container. Think of it like a toolbox. It can hold properties (data) and methods (actions).

• A Method is an action the class can perform. It’s like a tool in the box—each method does something specific.

• A Sub-Class is a class defined inside another class. It’s used for organizing related logic or creating structured data objects within a class.