The IDC projects that 4.2M new Salesforce-related jobs will be created between 2019 and 2024. A portion of these roles are Salesforce developer positions. But what’s the job of a Salesforce developer, and how do professionals transition into these roles? These questions– and workforce evolutions– are close to my personal experience. I had a conversation with Alba Rivas to discuss these topics, as they’re part of her journey as well. In this post, we’ll discuss her history with the platform, and she’ll outline what a Salesforce developer job looks like today. Alba will also give you tips and tricks to successfully get started yourself.
Alba began her path to Salesforce by studying telecommunications engineering, and she’s been developing software since she graduated. Early in her career, she worked on applications primarily built with Python and Java. But in 2014, Alba was contacted by a company who built apps on the Salesforce platform to sell through Salesforce’s app marketplace, AppExchange. The company was looking for back-end developers. The native back-end language used in Salesforce is Apex, an object-oriented domain-specific language similar to Java or C++. Because there weren’t many Salesforce developers in the market yet, the company was looking for developers with object-oriented programming skills. Alba told me that initially, she was reluctant to take the job. She was skeptical of a platform that had created its own programming languages. Ultimately, Alba finally decided to accept the offer and give it a chance.
When Alba and I discussed the early days of her Salesforce developer work, she said she felt the benefits of developing on a SaaS (Software as a Service) platform from the very beginning. When developing apps with the Salesforce platform, Alba pointed out that you don’t have to take care of hosting your app. Developers don’t need to create and attach databases, start and stop web servers, or balance incoming requests. The Salesforce platform does all that for you. Becoming a Salesforce developer gave Alba the opportunity to invest her time in creating apps, which is what she told me she loves doing.
Salesforce executes in a multi-tenant environment, meaning that the underlying resources are shared with other customers. The platform has well defined limits that prevent one environment’s code from hoarding the resources. These limits, Alba found, served as positive motivation in her development work. Developing in an environment with clear limits forces developers like Alba to write optimal code. She told me she’s always been an advocate of clean code, design patterns, and performance. So, learning how to code with Apex was fun for Alba– like doing a sudoku in which everything fits together nicely.
Later in our chat, Alba and I talked about how on the Salesforce platform, there are two main ways to build apps: using configuration and coding. Thanks to this powerful combination, building apps on the Salesforce platform is extremely fast.
When configuring an app, the objects, the table where they’re stored, the basic user interfaces and APIs for the app and their APIs are configured through a web application. No code is needed. This initial configuration produces an app that is basic, but could be used immediately in production. To implement the custom logic and UI for your app, you can further configure it. The tools for these configurations are referred to as “builders.”
Lightning App Builder lets Alba and other Salesforce developers assemble pages with web components. These can be out-of-the-box components, components downloaded from the AppExchange, or custom components built by them.
For custom business logic and business processes, Alba likes to use Flow Builder. Flows are units of logic build with a block-based programming interface. Flows can be configured to be executed when a record is modified, or through other entry points. For instance, Alba talked about how they can be invoked from Apex and how they are also exposed for execution from a REST API call.
Flows can also incorporate UI to create complex guided visual experiences with no code. These are called “Screen Flows.”
These builders vastly speed up the app creation process. At this point in our conversation, Alba acknowledged that traditional coders might be wary of what she was saying. But she encouraged me (and you) to think of builders as a booster to speed up development. She pointed out that you can quickly build basic, less interesting functionality with no code, freeing up developers to concentrate on solving more complex and challenging problems with code.
At this point, I asked Alba how much time a Salesforce developer invests in coding alone. She said it can depend on many factors. Primarily, it depends on the structure of the company that you work for. In Alba’s case, she has always dedicated 95% of her time to code, as there haven’t been other people in her company whose role it was to do the configuration. Having said that, she acknowledged this is not always the case.
When Alba started with Salesforce development, the supported coding languages were Apex to implement business processes and Visualforce (a server-side rendering framework with its own custom markup) to create pages.
We also talked about how the door has been opened to other back-end programming languages (beyond Apex) thanks to Salesforce Functions. With this new technology, developers are able to, from different Salesforce entry points, invoke functions written with standard-industry languages like Node.js or Java. These functions run elastically, using the exact resources that they need.
I asked Alba about the most noticeable Salesforce developer improvements she’s seen over the years. According to her, it boils down to the developer experience. When she started coding with Salesforce, it was normal to code in a limited, web-based IDE called the Developer Console. (Developers could also use the Force.com ANT-based migration tool to deploy their changes to Salesforce.) While using the migration tool brought Alba the familiarity of ANT, there were limited capabilities for tracking changes and performing conflict resolution.
Alba told me the launch of the Salesforce CLI in 2016 fixed a lot of the earlier limitations. In addition to change tracking and improved conflict resolution, the Salesforce CLI introduced features to manage Salesforce environments, run tests, load sample data, and much more. By using the Salesforce CLI, Alba said she became much more productive. This also helped her team to transform their application lifecycle management, as the Salesforce CLI allows developers to implement modern CI/CD flows much easier. Salesforce has also invested in the Salesforce extension pack for VisualStudio Code. Alba listed some of the extension’s benefits which included autocompletion capabilities, direct access to the help feature, tools for debugging, testing, and access to many of the Salesforce CLI features.
Since I know many developers are anxious about their time to productivity when switching roles, I asked Alba about this. She said that in her first months as a Salesforce developer, she invested some time into learning, but that honestly, the learning curve was not too steep. There was great documentation, developer guides, and other training materials that she could find online.
This onboarding experience has vastly improved thanks to Trailhead. Trailhead is Salesforce’s fun, free learning platform in which developers can learn by following interactive tutorials, all while getting up to speed lightning fast. It contains more than 1000 learning modules and hands-on projects.
In thinking about Salesforce’s size, I asked Alba whether she felt it was a benefit or drawback. Alba described it as an appealing differentiating factor– the community around Salesforce is huge. So, if you have a question, you can ask it in a public community, such as the online Trailblazer community, the Developer Forums, or Salesforce Stackexchange, and lots of folks will be happy to quickly help you. Alba also pointed out that developers can join a Trailblazer community group near where they live and connect with people at online and in-person events. She said that Salesforce Community members normally have a spirit of cohesion; they look out for each other. Being involved in the community was key in her own learning path, and it also helped Alba to join the developer relations team at Salesforce, where she works as a developer advocate today.
If you want to get started with Salesforce development, Alba recommends starting with the Developer Beginner trail. In addition to Trailhead, Salesforce publishes lots of development resources to read, watch, and listen to. Alba also suggested this developer’s blog, the Salesforce podcast, and their Youtube channel (subscribe if you haven’t yet!). Alba specifically encouraged new Salesforce developers to take a look at the Beginner’s Mind and Quick Start video series. Want to take a look at some sample code? Salesforce has sample apps with patterns and best practices to help you ramp up your development skills.
I hope you enjoyed reading this post as much as I enjoyed connecting with Alba. Best of luck in following her path toward becoming a Salesforce developer.
Have a really great day!