Melissa Hansen is the co-founder and principal architect for the HiFi Consulting Group. In this episode, we discuss her experiences working with nonprofits since she started the group. The HiFi Consulting Group also built out an application using Experience Cloud, and we break down the architectural and development decisions made while creating that app. Tune in for great information from Melissa.

Show Highlights:

  • How Melissa got her foot in the door at Salesforce.
  • What the HiFi Group does.
  • Melissa’s journey from admin to developer.
  • How she first started learning programming languages.
  • The users she created her application for.
  • The maintainability benefits of using an app that’s almost purely on the platform.
  • What Melissa considered when it came to the data model of her app.
  • Why she thinks about who’s going to inherit a project as she’s working on it.
  • Tips for making data-bound Apex classes perform.
  • When to use base components vs. custom components.
  • The performance gains you get from using the asynch/await model in JavaScript.
  • What RAD Women is.

Links:

Episode Transcript

Melissa Hansen:
I knew coming out of college, that I wanted to be involved with some kind of cause as many young people do. And I started working at a pretty small family support center in Los Angeles.

Josh Birk:
That is Melissa Hansen, co-founder and principal architect for the Hi-Fi Consulting Group. I’m Josh Birk, your host for the Salesforce Developer podcast. And here on the podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Melissa about her experiences with the Hi-Fi Consulting Group and their work with nonprofits. And we take a particular sample of them building out an application using Experience Cloud. For now, we kick back where we started from that quote and talk about her early years in getting into Salesforce.

Melissa Hansen:
Yeah. It was an amazing organization. It’s still around. It’s called Friends of the Family and they provided sliding scale counseling, parent education, classes for young parents, all kinds of really great programming and as many small community organizations, especially back then, they didn’t have a lot of technical wherewithal or tools and they didn’t have a database of any kind. There were paper files. I can remember the huge filing cabinets in our executive director’s office. Literal files. But what we did have is we had Microsoft Office, which comes with Access. So I took the class at the … there’s a … I forget what it’s called, but there’s a nonprofit specific tech center or there was in LA. And so I took like a week long class in Access and I built us a donor database.

Josh Birk:
Really?

Melissa Hansen:
Yes. I do believe they’ve moved on from it, but they used it for many years and through that process, it’s one of those things where after that class, that was immediately the favorite part of my job. I did a million things there, events and all kinds of stuff, but all I really wanted to do was work on that database. And so I figured I might want to lean into that.

Josh Birk:
So I think I’m already hearing where this is probably going because the slippery slope of the pain of spreadsheets and paper and all of this stuff into databases that often leads into my next question. How did you get into the Salesforce ecosystem?

Melissa Hansen:
Yes, after that organization, I worked a couple of places with existing databases, like Raiser’s Edge. And then I took a job at an organization called Stand for Children where I am down in Portland, Oregon, and they were in the process of transitioning from Raiser’s Edge into Salesforce. And so I was hired to help the implementation and all of the database transformation work. And that’s how I kind of got my foot in the door with using Salesforce.

Josh Birk:
Got it. And I kind of feel like maybe this is a little bit of,… maybe you just said all the things, but describe a little bit about Hi-Fi Consulting and what you do.

Melissa Hansen:
Yeah. So Hi-Fi Consulting Group, co-founded with my partner, Rich Nevin just over a year ago, and we work with nonprofits who are on platform already, generally, we don’t do implementations, but organizations who are using Salesforce and are ready to kind of take the next step. Maybe they have a program they want to scale bigger, or they need a custom interface, or they have some processes that are just killing them productivity wise, and aren’t quite working. And we really specialize in building custom apps on platform within the Salesforce ecosystem to help them do what they need to do.

Josh Birk:
Gotcha. Now I heard a lot about databases, Raiser’s Edge transitioning to on-platform. I’ve heard that story in the past as well, but I’m missing a little bit of how were you going from admin to on-platform ramping to, I mean, today, we’re going to talk about performance lightning web components and some very specific developer stuff. What was your journey from admin to developer?

