Having spent a little more than a year learning about Salesforce, and almost a year working in the Salesforce ecosystem, I’ve come to understand what it means, in various skill levels, to be a Salesforce developer, or rather, a developer working in the Salesforce ecosystem. This blog post will explore the typical path of becoming a Salesforce developer as a Salesforce admin, then will explain any disparities between that path, and the way I became a Salesforce developer, by working as a general software developer first. Coming into the Salesforce ecosystem with software development experience from outside, I believe, that Salesforce developers can stand to become better developers and make great progress in their career if they spent some time understanding what it means to be a software developer outside of Salesforce.

Many current developers started their careers working for a number of years as a Salesforce Admin, and saw Salesforce Platform development as progression in their Salesforce careers. The developer certifications, Platform Developer I and II, and the latest one, JavaScript Developer I, help guide and provide the baseline of knowledge and understanding expected from Salesforce developers today. And yet, I’ve heard of, and experienced the work of Salesforce developers that have felt subpar from my understanding of what constitutes good work as a software developer. Having studied towards earning Platform Developer I and II myself, in my experience, the material covered is considered the fundamentals that will get you a junior developer role in the general population of the software development world. Having worked in Salesforce development, I have seen that there is a great need for the knowledge and skills covered in studying for the Platform Developer II certification. To give you an idea, to pass that certification, you will need to be able to work with asynchronous, scheduled, and batch Apex code, have a good handle of JavaScript to be able to work with Lightning Components, and be comfortable working with web API callouts, such as REST and SOAP. The only thing I feel that a Salesforce developer knows that a general software developer doesn’t at that point is the strange inconsistencies, what I call quirks, with many parts of the Salesforce Platform. Many of those can be investigated doing a Google search, with many workarounds abound.

Salesforce has heavily invested in modern web and integration technologies that are now standard in the outside software development ecosystem. With their Lightning Experience user interface, Salesforce has adopted modern UI standards such as separating groups of markup and code into components, and responsive web design. Those standards were manifested through their Aura Components framework, which was designed when modern web frameworks were in their infancy. Aura Components worked very well for its time, and it is considered the more mature, full-featured framework to use when developing Lighting Components.

Fast-forward to recently, starting at the end of 2018, when Salesforce introduced Lightning Web Components, shortened to LWCs in some texts. Lightning Web Components combined the lessons learned from Aura Components, and the development of modern web frameworks such as React, Angular and Vue, as well as having better compatibility for future JavaScript language developments such as ES6 and beyond. It also has the capability to add unit testing, the majority using Jest for that purpose. Being new in the Salesforce Platform scene, it isn’t as mature as Aura Components, and many Salesforce developers are still figuring out best practices. Many exciting developments are coming for LWCs, like Lightning Message Service in Summer ‘20 (although it also improves things for Aura Components and Visualforce) that replaces the temporary c-pubsub shim component.

Another great tool in the general software development world that I feel many Salesforce developers miss out on is called “git”. Git is actually a version control system that Linus Torvalds, creator of the Linux kernel, developed to make it easier for him and his team of developers to work on the Linux kernel together. Git has a few important capabilities that I will explain. First, it allows your codebase to become distributed, meaning that all of the code can be copied easily in different places, to prevent loss of work if any copy is destroyed, and other copies exist. Second, saving your code in git is called committing your code. When you commit, git keeps a history of the code, so you can go back if you want, and even revert the code to a previous state. Third, you are able to create branches of the codebase, which is kind of like a copy within the same folder structure. From another branch, you can work on the code, and even experiment, and if you make mistakes in a branch that you can’t recover from, you can go back to the original branch, get rid of the ruined one, and start all over.

The fourth important capability, I consider a very important one, is that git allows you to easily merge code. This is very important when you are working on a team that modifies the same codebase. The best thing about it is that it has ways to fix merges that conflict with each other, called merge conflicts. Git does so by either intelligently merging the code if it can, or merging the code in a way so that you can do a side-by-side comparison of the merged code, and decide how to resolve the merge conflict that works for all changes. This is great especially when multiple developers happen to modify the same method or function, for example, and you want both changes to work together.

Finally, I will end this by talking about my experience as a Salesforce developer, working in consulting. Many fledgling boutique consulting firms hardly have the budget for keeping a Salesforce developer around. That said, if you want to be successful in those companies, you should already have some developer experience, as you will become a solo developer, and you will have no one to turn to if you have questions. In many Salesforce-oriented consulting firms, the solution architects are top-notch in their work, but still struggle to break into Salesforce development, although many will try. When they eventually understand code enough to be considered a Salesforce developer, unfortunately many will still have solution architect responsibilities, since that’s what they’re good at. Unfortunately, that fact will hinder their career as a Salesforce developer, unless they take personal time to work towards more advanced certifications, or learn some general software development.

I’ve experienced Apex code that struggles to have decent, coherent unit testing, and Apex tests that actually test code functionality. I’ve experienced Salesforce development teams that have no idea what git is, and that do much of their coding in Developer Console. I’ve had to fix test code because people have made changes in Salesforce setup, but they forget for a long time that the Apex tests need to be updated as well, so the test code is somewhat of a mess to fix as this “technical debt” accumulates, and they end up paying back by hiring a Salesforce consulting partner. This is somewhat a great argument for why the software development world in general likes to not hire junior developers, as companies need expertise that will fix the damage done by bad practices or accumulated technical debt. Therefore, there is great opportunity in learning the skills needed in the general software development world, as developers who work in that space more purely have to work with code in all of its components, so the rigour and the best practices that come out of it can be quite valuable when they are applied in Salesforce platform development.