What my Salesforce Interview Taught Me About Low Code
My interview had gone well, but then I received my demo project. Building then presenting this demo would be my final hurdle before I was offered– or not offered– a demo engineer role at Salesforce. But the list of demo requirements looked obnoxious. No way! I thought. This will take a month or more of development. Before I bailed, however, I was convinced to give Salesforce a final look, and that changed my perspective on app development.
Today, I’ve worked at Salesforce for almost four years. I’ve also built and performed dozens and dozens of demos, including demos for three Dreamforce keynotes. But prior to working at Salesforce, I was a developer and my entire career had consisted of either writing code and/or helping others write code. Consequently, code was my hammer, and everything looked like a nail.
This was my mindset when I received the demo project described above. I didn’t understand how Salesforce expected me to address their long list of project requirements. This is a partial list:
1) create a data model
2) create a responsive UI
3) showcase security/permissions
4) create a mobile app
5) create a public-facing website
6) integrate the website with Salesforce, etc., etc.
I looked at this list and thought WTF! I still had a full-time job, this would require weeks of work to maybe get a job offer. I was ready to reply with “Thanks, but no thanks!”
“I didn’t understand how Salesforce expected me to address this long list of project requirements.”
Thankfully, someone wiser suggested that I spend a couple of hours exploring Salesforce. “If you’re still thinking ‘no way,’” they suggested, “then move on.” And when I took that advice, I discovered that this project with its long list of requirements was already nearly complete. You see, code was my hammer and everything looked like a nail. I was thinking about the amount of code I would need to write to implement these features. I didn’t understand that Salesforce takes a different approach when confronting these common app development challenges.
“Salesforce takes a different approach to confronting these common app development challenges.”
Take, for example, the data model. Most developers are familiar with creating a relational database table. It’s not overly difficult, but once you’re done, the only thing you have is a database table. If you want a user interface for populating and managing the data in that database table, that represents another project. This goes on and on as new features get proposed (API’s, permissions, field validation, reporting, mobile-access). Each of these items represents hundreds, if not thousands, of lines of code to implement. That’s the world I knew, and the lens I was viewing this demo project through.
But inside Salesforce, once you define the data model these features get auto-generated. Ruby on Rails does a similar trick by auto-generating code from a data model, but inside Salesforce there is no code. Instead, there is metadata that inherits functionality. Think configuration, instead of code. Because of this, any work done inside Salesforce inherits new features as they are introduced. Which means a data model created inside Salesforce in 2005 is now accessible on mobile devices. No changes were needed. That’s the power of configuration over code.
“This epiphany lured me into Salesforce and helped me understand why this project wasn’t impossible.”
This epiphany lured me into Salesforce and helped me understand why this project wasn’t impossible. This being said, my demo DID involve some code, but the volume of code I needed to write was a fraction of what I first thought it would require. I was able to blend custom code I’d written with lots of features that I inherited from Salesforce’s no-code builder tools. The rest is history, I built the project, I gave the demo, and I got the job.
As developers, we are ALWAYS working with some layer of abstraction that exists between our intent and the underlying machine. None of us are feeding punch cards into computers, instead, we’re using programming languages, frameworks, UI libraries, etc. that translate our intent into machine instructions. My Salesforce interview taught me that “click-based” builder tools are simply a new layer of abstraction. With a few clicks inside Salesforce, I can express my intent and save a lot of time by reusing what’s already built. But similar to other abstraction layers, I can also drop down to a lower level of abstraction (i.e. code) if needed to address something that is unique to my projects. Ultimately, it’s this combination of clicks and code that enabled me to tackle this demo project, and the many projects I’ve encountered since.
If you want to experience this story for yourself, you can watch the quick 5-minute demo posted above. Or better yet, visit Trailhead and work through one of our app-building trails. Similar to me, if you’re skeptical, then time box it, give it a couple of hours. If you aren’t convinced, ditch it, but maybe first let us know how we can make it better. Thanks for reading! :)
