Career Highlights

Salesforce

October 2017 - April 2023

Declarative Field Rendering

The Salesforce database is a strongly typed data store, that is also very customizable. As such, a lot of the UI developed internally at Salesforce can't really know what kind of data will be rendered until runtime, just before the rendering needs to happen. To make this possible, the Salesforce database provides metadata indicating all kinds of useful aspects of the data, including data types (Number, Email, Currency, etc.) of individual fields. At runtime, this metadata is processed and interpretted so that, for example, an Email type field renders with the correct email capable UI component.

But it's actually quite a bit more complicated than that. For example, the Fiscal field on Opportunity is (according to metadata) a DateTime field. However, at runtime it needs to be rendered with a special Opportunity-specific UI component that will render the field's value as a fiscal quarter - like "Q3 2024". In this way, field rendering depends not just on the field datatype but potentially any other metadta, including available product licenses, feature enablement, etc.

Previously, this was accomplished with imperative code executed on the backend. Over years of having engineers add their special conditions to this code, it became not just unwieldy, but actually impossible to understand just by reading. The only way to know for sure what was happening and why was to debug through many layers of very old code. This obviously led to bugs, where an engineer would implement a new field rendering scenario, but that change would cause a cascade of field rendering errors because they didn't (and really couldn't) fully understand all the downstream implications of the change they were making.

Perhaps the most ambitous project I accomplished at Salesforce was to replace this imperative system with something that was much easier to understand and reason about, while being powerful enough to express all of the existing scenarios. I spent a lot of time reading through the aforementioned unreadable imperative code to find patterns and extract them out to a declarative language for field rendering. With this new declarative language, at development time it was much easier to understand what would happen at runtime - all you had to do was look at the declarative extensions for field rendering, which were easily found, and intuitive to read.

The last mile for this project was converting the existing imperative logic over to the new declarative system. For me, that meant mounting a comprehensive education campaign so that other Salesforce engineers could take on this conversion work with confidence - using the new declarative system to provide their team's domain specific knowledge to the field rendering process. This included live presentations and demos, as well as an extensive document explaining the new system for the engineers that needed to use it. I am extremely proud of this project since not only it was an enormous effort, but in the end, the system was intuitive, effective, and extremely performant. Each day it powers untold numbers (billions?) of field renderings on the Salesforce platform.

As a side note, the very last Slack message I got as a Salesforce employee was coincidentally from an Engineering Manager that had just found my documentation on this system and they were thanking me for how well it was written ❤️

How UX Saved Pinned List Views

Pinned List Views is a feature whereby Salesforce customers can choose to "pin" a particular List View to their Object Home page so that, for example, when they navigate to their Contacts tab, it shows their pinned List View instead of the default "Recently Viewed" list. It's a nice quality-of-life feature for Salesforce customers that almost didn't ship.

I joined Salesforce in the middle of their release cycle, and so one of the first significant memories of my time there was near the very the end of that first release, an executive was having our team remove a brand new feature that otherwise was about to ship for the first time. I remember this last-minute decision being somewhere between "very annoying" and "devastating" to my teammate who had been working on this feature for the past several months. The feature was "Default List Views" and it worked by always returning the user to the last List View they had opened on some Object Home. But there was a problem... It is possible for Salesforce customers to define List Views that result in a complex record query that is expensive to execute, that is, some List Views are unavoidably slow. The executive in question was concerned that this was a significant performance regression that made loading Object Home unnecessarily slow, and the feature was disabled at the last minute, and scheduled for removal at the first opportunity.

To my eyes though, this wasn't a performance issue, it was a UX issue. For one, changing the default List View to the last one visited is really just "magic" that the user (including the executive concerned about performance) didn't have any awareness of. Secondly, if the default was set to a slow List View, the user had no reasonable way to get themselves out of that state - there was no explicit action they could know to take to return this Object Home back to a more performant List View. They would have to somehow know to choose another List View and then navigate away from Object Home, which is not at all intuitive. But both of these problems are easily fixed.

In order to save this feature, I quickly went to work producing an animated UX mockup showing my idea for having a "pin" button next to the List View name. When pressed, the current List View would become the default for this Object Home, and the pin button would clearly indicate whether or not the current List View was "pinned". You could change this at any time by either un-pinning the button by clicking it again, or selecting a different List View and pinning that one instead.

On a personal note, I was sooo nervous when I posted this mockup to a Slack channel that included IC's, engineering managers, and even my Product Manager. I was the new guy on the team and I was hired to write backend code, not weigh in on UX which, presumably, was way out of my lane. Fortunately, everyone including and especially the Product Manager saw that this was a good solution to the problem. It took away the "magic" of having the default List View set automatically without explicit action by the user, as well as intuitively putting the user in control of getting out of a bad situation.

It was too late to change the implementation to Pinned List Views in that current release, but it shipped in the very next one, much to the relief of my teammate that spent so much time working on it.

IBM

October 2003 - September 2017

Serverless Event Provider for Kafka Message Queues

I was honored to have contributed significantly to Apache OpenWhisk in its early days - before it was donated to Apache and was still being incubated internally at IBM. As an event-driven serverless platform, one of the big advantages of the system is to have serverless functions invoked automatically in response to meaningful events. At the time I joined the project, there was just a small handful of supported events, notably one for cron-based alarms, another for CouchDB events, and maybe one or two others I might be forgetting. I was assigned the task of creating a new event provider that would trigger OpenWhisk functions in response to messages posted to the user's Kafka message queue.

The requirements were pretty straightforward: Write a microservice that would subscribe to Kafka message queues on behalf of OpenWhisk users, and fire the appropriate triggers when new messages arrived. At the time, the only acceptable Kafka client I could find was in a Python library (the Java client only allowed subscriptions to one Kafka instance per JVM - a non-starter for performance and scalability). And so, it was time that I finally learned Python. Fortunately, I found Python to be incredibly intuitive, and even had a real "Neo" moment where instead of having Kung Fu instantly downloaded into my brain, in just a few hours I was able to start writing Python.

Within a week I had a POC working, but of course getting the code to simply work was just the beginning. This new service needed to be performant, redundant, and horizontally scalable. If an instance of the service crashed, there needed to be another one ready to go instantly, and guarantee that no messages were lost or repeated in the OpenWhisk system. Additionally, it needed to be architected in a way that new instances of the service could be added and put online at any time in such a way that work was evenly balanced between all running instances. And, of course, there needed to be monitoring, health checks, and support procedures and playbooks to create.

In the end, I am extremely proud of the work I did on this project. Not only did I create an architecture that solved all of the non-functional requirements, that architecture was so successful that it was also applied to the Alarms and CouchDB feed providers to increase the reliability and scalability of those existing services. Years after I left IBM, I got in touch with my former OpenWhisk architect, Carlos Santana, for lunch and I asked about the Kafka event provider - my baby. I continued to follow the project on GitHub but hadn't seen many meaningful updates since I left, and I was worried that perhaps it was deprecated or replaced. Carlos relieved my worries by giving me one of the highest compliments that can be given to a piece of software, "No dude... it just keeps on running."

Google Sites

Report abuse