Melissa Hansen:
Yes. So after we implemented Salesforce, we immediately started doing some custom code work. So I was lucky to be in a group that included a lead developer, a front end developer, and a CTO. And so we were pretty tech forward organization and a pretty ambitious organization in terms of what they wanted to be able to build for their in-house purposes and also public facing. And the short of it was I had great mentors. So there were a couple of guys who were just like, “Hey Melissa, you should start picking up the coding side.” And I had thought about it previously, but it can be hard to figure out where to plug in to kind of get started. And they started feeding me test classes to write and little trigger handlers.

Josh Birk:
Oh, okay. So I have to call that out. So you got, they had you starting with their test classes, did they?

Melissa Hansen:
Yeah, I think there was a plan. Looking back, I can see a few reasons for giving me test coverage. I know. It’s a little silly, but I think it’s not a bad place to put someone if you want to familiarize them with what the code is doing in a current org.

Josh Birk:
Yes. And I was going to say, I mean, I think there’s a joke in there that obviously, devious developers not wanting to have to do their own unit tests, but you do have to be very orthogonal to what’s happening in that org. And I’m assuming you probably learned a lot about the functional code that was already in there because you’re trying to poke at all the corners and the crevices to see what it’s actually doing.

Melissa Hansen:
Yes, exactly. It brings the right questions to the floor pretty quickly because you get in there and you have to understand what it’s supposed to be doing, how it’s supposed to be doing it, how you might break it. And so it was a really good way to learn. I didn’t exclusively … I think the plan was for me to just work on tests for awhile, but it’s a pretty nimble organization. So very quickly, as soon as I was useful in that regard, I started building what needed to be built and getting a lot of support along the way, which I think that’s one of the more crucial pieces because it’s a lot of work to pick up a whole new skill set mid career. And you know, I did a lot of self-study. This is actually right when MOOCs were taking off, the massive online enrollment courses, think edX is a big one. That’s the one that I use, there’s Coursera. And so I took the first CS 101 virtual class, which was the Harvard class.

Josh Birk:
Right.

Melissa Hansen:
I’m an overachiever, I guess. So it was like C plus and it was super hard.

Josh Birk:
Oh wow.

Melissa Hansen:
So I learned a ton. But I had my phone of friends at work which was clutch.

Josh Birk:
So specifically, what was the first programming language you really sunk your teeth on? Was it C + or was it Apex?

Melissa Hansen:
I probably, I was-

Josh Birk:
Or a little bit of both?

Melissa Hansen:
Good question. I think it was a little bit of both because I was figuring out what the Apex did, functionally and just you recognize patterns and you figure it out. But alongside I was getting the fundamentals of programming on the C + side.

Josh Birk:
Right, right. That is so fascinating because I honestly expected you to say JavaScript because that’s so easy to be the gateway drug of coding, but you went strongly typed and then loosely typed. So were you one of those people when you first started talking to JavaScript, it actually really aggravated you?

Melissa Hansen:
Yes. Yes. It’s funny because I do see that a lot of people coming from, maybe web stuff and CSS, HTML, then they pick up JavaScript and I am the opposite because I really like databases and backend structures. And the front end is still kind of a challenge for me. I’ve gotten friendly with JavaScript, but that used to not be my best friend. It’s so fiddly.

Josh Birk:
All of us JavaScript developers, we’re right there with you. I have very contentious relationship with CSS and as much as I had toward JavaScript, sometimes I’ve had arguments with it too. It happens. It happens. Okay. So let’s talk a little bit about the application that we’re going to kind of go over. You presented at Cactus Force and you gave a breakdown of this application, so let’s dissect it and get into the process of building it. But first let’s start with the audience who were the users that you were architecting for.

