.png)
You quit Salesforce when the going gets tough
If you're used to only learning via Trailhead, you're in for a rude awakening on the job.
You need to rely on other resources to help you solve real-world business problems.
When people face that reality, some will give up. They'll find ways to give their coworkers the work items they cannot figure out.
Giving up working on challenging Salesforce work robs you of countless learning opportunities.
In reality, there'll be times you'll have to synthesize information across different sources.
So, how do you stop quitting when things get difficult?
How to persevere as a Salesforce professional
Do the boring stuff, repeatedly.
It sounds corny, but when you condition your brain to think you'll find the solution eventually, you can operate in a much better state of mind.
For example, suppose you get a bug that takes puzzles you. You spend an hour triaging the problem. After that hour, you can decide to give up or keep investigating what's causing it.
You'd be surprised, but some people will give up and come up with excuses for not spending more time triaging the issue.
Don't give up so easily. Spend that extra time trying to find out what's causing the problem.
That brings me to my second point.
Know where to find information.
My favorite place to find answers to my questions is to look on the Salesforce StackExchange.
Several Salesforce developer and architect blogs have saved me more time than I can count.
By the way, are you interested in learning what it's like to be a Salesforce developer? Click here to read more about it.
Some Salesforce blogs to support you in your quest for knowledge
Salesforce Well Architected
If you're a Salesforce Developer or Salesforce Architect, you should be referencing Salesforce Well-Architected.
From their website:
Salesforce Well-Architected shows you what health looks like and where to spend your time roadmapping and designing solutions with the Salesforce Customer 360 Platform. It shares prescriptive guidance and examples of patterns and anti-patterns to look for in your landscape, based on knowledge from product teams and implementation experts throughout Salesforce and our ecosystem. Salesforce Well-Architected is organized to help you build solutions that are Trusted, Easy, and Adaptable.
Coding with the Force
What is Coding with the Force?
From Matt Gerry, the creator of the blog:
Welcome to Coding With The Force where you can find high quality development, administrative and architecture tutorials for the Salesforce platform! This blog exists to provide the Salesforce ecosystem an alternative way to learn the platform for free. So stick around, and if you subscribe, welcome to the Coding Force.
Interested in becoming a Salesforce Developer or growing your Salesforce development chops?He also has some excellent Apex content here.
How do you use it?
If you ever have trouble with an Apex concept - whether beginner or advanced - go here.
Salesforce StackExchange
How do you use it?
Whenever I have a tactical development or API services question, I type it in Google and inevitably there will be a search result where someone asked a similar question on the StackExchange.
What is the Salesforce StackExchange?
According to the website's definition:
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It only takes a minute to sign up.
You fight against changes in Salesforce and preserve the status quo
Why being resistant to changes in your CRM costs you
Quick story time.
Don't know what Visualforce is? Think of it as Salesforce's version of HTML. It was how Salesforce developers built UI components in Salesforce for a long time.
In 2014, Salesforce introduced Aura. It changed how Salesforce developers create customized UI components on the platform.
Fast forward to 2019, when Salesforce introduced Lightning Web Components. LWCs changed how Salesforce developers approached writing UI components again.
The point here is that Visualforce is an older scripting technology.
In any case, there was a Salesforce Developer named Mike.
Mike only wrote in Visualforce. He was on a Salesforce team that didn't want to migrate from Classic to Lightning. That is until Mike's manager, Erin finally decided to move to Lightning.
Erin assigned every developer some Visualforce pages to migrate to Aura components and gave them ample hours to do so.
Mike flat-out refused. It wasn't because he had concerns about feature gaps between Classic and Lightning. Nor was it because he has concerns about the feasibility of the project timeline.
Simply put, he didn't want to learn another technology and was adamant about it. He didn't want to lift a finger to learn about Aura, let alone Lightning Web Components.
Being unwilling to learn new things is the death knell for your Salesforce career.
Sure enough, Mike was fired and was looking for new Salesforce jobs within six months due to "performance reasons." The company terminated his employment because he didn't want to keep up with the times.
How to fix this mistake
Recognize that change is hard but necessary. I understand you could frustrate at the idea of always having to learn. But that's part of being in the Salesforce ecosystem.
Don't quit easily. Mike may have been scared to learn something new, and that's okay. The team would have likely been supportive if he had taken a little longer to migrate the pages to Lightning and would have helped out.
You blindly perform tasks without understanding or questioning the reasons behind them
Why it's a mistake
You need to understand how a customer uses Salesforce to serve their business.
If you don't ask follow-up questions to your stakeholders, then you're not going to learn this.
You won't form an opinion on how to scale the company.
In the long run, being a mindless ticket-taker is a net negative for the company.
How to fix this mistake
Flex the "ask more questions" muscle. You're taking business requests from people who need to learn how Salesforce works. They're not the expert. You are.
Why is the business doing this? What company/department goal does it serve?
If the solution takes a long time, is there a middle ground we can reach to solve 90% of the business case?
You over-engineer everything
What does Wikipedia tell us about what over-engineering means?
It's when you design a product or provide a solution to a problem in an elaborate or complicated manner. But there's a more straightforward solution with the same efficiency and effectiveness as the original.
Why it's a mistake
Over-engineering will blind you from a more straightforward and elegant solution.
What are some examples of over-engineering in the Salesforce ecosystem?
- You write an elegant solution in Apex when a simple Before Save Flow would have sufficed.
- You built a custom integration with an external system when the external system had one that existed out of the box.
- You build an LWC that does one thing better than an out-of-the-box implementation. You're ready to show the business this awesome thing you created. But, to your surprise, the company didn't care about that particular feature you built.
You spent development time on something that you thought the business might need. The company didn't need it and wanted something else entirely.
Then you spend even more time adjusting your solution.
How to fix this mistake
- Only write code or write configuration for problems you have.
- Don't focus on tasks that don't have significant business value. Partner with your business stakeholders to find out what's valuable to them.
- Have principles that guide you to a solution, but be moderate about tackling a specific piece of work.
You're afraid to make decisions
Why it's a mistake
Your design or implementation mistakes are negligible in the long run. What's important is deciding to take action and learn from the mistakes you'll make.
Are you afraid of getting your ego bruised because people might think you don't know anything?
Think about how bad it'll feel when your coworkers or employees get frustrated. They're frustrated in waiting for you to stop twiddling your thumbs and take action on finishing up that Flow.
What can you do to fix it
Time-box how you will spend on your approach to a problem. Whatever you come up with in that timeframe will be what you show to your teammates and management.
You might be wondering: "but what if it's not good enough?"
It's ok. It's better to present a half-baked idea that your team and management can see than to promise that you will deliver a fully complete idea 6 months from now. Your team will almost always prefer the former.
Example: I will give myself two days to think about how to tackle this Sales Cloud problem. After that, I'll give myself a day to propose a solution. Then I'll present my proposal to my team and stakeholders and ask for feedback.
But living in your head and never putting pen to paper will fare much worse for you.
Write down what it takes to get to a solution in bite-size tickets.
.jpg)
.gif)
