In this episode, Matt and Mike talk with Salesforce’s SVP of Engineering for Developer Experience about learning to interact with developers as if they are your customers. As the engineering leader of Salesforce’s platform developer experience, Frederick leads Salesforce’s proprietary Apex programming language, the Heroku runtime, and all the developer tools that enable the platforms including Visual Studio extensions and much more. “I try to be the biggest nerd for developers that I can be,” is how Frederick explains her role.
Checkout the episode here.
Before landing at Salesforce in 2020, Frederick ran the developer ecosystem at Ebay for six years. Before Ebay, she worked at Intel’s Open Source Technology Center focused on porting the Linux kernel to Intel chipsets. It’s there that she learned, “If you can make a developer happy then they will do really creative things…the sky’s the limit.”
Supporting non-consumer developers
To start out, Frederick talked about what she calls non-consumer developers. As she sees it, developers are often working to solve their own problems and they are typically using your API for just a few parts of their solution. They measure productivity, not in terms of your API, but in terms of their own solution. They want to get a job done for their business and move on to the next thing,” she explained.
Influencing a positive developer experience
Matt noted that Frederick has lots of self-driven communities to contend with at Salesforce. Each part of the organization has their own set of priorities and constraints. And he asked about the challenges of leading these seemingly disparate groups toward the same goal. At Salesforce Frederick works with programming languages, SDKs, CLIs, runtimes, etc. For Frederick, these are all “APIs” they are all “windows into our company.”
One key question that came up was how to get things done when you have such a diverse platform and developer community. Gail’s response was priceless, “I employ carrots and sticks and wine and chocolate each in different ways” to influence Salesforce teams into creating that positive developer experience across various toolsets and platforms. The “carrot” is about being positive internally about the upside of good design. The “stick” is more about governance and maintaining consistency across the organization. Finally, the “wine and chocolate” is all about making smart compromises as you improve the platform. “I am not above horse-trading with my peers and helping them when they help me,” Frederick says.
Maintaining program consistency and developer UX
Matt asked why it is important to have consistency across all sorts of APIs. Frederick points out that consistency is one way to improve developer productivity — to make it easier for them to solve their own problems and move on. For example, Frederick pointed out that twenty years later, Salesforce still tells developers “you can use any version of our API that you want to” and they still ensure that it will work as promised.
Frederick also reminds us that web APIs are just one type of interaction developers deal with at Salesforce and consistency matters across ecosystems (CLI vs. SDK vs. API, etc.) and that Salesforce is really focused on the UX of the platform itself. She also says that the personas of developers on the Salesforce platform is quite varied. Some are focused on declarative solutions, some on full-on object modeling and programming, and others deal with command-line scripting. As she points out, “If you get it right for engineers, not only will you have a great product but you end up making a lot of money for the company.”
Dealing with “bad behavior” and reliability on the platform
One point that came up was dealing with improper use of the API (whether intentional or not) and how to weed out developers who should not be on the platform. This is especially important since the API space is a petty big target for abuse. Frederick talked about a mix of detection and mitigation as well as designing APIs with safety in mind — such as adding observability, identifying good behavior, and encouraging it too.
Bugs, quirks, and the continuous hammer
This led to a conversation about an element of “seeing” what is happening at all times — tracking changes and modifications over time and still keeping everything up and running reliably. Frederick talked about the role of test automation in keeping the platform resilient and mentioned an internal product at Salesforce known as “The Continuous Hammer.” The hammer, she explained, runs around 1.5 million tests — all provided by Salesforce API consumers — to discover unexpected errors and inconsistencies based on “the truth as our customers see it.” That’s how Safesforce gains confidence that our releases will be safe.
As a side note, Frederick shared two handy definitions when reviewing results of testing: bugs and quirks. The definition of a bug is a defect you didn’t intend and the definition of a “quirk” is a bug you actually “like.”
New ways to connect and go fast
What followed was a short trip into the world of new patterns and technologies such as gRPC and GraphQL and how Salesforce deals with these trends in the API space. Salesforce doesn’t try to be on the “bleeding edge,” but they are constantly looking at new approaches and paying attention to when a critical mass of developers want access to the new tools.
To wrap up Mike asked Gail what advice she had for companies that read about how Salesforce, Ebay, and other organizations manage their platforms and decide they want to do it just like Salesforce. Her first bit of advice is “don’t read tech blogs because you’re likely to get a lot of fashion information.” Instead, she says companies should stay focused on the developers that are your customers, understand their needs, and remind yourself that your job is to help your developers go “really fast” on your platform.
This is just a taste of the insights Gail shared in the episode — listen to the whole thing in the link above. Follow the podcast on SoundCloud or subscribe to our newsletter above to get summaries of the episodes.