Melissa Hansen:
So this is for Stand for Children again, and the audience were, they’re community organizers. So these are staff, they are … Generally, this is a one to two year role. Some superstars can go a lot longer, but a lot of recent college grads or recent AmeriCorps folks, and they are going out into communities and working with, in this case, parents on getting familiar with the public school system, advocating for their kids. They do a lot of legislative work, so it could be getting out the vote or calling people and making sure that they’re talking to their school board. It’s almost like sales in that you are working leads and trying to cultivate leaders. You’re not trying to get them to buy anything, you’re trying to get them to participate. So it’s a lot of on the ground footwork kind of.

Josh Birk:
Got it, got it. I think it is interesting how much, I think people who haven’t gone too much into the nonprofit world realize the parallels that exist with when it comes to the sales cycle, because like you were mentioning Raiser’s Edge, we have NPSP and there’s so much of it, which is points of contact leads, accounts, opportunities, all the things that you see in the business world. Sometimes you’re chasing down a donation and sometimes you’re chasing down an ally. Right?

Melissa Hansen:
Yes. And it’s interesting because there are those similarities structurally and process-wise, but the guts are so very different. One of the fun things on the nonprofit side is that, and I’m biased, I’m sure [inaudible 00:10:55] for profit side as well, but they’re doing such interesting and specific things. And so translating that is important, because if you’re using the language of leads and opportunities, that’s not going to hit well.

Josh Birk:
Gotcha. Gotcha. So even though the roles are the same, the nouns are actually really important.

Melissa Hansen:
Exactly. So these community organizers, the thought process when we’re looking at this group and thinking about them as our customers is they need an application that is going to make sense for them, that looks like their job. So the goal is to have them, open up the program, take a look around and without a lot of training or handholding, they can kind of go, “Oh, okay, I get this. This makes sense because these are the words that I use. These are the structures that I think in. I can go use this,” whereas just dropping them into Lightning Experience in Salesforce probably wouldn’t be as successful.

Josh Birk:
Got it. Got it. Okay. Describe the size of the development team you were working with.

Melissa Hansen:
So for this application, it was my partner Rich Nevin and myself for Hi-Fi. And then we were augmenting their staff, which was a Apex developer, a sort of junior front end, so a guy who’s really great with CSS [inaudible 00:12:18] all the stuff that I hate.

Josh Birk:
You got to have that one. You got to get that one CSS whisperer in order to not lose your mind.

Melissa Hansen:
Absolutely. And then a project manager and director level person over there, a support. So that was the team size essentially.

Josh Birk:
Okay.

Melissa Hansen:
Two sort of Apex back-end developers/lightning web component developers and a CSS whisperer. And I should say Rich Nevin’s role is really on the product side. So he comes from that background. That’s the way that he thinks. And so he’s responsible for, not just translating the business requirements and getting the user stories, but also the design of the thing, how it’s going to look and interact.

Josh Birk:
Oh, interesting. So he’s kind of product, but also sort of your UX/information architect.

Melissa Hansen:
Yes. Many, many hats. [inaudible 00:13:16]

Josh Birk:
And I can really, from an architectural point of view, it’s so important, to have that as a first foot forward before you actually start coding anything, right?

Melissa Hansen:
Yes. And this is, I don’t know, maybe I’m jumping ahead here, but as the Lightning framework has matured the tools and supports around it have just gotten better and better. So for this app, we used Sketch, I think we used sketch.

Josh Birk:
Got it. Because we can give that an extra shout out, I think, did you use the Lightning Sketch plugin? I think those were all the right nouns.

Melissa Hansen:
Yes. Absolutely. Which is such a cool way to build wireframes or prototype using the framework that we’re going to be building with. And it’s almost like giving him … Because blank page design is hard, right?

Josh Birk:
Yes.

