Let’s rewind to my early days as a Salesforce Developer.
I had no idea what I was doing.
Just me, my Trailhead badges, a few Apex classes…
…and a whole lot of hard-coded IDs (oops 🙈).
🎯 1. Learn the Why Before the How
What I did:
I jumped into learning Apex triggers and Visualforce like I was on fire.
I could build stuff, but I didn’t know why Salesforce did things a certain way.
What I’d do instead:
Start by learning Salesforce fundamentals:
- Why multi-tenant architecture matters
- The concept of metadata-driven platforms
- Sharing rules, governor limits, OWD
📌 You can’t build well if you don’t understand the platform you’re building on.
🧠 2. Stop Hardcoding Everything (Please)
What I did:
I hardcoded RecordType IDs, Profile Names, and even User IDs, like it was a badge of honour.
It worked in dev, broke in UAT, and nuked production. 😅
What I’d do instead:
- Learn about Custom Settings, Custom Metadata, and Dynamic Queries early on.
💡 Think: How can I build this so it works in every sandbox, even 6 months later, when I’m on a different project?
⚖️ 3. Master the Clicks vs Code Balance
What I did:
I built EVERYTHING in Apex — validations, workflows, automations.
If it moved, I coded it. 😎
What I’d do instead:
- Understand when to use Flows, Process Builder (or Flow now), and when to fall back on code.
- Embrace the “Clicks Before Code” mindset.
📍 Code is not a badge of honor.
Maintainability is.
🧪 4. Write Tests Like They Actually Matter
What I did:
- Wrote test classes to “get to 75% coverage”
- No assertions.
- No negative cases.
- No sanity.
What I’d do instead:
- Learn test-driven thinking from Day 1.
- Focus on meaningful test cases — not just coverage.
📌 Test classes aren’t just a Salesforce requirement.
They’re your insurance policy.
🧰 5. Invest Time in Dev Tools & Productivity
What I did:
- Used only the Developer Console (😬)
- Thought VS Code and SFDX were too “complicated”
What I’d do instead:
- Set up VS Code + Salesforce Extensions early
- Use tools like:
- Prettier for formatting
- PMD or CodeScan for static code analysis
- Salesforce CLI for speed and version control
⚡ Being fast doesn’t mean being sloppy. It means knowing your tools well.
👥 6. Pair With Admins and BAs More Often
What I did:
Sat in my dev bubble and built what I was told — no questions asked.
What I’d do instead:
- Sit with Admins and ask why they want a field or a flow.
- Ask BAs about the business process, not just the technical spec.
💬 Understanding the “why” behind the “what” turns you from coder to consultant.
🧱 7. Learn Data Modeling Like It’s Your Superpower
What I did:
- Created objects for everything
- Ignored standard objects because they looked “basic”
What I’d do instead:
- Study the Salesforce standard schema
- Understand junction objects, lookup vs master-detail, and reporting implications
📐 A bad data model is like a weak foundation. The app will collapse eventually.
🤯 8. Ask More Questions (Even “Silly” Ones)
What I did:
Nodded in meetings even when I didn’t understand a thing.
What I’d do instead:
- Ask “why are we doing this?”
- Ask “is there a better way?”
- Ask “what happens when this fails?”
💡 Smart developers don’t know everything. They just ask better questions.
🔁 9. Think in Versions, Not Fixes
What I did:
- Fixed bugs quickly — directly in prod (😨)
- No version control, no rollback, no trace
What I’d do instead:
- Use Source Control (Git, Bitbucket, etc.)
- Adopt DevOps mindset early
- Deploy with change sets or CI/CD — not copy-paste Apex
🚀 Think like a product team, not a fire-fighting hero.
📈 10. Build With the Future in Mind
What I did:
- Built features just to “make it work” today
- Never thought about scale, upgrades, or reusability
What I’d do instead:
- Design as if someone else will take over next month
- Name fields and variables for clarity, not cleverness
- Use frameworks and design patterns from Day 1
🌱 It’s not about how fast you build. It’s about how long it lasts.
📌 TL;DR – 10 Things I’d Do Differently
| Then (🤦♂️) | Now (✅) |
|---|---|
| Hardcoded IDs everywhere | Dynamic & Metadata-based logic |
| Code-first mindset | Clicks-first with thoughtful fallback |
| Test just to get 75% coverage | Test for quality, coverage comes later |
| Avoided Git and CLI tools | Embrace SFDX, VS Code, and Git early |
| Worked in silos | Collaborate with Admins, BAs, QA |
| Created too many custom objects | Reuse standard, model wisely |
| Feature-focused | Process & platform-focused |
🧠 Final Thought
If you’re just starting out as a Salesforce Developer — awesome.
You’re in one of the most versatile, rewarding ecosystems in tech.
But don’t rush.
Take the time to understand the platform, the business, and the people behind the tickets.
Because being a great developer isn’t about how well you write code.
It’s about how well you solve problems — and how gracefully your solutions survive the test of time.
Salesforce Developer, Salesforce Developer, Salesforce Developer
