15 Years on Salesforce: What I'd Tell My Day-1 Self

I started on Salesforce in 2010. Lightning didn't exist. Apex was on API version 18. We deployed by hand-merging change sets and clicking "Deploy" through the UI. The platform has changed enormously since then, and so has what I think makes a good engineer on it.

If I could pass a note back to the version of me who logged into his first sandbox, it wouldn't be technical. The technical stuff I've forgotten and relearned three times — Visualforce, Lightning Aura, LWC, OmniStudio, Einstein, now AI-native. The lessons that stuck are about how to operate, what to invest in, and what to walk away from. Here's the list I'd hand over.

Don't Confuse Activity with Progress

Day-1 me thought billable hours were the metric. Closing tickets, writing tests, completing user stories. The longer I worked, the better I was doing.

That's wrong. The metric that actually mattered was whether the org was getting easier to maintain or harder. Some weeks I closed twenty tickets and made the codebase worse. Some weeks I closed three and refactored a trigger that had been costing every future change. The org-level health was the real KPI; the ticket count was a vanity metric.

I noticed this only after inheriting orgs from people who had been "highly productive" for two years and left a smouldering wreck behind. Productivity that doesn't compound is just motion.

Write Less Code Than You Think You Need

The instinct on day one is to solve every problem with Apex because Apex feels powerful. Custom triggers, custom controllers, custom batch jobs, custom REST endpoints. It works. Then you become the person who maintains it forever.

I learned to ask, in this order: Can config do it? Can a Flow do it? Can the standard platform do it? If the answer to any of those is yes, that's the answer. Apex is the last resort, not the first.

There are exceptions — multi-object orchestration, integration callouts, complex computation. Those still need code. But probably 60% of what I wrote in my first three years was Apex that should have been a Flow, a validation rule, or a sharing rule. Future me has spent a lot of years quietly deleting that code.

Optimise for the Person Who Joins After You Leave

Every architectural decision has a half-life. The clever pattern I'm proud of today is the cryptic pattern someone curses at next year. The trick is asking, while you're writing it, whether someone with two years' less experience would understand it without a diagram.

This is why I default to boring. Single trigger per object, named the same way every time. Standard naming conventions. Custom metadata for configuration so the next person doesn't have to deploy code to flip a flag. Comments that explain why the unusual choice exists, not what the code does. None of it is novel. All of it adds up.

The trigger framework I've described before is built around this principle. The framework isn't impressive. The discipline of using it consistently is.

Certifications Are a Floor, Not a Signal

I have 25+ certifications. They opened doors early. They've never won me a project once I was through the door.

What wins projects is being able to talk about a real org you've worked on, the trade-offs you made, and the things that broke. Certifications get you the meeting. Stories from the field close the deal. If you have to choose between studying for another cert and shipping a side project that does something real, ship the project.

The CTA chase is the version of this that's bitten the most people I know. Two years of study, multiple attempts at the review board, and afterwards they still need to build the same kind of credibility every other architect needs. I stopped pursuing CTA when I realised the time would be better spent building things that demonstrated the same skills directly.

The First Year of an Org Sets the Next Five

I've inherited orgs where someone made a decision in week one — the wrong field type, the wrong sharing model, the wrong record type strategy — and that decision constrained every subsequent project for years. Not because it was unfixable, but because fixing it required more political will than anyone could ever muster.

When you're starting a new implementation, the early choices have outsized weight. Write them down. Defend them. Get them right or get them right enough that they bend later. The half-built decisions that nobody documented are the ones that ossify into permanent fixtures of the org.

Day-1 me was happy to defer decisions to "later when we know more." Most of those decisions were never made consciously. They got made by accident through the first thing that shipped.

Trust the Audit, Not the Documentation

Every org I've inherited has documentation that diverges from reality. The Confluence page says all triggers go through the framework — but three triggers were added directly to objects without the framework. The architecture diagram says Salesforce talks to Xero through middleware — but a developer added a direct callout in 2022. The data dictionary says the External_Id__c field is indexed — but no one filed the support case.

The fastest way to understand an org is to query its actual state. SetupAuditTrail. ApexClass. CustomField metadata. The metadata API tells the truth; the wiki page tells the story someone wanted to be true. When I do a health check for a client, I read the metadata first and the documentation second. The gap between them is usually where the bugs live.

Async Is Underrated; Calls Are Overused

Day-1 me thought consulting meant being on a lot of calls. Standups, design reviews, stakeholder meetings, status updates. The senior people on my projects were on calls eight hours a day.

Now I run my consulting practice mostly async — written briefs, asynchronous reviews, recorded walkthroughs. The work is faster, the deliverables are better documented, and the clients get to consume my output on their own time. Calls happen when they're genuinely the cheapest way to converge — not as a default mode of communication.

If I'd known earlier how much output the average call destroys, I would have pushed back on the meeting culture much sooner.

The Platform Will Change Underneath You

In fifteen years I've seen S-Controls deprecated, Visualforce relegated, Aura quietly replaced, multi-currency added then largely ignored, Process Builder built and killed, Workflow Rules declared dead. Anything you build today will be running on a different version of Salesforce in five years.

This sounds depressing but it's actually freeing. It means there's no "right" architecture for all time. You make the best decision you can with what's available now, and you build flexibility in for the parts you know will change. The orgs that hold up best aren't the ones that picked the most futureproof technology — they're the ones that minimised lock-in to any particular feature.

Practical version: avoid building load-bearing logic on features that have a "deprecated soon" smell. Workflow Rules, Process Builder, Aura — when Salesforce signals a successor is coming, don't fight the current. Migrate.

What I'd Skip Entirely

A short list of things that took me time to learn weren't worth the time:

• Memorising every governor limit. Look them up when needed. They've changed.
• Building "frameworks" for things that don't repeat. A framework for one use case is just a more complicated version of the use case.
• Polishing demos for stakeholders who weren't going to buy in anyway. Read the room earlier.
• Generic admin tools that "save time" but only get used twice. Just do the thing twice.
• Defending pet patterns past the point they were useful. The patterns aren't the goal. The org is the goal.

The One Thing I'd Double Down On

If I could go back and tell day-1 me to invest harder in one skill, it'd be writing. Not blog writing — internal writing. Architecture decision records, design documents, post-mortem write-ups, code review comments that explain reasoning rather than just demanding changes.

The best engineers I've worked with weren't the smartest in the room. They were the ones whose writing made everyone else smarter. Their architecture documents made design reviews shorter. Their code review comments turned junior engineers into senior engineers. Their post-mortems prevented the next incident.

It's the highest-leverage skill on the platform and the most underrated. Day-1 me would have rolled his eyes. Fifteen years in, it's the thing I most wish I'd taken seriously sooner.

The shortest summary: build for the people who come after you, write things down that would otherwise be lost, and don't confuse activity with progress. Most of the rest you can figure out on the way.