Melissa Hansen:
You’re just trying to design out of the clear blue sky. You really are going to need a UX specialist, but since we’ve already constrained ourselves in a positive way of saying, “Okay, we’re using Lightning web components. We’ll go custom when we need to, but in general, these are good designs, good patterns. Users are familiar with them. Let’s use what we’ve got. So it’s like, “Here’s your, the Lightning web components, or base components library. This is your grocery store. You can pick anything off the shelf. If we need to do a custom order, we will,” but it’s a way to make sure that he doesn’t come with a wireframe that we look at and, “Well, that’s going to take six months to get half done.”

Josh Birk:
Right. Yeah. Well [inaudible 00:15:00] because back in my days of a consultant and actually being an enterprise developer, we would start with wireframes and all this kind of stuff. But I just have this phrase burned into my mind because it was on every single one, which was wireframes are not designed. Wireframes were the inventory of things that we were going to have to build, but they were absolutely no way an obligation that that pixel was going to … That this was going to be exactly in that corner or these pixel wits or stuff like that. That would come later. And it’s just kind of cool for me to hear that we’ve reached a point where that may still be a little true, but if it sounds like the wave has collapsed to a certain extent.

Melissa Hansen:
I think so because the first sort of standalone Lightning app that we built on Salesforce, we did go to the comps level. He made design comps and it was a lot more custom styling and that was with AURA. So it was a little while ago, but yeah, the maturity of the component library and the styling has made it so that we kind of … It’s not that it would hurt, especially if you were trying to do something that had a really specific look and feel that was different, but that’s not what we were going for.

Josh Birk:
Right, right. Okay. Let’s pull back the calendar a little bit because you just mentioned AURA and then I believe there was an iteration of the, not an iteration of your application, but there was an original app that you were replacing. What was that like?

Melissa Hansen:
Yes. So this, it’s called The Organizer app since it’s for organizers and the first version of this … Gosh, when this? Has been maybe eight years ago, eight or nine years ago. And it was a Apex REST API back ends. So all of the backend was in Salesforce, but then an HTML 5 frontend. And at that time they had a full frontend web developer on staff. So that was … Oh, and we used a consultant group. That’s right. We also had … This was a while ago. There was a consulting group that we worked with who did a lot of the initial build of that app and then kind of handed it over and it was great. That app really changed the organization in a lot of ways, because it saw what you could do when you really build the right tool. And so I think it gave the organization even more of an appetite to say, “Oh, we can do this. We can build really cool things that are specific to what we’re trying to do instead of trying to cobble together things that don’t quite work.”

Josh Birk:
Right. Right. Well, and maybe this is going too far into the calendar date, but out of curiosity, do you remember what that app, the REST based HTML 5 one, what process was that replacing?

Melissa Hansen:
Oh, yes. That was replacing a lot of paper. It was replacing spreadsheets. It was replacing a lot of arduous, hand-built tools. Yeah. There was no corollary in terms of an actual app. It was just the variety of tools that they had stitched together to get their jobs done.

Josh Birk:
To get a process done. I’m trying to remember which interview it was, but I remember back in my model metrics days, my favorite clients were always the smaller the business, the more I love working with them because the small scrappy shops, which most nonprofits are in some form, a small scrappy shop, you fix that process for them and convert it into an application, it just means so much to them. You’ve saved so much of the day. Whereas an enterprise, a lot of the big enterprise people who are kind of like, “Why are you in my boardroom? Why are you in this meeting room? I have my own developers.” Kind of thing. And so I always love working with the small shops because they’re just so appreciative of the time that they had just saved.

Melissa Hansen:
Yeah. And that actually gets to a value that we hold really deeply, which is the value of the work that a lot of nonprofits are doing is huge. And sometimes they’re constrained because they have to be, and sometimes they’re constrained out of habit to just use what’s available and make it do. And when you invest in a tool that’s the right tool that gets the job done, that’s probably going to save money in the long run, I feel like it puts a lot of value on the work that they’re doing, right.

Josh Birk:
Yeah.

Melissa Hansen:
You’re saying to the community organizer, this job matters. What you’re doing is important. And we built a tool to do it the right way.

