Learning to Think in Abstractions: Part 1

Just about everything we interact with in the Lightning Platform is an abstraction of something.

Whether it’s an abstraction of the database, an abstraction of the application, an abstraction of the platform itself, or even an abstraction of the solutions that you build on top of the platform, everything we touch is at some level a layer of abstraction.

We as Salesforce developers and architects need to learn to think in abstractions. There is no path to success otherwise.

What does it mean to think in abstractions, exactly? Well, let’s get a little introspective for a moment.

  • We are technical thinkers, and technical thinkers tend to be more literal than metaphorical.
  • We tend to follow a linear path and avoid deviations.
  • We balance being highly analytical with a certain level of constrained creativity.
  • We think in concrete terms. We struggle to connect high level concepts unless they can be tied to specific examples.
  • We try to find the most efficient path to an explicitly defined outcome. We are always looking for the shortest path from Point A to Point B.
  • We prefer prescriptive and explicit direction to ambiguity and connecting the dots.
  • We prefer to communicate with pictures and pseudocode because human verbal and nonverbal communications leave too much room for error.
  • We sometimes get so locked in that we lose our ability to connect with the bigger picture.

What Does This Mean?

  • This is why it’s easier for us to find code on Stack Exchange and make it our own rather than start from square one.
  • This is why we like frameworks.
  • This is why when we need to communicate, our first inclination is to find the nearest whiteboard.
  • This is why designing and implementing the design are two very different things to us.
  • This is why high level requirements tend to be the bane of our existence.

Fortunately and unfortunately there is rarely a linear path to follow when approaching challenges and solutions with the Lightning Platform.

There are almost always multiple paths, each coming with a tradeoff. And with each of the three releases each year, the number of paths to potential solutions grows.

This ambiguity makes it critical for us to not only learn how the platform works and to understand all of the moving pieces that the platform exposes, but how to think at a higher level that allows us to assemble the pieces in a manner that balances the tradeoffs and creates an elegant solution.

We also have to be open to continuous improvement and change, as new solutions may emerge that weren’t practical or even possible just months prior.

How Does This Apply to Salesforce Development?

  • If you’re coming to Salesforce from another platform, you have to unlearn it because Salesforce is different.
  • If you’re used to having control over each layer in the stack, you have to learn to subordinate to the platform.
  • If you’re not willing to accept a level of uncertainty and an embark on a journey of continuous growth and innovation, this is not the platform for you.

Detach from the concrete and embrace the abstract.