Josh Birk:
Right. Now this is probably a little bit of a self-evident question, but pulling that back towards the future, what are some of the gains that you get when you replace an HTML 5 REST application, with something that’s pretty much purely on the platform?

Melissa Hansen:
I mean, for one thing, we were able to do it without having to hire a frontend developer, which is not to say … Frontend developers are great and sometimes you need them. I have not tried to [inaudible 00:19:52] that role. [inaudible 00:19:54] to mention.

Josh Birk:
Sure.

Melissa Hansen:
But in terms of being able to use the skillsets that are in-house or that you already have with a consulting relationship, the maintainability issue is huge.

Josh Birk:
Gotcha.

Melissa Hansen:
Because if you have to have all of these stacks that you’re maintaining, you’ve got your AWS servers that you have to keep track of, maybe you’ve got Drupal on the website that you have to keep upgraded. If there’s a new release of PHP, which is going to break the frontend … There’s a lot of different skillsets. And if you have a team that’s really familiar with Salesforce and has those Salesforce skills, even if it’s something they need help building, they’re going to be able to maintain it so much more easily because it’s all on platform and those skills transfer. So I think that’s a huge gain, just keeping that footprint smaller and focused on what’s the value of this thing versus trying to have a full-blown tech team for an organization that maybe wouldn’t need it otherwise.

Josh Birk:
Gotcha. And I acknowledge, especially since I’m … I’ll ask after the AURA version first, but since we’re talking today about performance and some tips to creating these experiences in Experience Cloud, how did the performance of the AURA version compare to the original REST version.

Melissa Hansen:
That’s a good question. It was definitely faster. It’s also [crosstalk 00:21:21].

Josh Birk:
Good. That was the answer I was hoping for.

Melissa Hansen:
The interface is so different. It was so, so … You’re definitely saving trips, right? We were saving trips and we were able to load data in a way that made more sense. I mean, I should also say along with the new application, was a new data model, so it’s a little bit oranges and orangutans to compare.

Josh Birk:
I like that one. I’m going to have to remember that one.

Melissa Hansen:
That actually is a line from one of my mentors back in the early days.

Josh Birk:
Nice. Oranges … Okay. I will, I’m going to note that. So let’s poke at that a little bit. I do want to talk about LDBC and I want to talk about Experience Cloud, but an important part of getting to that performance shift you’re saying is, is not just how you’re building up the client, but what you’re building the client up to. So what were some of the considerations? Let’s start with the data model, then move to Apex.

Melissa Hansen:
Okay. Yeah. The data model is one of my favorite things to work on.

Josh Birk:
Nice.

Melissa Hansen:
We use a pattern. So this organization, in addition to having a couple of Lightning Web component based apps that are hosted in Experience Cloud, they also have integrations with their marketing and advocacy platform and a couple other tools are definitely users who are in the regular Lightning experience. So there’s a lot of consumers of this data, and it was important to think about not having the logic spread out in too many places. We don’t want to have business rules in a flow and in a trigger handler and in Lightning controller because things get out of hand really quickly. And so we use the domain layer a lot and a lot of encapsulation classes.

Melissa Hansen:
So if you think about the data model at the bottom with our S objects, cool, cool, cool. And then one layer up from that, we use a lot of these classes that represent a business idea. Team is probably a good example. All the people that they’re organizing, they put into teams to work together. And in the data layer, a team has an account, but in the business logic layer, that would be an Apex class it’s team that you can instantiate. And it’s got the business rules in there, if you’re creating a new one, if you’re closing it, if you’re adding people to it, all of the consumers, whether it’s something from the API or if it’s a Lightning Web component, or if it’s a trigger are going to go through that same logic path. And then we have assurance that all the rules are in one place, first of all. Well, mostly in one place and that they’re going to be consistently applied, which is a big deal.

Josh Birk:
Got it. Okay. So I find that a little fascinating because I feel like it echoes what you were saying previously about talking about those nouns. So am I paraphrasing this correctly that you are encapsulating the noun and some of the associated verbs that they would be needing in their process, and you’re putting that into the Apex layer for everybody to have access to whether it’s a Lightning Web component or a mobile application, or maybe even another REST application or virtually anything that has to access talking back to that data layer.

Melissa Hansen:
Yep, exactly.

Josh Birk:
Okay.

Melissa Hansen:
And I think it’s also called object relational mapping.

Josh Birk:
Got it, got it.

Melissa Hansen:
New [inaudible 00:24:52]

Josh Birk:
I’m trying to remember the first time I’m like in a meeting and somebody is like, “Well, why don’t we do a data access layer?” And I’m like, “You mean SACL?” The concept of overwrapping something on the data layer into Apex hadn’t actually really occurred to me at that time. I was a little young in my career. But I think … I’ll ask a follow-up question. Is there also, because that’s a very sophisticated, and also allows you to do better maintainability and it feels like that’s also important for a project that you’re going to have a nonprofit who I’m assuming at some point they kind of assume control and maintain, and will be maintaining this themselves.

Melissa Hansen:
Yeah, absolutely. In this case we have a sort of longer term retainer, so I can still pop in and help with either other projects or with maintenance, but this is definitely something they can own and operate with or without me just fine. And I think that’s a really important point. Something I think about a lot when I’m working on a project is, who’s going to inherit this? I tend to be somewhat verbose in the way that I write code. And I use a lot of comments. I’m definitely not playing the game of like, can I get this in one line? This is explicitly not the goal because a lot of times I can imagine the next person’s going to be maybe fairly new to this. I want it to super clear what this is doing and why.

Josh Birk:
Yes. And I thank you for that because I have never been the kind of developer who has … I mean, don’t get me wrong. I want to do things in as few lines of code as possible. I’m not going to have somebody go check out my logic puzzle to figure out why my [inaudible 00:26:41] realizes itself. So as somebody who has given code and taken code from other people, I deeply appreciate that.

Melissa Hansen:
I can also think of it as a side effect of being a non-traditional developer. I don’t have a CS degree. And so some of the fancier tricks, maybe I don’t use them because I don’t know them. They’re fun to learn and I love picking up new stuff, but sometimes I’ll learn a thing and go, “Cool. I’m not going to use it though, because no one else will know what this is.”

Josh Birk:
Right. Exactly. Exactly. So, and I don’t want to like … We’ll point people to your presentation, because I think you go into some depth with this, and it’s easier obviously to see code than to hear code, but do you have, when you’re talking about that data access layer, and I think I just used the wrong term, but when you’re talking about these data encapsulating Apex classes, since they’re data bound, do you have any tips on making those perform it?

Melissa Hansen:
Yeah. One of the patterns is I tend to have constructors. So when I’m instantiating one of those object classes, if it’s one that has the tendency to get really big, like the biggest one is person, as you can imagine.

Josh Birk:
Shocking.

Melissa Hansen:
Person is going to have a lot of related info. And they’re going to have in many cases, this application is all about lists, like finding the people, who am I going to talk to next? I want to find 10 people who I can get to show up and testify tomorrow. And so we’re giving them ways to just kind of manage and filter through and get to the right grouping as quickly as possible. So a person is going to have lists of actions they’ve taken in the past and interests and a whole bunch of metrics associated with them, and so what I’ll usually do is give some kind of bullion of do I need all the extras or I just need the basic part? Because sometimes I just want to load the person or a list of people and we don’t need five years of activity data attached to them. So I think thinking through what are the maybe top two or three cases of why would I be grabbing this object or an array of this object, and do I really need all of it or can I be strategic about, yeah, I don’t need everything.

Josh Birk:
All right. Let’s level set about the artist formerly known as Community Cloud now known as Experience Cloud, and yes, I’m still doing that mental hurdle myself. But at one point building out sites in this cloud was really a heavily specialized experience kind of tailored to how that worked. But now you’re using base components. You’re building out custom components, what’s it like not to sound too redundant, what’s the experience of building sites in Experience Cloud right now.

Melissa Hansen:
Yeah. And it’s interesting because we’ve typically been using Community/Experience Cloud almost as a container because we’ve been really focused on building these custom experiences with components. And so especially early on, we couldn’t use any of the built out templates. We weren’t trying to create a typical community per se, but it gave us a platform and the ability to build an app, at first out of AURA components, now out of Lightning Web components, and then serve them out publicly more or less, whether we’re reaching a public audience or just a bigger group of employees, but it gave us a nice container.

Josh Birk:
Got it.

Melissa Hansen:
I will say, it’s definitely a place where we’ve had to be conscious about what’s supported because things aren’t necessarily supported for the Experience Cloud, at the same time they are more generally [crosstalk 00:30:24]

Josh Birk:
By supported you mean specific components that you could use on the Lightning platform, but maybe not within Experience Cloud.

Melissa Hansen:
Exactly. It might be base components or it might be some other part of the framework. For example, the Lightning messaging service, I think is just now in beta for Experience Cloud, whereas it’s been available in the standard Lightning experience for a little bit.

Josh Birk:
Got it. And tell me a little bit more about using base components versus custom components, that you have kind of a rule or guiding rule to know what to put onto the page and when.

Melissa Hansen:
Yes, we very much have a great [inaudible 00:30:59] there, which is don’t build it if you don’t have to. We’re not trying to create something out of whole cloth. The reason we’ve been able to build pretty robust apps very quickly is because we start with that base component library. So the rule is at first try and find a base component that does what you need it to do, hopefully just out of the box. We can apply some custom styling of course, and get it where we need to get it. If for some reason, one of the base components just doesn’t quite work or we need it to do something extra we’ll then extend. So a good example of that is Lightning Data Table, which we use all over the place and we don’t necessarily want to build completely custom version of. Also, it didn’t quite get us what we needed in terms of the look and feel. It’s very narrow, rows, hard to read. So we extended it both stylistically, is that a word?

Josh Birk:
I’ll allow it.

Melissa Hansen:
Okay. So that it looked more friendly. There’s a big button on it instead of a checkbox, that kind of thing. And then also some inline editing that wasn’t available in the way we needed it to be. So we’ll kind of add on features we need. And then the last resort, if there really isn’t something that does what we needed to do, we’ll build something quote unquote from scratch.

Josh Birk:
Gotcha.

Melissa Hansen:
But from scratch also means we start with SLDS. We go to the Salesforce Lightning Design System and generally there’s a pattern or a series of patterns we can bring in so that we have consistency and user experience, the look and feel, but we can also have something that’s completely custom.

Josh Birk:
Got it. Okay. Okay. Well, let’s dig into a little bit of the working parts of those web components when you are coding your own custom functionality. When you’re talking about those JavaScript controllers, can you tell me a little bit about the importance and some of the performance gains you’re getting when you’re using the await async … No, I think I have that backwards. Async Await model.

Melissa Hansen:
Yes. And I’ll talk about the performance, but also just the ease of use. So I’m still, I’m definitely not a JavaScript expert. I am learning as I go like I do all the things. And so initially getting into JavaScript promises were really confusing and complex and call back pains were really confusing and I got in there and fought that fight and I can get myself back there and understand what’s happening, but it’s hard to follow. So Async Await gets us a couple of different things. For one, it wraps up that promise syntax in a way that is much easier to read and understand and know what is happening when. It allows you to execute things in a way that feels more synchronous, a little bit closer to Apex. Like I know if I have an Async Await line, the next thing isn’t going to happen until it’s done. Which is one of those things that sounds easy, but can be a bit of a struggle to make sure that you’ve got the timing right. Getting the data and trying to do something with the data only once you have the data.

Josh Birk:
Right.

Melissa Hansen:
So that, that honestly was a big part of it. And then yes, the performance gains. So one of the patterns that I talked about in my Cactus Force presentation was sort of bundling together. These Async functions, so if you have one function, that’s fine. You do your Async, you call the function. It waits until it gets the data back and then you proceed. But if you have, as we sometimes do, two or three functions and we can’t move on to the next step until we have all three of those promises resolved, but I don’t care what order they go in. They’re not dependent on each other. You can bundle those together so that they’re executing side-by-side essentially, and then when all three have resolved that promise will come back and then I’ve got all the data and then we can move on to the next thing.

Josh Birk:
Okay, well, changing topics a little bit, I want to make sure that we talk about RAD Women. First of all, what is it? And specifically, what does RAD stand for?

Melissa Hansen:
RAD stands for Radical Apex Developers. So it’s a really cool program. So we’re all volunteer based organization. And what we do is we offer free coding classes for women and non-binary folks who are advanced admins on the platform who want to get into the programmatic side. So when we talked earlier about sort of my personal history, I’m a non-traditional developer, I don’t have a CS degree background, but I had great mentors on the job. And that’s just lucky and that’s not good enough.

Josh Birk:
Right.

Melissa Hansen:
And it’s often why you look around and there’s not as much diversity and representation as we would want to see amongst developers. So the RAD program is a way of bringing that mentorship to anyone who needs it. So we have, classes are six to eight learners. They’re pretty small. Each has two coaches, and they meet once a week for 10 weeks for an hour and a half, and really get into the fundamentals of Apex and what programming is from scratch. I think a lot of developers forget how much, really where you have to start, especially for, if you’re a developer who’s been coding for forever, you probably don’t remember not knowing what primitives mean or what strings are. You can skip over that when you’re talking to a new developer and it’s really alienating. So we want to make sure we are giving the fundamentals to a group of really smart people who want to move into the programmatic side and we can give them the tools and the vocabulary and the coaching that they need.

Josh Birk:
So I just love all of that. And I especially love the acknowledgement that it’s access to not just material, but to people that can get important. By the time this airs, I will have been on the admin podcast, and I actually brought up this conversation with them because they were talking about this journey where it’s like if admins want to become developers, what should they know? And I’ve just now heard it so many times that it’s like, success is sometimes other people, that it’s having access to those people who can be trusted allies, partners, mentors, advisors, is what gets people to that next step and starts getting into those developer skills.

Melissa Hansen:
Yes, absolutely. And you’re right on with the people part. Coaches are the most important part of this program by far.

Josh Birk:
Gotcha.

Melissa Hansen:
So if you’re interested in either side, definitely follow us on Twitter. That’s where the most information comes out and where we talk about when we’re recruiting or opening up registration and we’re @RAD Women Code on Twitter, you can also go to radwomen.org and we’ve got some signup forms there. And if there’s developers listening, particularly if you identify as a woman or non binary or a person of color, we’d specially love to hear from you because we want great coaches and great representation. So please, please hit us up.

Josh Birk:
And that’s our show. We will be including a link to Melissa’s presentation from Cactus Force in the show notes. Be sure to check that out as well as links to the relevant RAD Women information. Now, before we go, I did ask after Melissa’s favorite non-technical hobby, and it turns out it’s not just cooking, but a lot of cooking.

Melissa Hansen:
But I really like project cooking-

Josh Birk:
Project cooking.

Melissa Hansen:
… and kind of hanging out with big, yeah. [crosstalk 00:38:55].

Josh Birk:
How many steps?

Melissa Hansen:
Too many. A good multi-day project, like a mole where you’re grinding all your spices or a bolognese where there’s four kinds of meat and six hours of simmering, just feeds my soul.

Josh Birk:
I want to thank Melissa for the great information and conversation. And of course, as always, I want to thank you for listening. If you want to learn more about this show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes and have links to your favorite podcast service. Be sure to also catch me on Twitter @Josh Birk and also on Twitch @Josh Birk. Thanks again and I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.