Kevin Poorman is a Senior Developer Evangelist with Salesforce. Today, we sit down and talk with him about his CodeLive series where Kevin and a guest pair program interesting and unique solutions and ideas for Salesforce. Kevin gives a general overview of the show, but we also dig a little deeper into some highlighted topics from it.

And while Kevin is mostly known for his Salesforce skills, he actually has a Master’s in Divinity, as well. Tune in to hear all about CodeLive as well as his experience with the diverse combination of software engineering and religion.

Show Highlights:

  • What CodeLive is and why he started doing it.
  • Why he wanted to go the direction of pure programming.
  • The few rules he gives to his CodeLive guests.
  • Tips and tricks to get debugging into your normal lifecycle of development.
  • Tools that help with peer programming.
  • What null coalescence is and specific cases where it helps.
  • What unlock packages are and how Kevin used them in CodeLive.
  • The journey he went through with moving Visualforce to LWC.
  • What Apex Recipes is and how he sees people using it.
  • What he wishes people did and didn’t do with Apex.

Links:

Episode Transcript

Kevin Poorman:

So, part of it is it’s fun. Part of it is I want to break down this whole just because you’ve been doing it forever, it means that you know everything.

Josh Birk:

That is Kevin Poorman, a senior developer evangelist with Salesforce. I’m Josh Birk, a developer evangelist for Salesforce, and here on the Salesforce Developer Podcast, you’ll hear stories and insights from developers for developers. Today we sit down and talk with Kevin about his CodeLive series, and we dig a little bit deeper on a couple of highlighted topics from that show. But before we got there, I asked Kevin after his masters in divinity, since most of us know him as a software engineer. So, did you kind of go to college for software engineering with a side of religion, or was it kind of the other way around?

Kevin Poorman:

Okay. Start off with a hard-hitting question. So, I went to school because I wanted to teach theology, and a lot of things influenced me not going into that.

Josh Birk:

Okay.

Kevin Poorman:

I had been doing computer programming since I was 14.

Josh Birk:

Wow.

Kevin Poorman:

Yeah. So, as it turns out, it’s harder to get into a Ph.D. program for theology than any other degree program out there, and it’s mostly because there’s only four or five institutions in the world that still offer it.

Josh Birk:

Interesting.

Kevin Poorman:

So, I got done with my master’s degree, and I wasn’t selected as a Ph.D. student.

Josh Birk:

Gotcha.

Kevin Poorman:

Yeah.

Josh Birk:

So, basically, falling back on software engineering. So, what’s your earliest experiences with computers then?

Kevin Poorman:

Yeah. I remember my dad brought home and I helped him unpack an Apple 2E, and that was my-

Josh Birk:

Nice.

Kevin Poorman:

… first introduction to computers. He had had a Commodore 64 beforehand, but the Apple IIE, and then when I was 14, I shattered my left hip, and I ended up in the hospital for a couple of months, and Kansas is one of those great states where they don’t really care if you’re in the hospital. You still have to go to school.

Josh Birk:

Gotcha.

Kevin Poorman:

So, schooling for me was they let me into this room where I got to play on an Apple IIC. It was great because it was color, and I started… Very quickly ran out of things to do out of the box with it, so I started playing around with Apple BASIC.

Josh Birk:

Got it. Nice.

Kevin Poorman:

Yeah.

Josh Birk:

When did you start working with Salesforce?

Kevin Poorman:

API 11, which if I remember correctly, was released back in 2009, 2008, 2009, somewhere in there.

Josh Birk:

Gotcha. Yeah, yeah.

Kevin Poorman:

Yeah. I was working at a software as a service company, and we decided to, well, the company decided to integrate Salesforce as our CRM, so there was this crazy 10-week span where everyone just crunched on that, and we got it up and working. There was a lot of interesting late nights and fun algorithm discussions.

Josh Birk:

When did you join Salesforce?

Kevin Poorman:

Let’s see. I joined Salesforce in 2015, I believe. Yeah. June 2015, somewhere in there.

Josh Birk:

Back then, you were an ISV evangelist?

Kevin Poorman:

No. I started off a… I don’t even remember what my exact title was, but I was working with Mobile Push-

Josh Birk:

Got it.

Kevin Poorman:

… the MobilePush SDK in Marketing Cloud, and so a lot of mobile development, a lot of working with Marketing Cloud customers to help figure out why the Marketing Cloud mobile SDK wasn’t working just like they thought it should-

Josh Birk:

Got it.

Kevin Poorman:

… all centered around MobilePush.

Josh Birk:

Got it. Got it. Okay. So, now in your current role as an evangelist, how do you describe to people what you do?

Kevin Poorman:

So, it alternates. Depending how technical the person is, I can talk about how I help our users sort of dream the possible and work out the issues and make things work for them and their companies in terms of developing on a platform. For someone a little less technical, I build demos and examples of code, and I then tell the world about them in an effort to teach our user, our end developers, I’m going to coin a phrase, end developers, how to do things efficiently and correctly on the platform.

Josh Birk:

Got it. Well, that segues into our main topic today, which is your CodeLive series. So, what exactly is CodeLive, and why did you kick that off?

Kevin Poorman:

So, CodeLive is a weekly one-hour-ish livestream where I and sometimes a guest will get together and livestream the development of some feature or focus of Apex or LWC, something on the platform. We’ve had a couple of instances where we’ve decided to go off the platform, but usually it’s pretty much tightly focused on doing development on the Salesforce platform, and we get together, we say, “Hey, we’re going to do X, Y, and Z,” and we sit down, and we code how to do X, Y and Z, generally trying to keep to basically a use case that is plausible, if not exactly something you would do every day.

Josh Birk:

Interesting. So, tell me a little bit more about that. So, the person you’re peer programming with, is it a passion project that they thought they might want to do, and then, again, you get with them and start fleshing that out?

Kevin Poorman:

Sometimes. We’re recording this on a Friday, so yesterday we had a CodeLive. I had with me Chris Peterson, the PM for Apex, and he had this idea for building a logging framework using platform events, and so we sat down and said, “Let’s build a logging framework. How would we architect that? How would we make sure that it’s extensible?” We worked through how to build out that sort of logging framework. Other times it’s we’ve got this feature of Apex we want to help people understand how to use, so sometimes it’s queueables, we’re going to do an hour-long coding sessions on queueables. Other times, it’s features of the platform. We did on a few weeks part where I worked with part of the custom notifications API team, and we showed off how to send and receive these custom notifications in a mobile app, and as well as on the desktop.

Josh Birk:

Gotcha. This is a very different format than a lot of stuff that evangelists have put together. It’s live. It’s peer programming. Why did you want to go with this direction?

Kevin Poorman:

A bunch of reasons. One, it’s a lot of fun.

Josh Birk:

Nice.

Kevin Poorman:

Yeah. It’s a lot of fun to sit down, and there’s a certain pressure that comes with developing software for an enterprise level that we don’t necessarily need to propagate and keep around in our community. So, part of this is to keep it light and to… I’ve been doing this for APEX development, Salesforce development for more than 10 years, and I do some volunteer work with a group called RAD Women, and we teach women to develop on the Salesforce platform over the span of 10 weeks, and one of the things that I consistently get in feedback from them was it’s really great to see somebody who they look up to as having all this experience, still looking up information and data.

Kevin Poorman:

So, part of it is it’s fun. Part of it is I want to break down this whole just because you’ve been doing it forever it means that you know everything idea, and another part of it is I just want us to make sure that we’re experimenting and trying new things. When we have a novel use case come up, that use case may be novel to us, but surely, somebody else has tried to do that same thing before.

Josh Birk:

In talking about things like fear of failure and stuff like that, I think CodeLive has a few specific rules that you give your guests. What kind of rules are those?

Kevin Poorman:

Yeah. So, the first rule is failure is always an option, and that is to say we can sit down and code something for an hour and have a typo that eludes us, and it fails miserably, and that’s okay. It’s okay to work on code and not have it work out of the gate. We’ve had numerous examples where somebody joins us for a CodeLive, and they’re in the chatroom, and they’re giving us feedback like, “You misspelled this word,” or that sort of thing-

Josh Birk:

Nice.

Kevin Poorman:

… and that’s true to day-to-day programming. Right?

Josh Birk:

Yeah.

Kevin Poorman:

It’s true to life. You can sit down and work on something and have a clear design in your head, have a clear focus, and then when you’re done typing the last thing, it just doesn’t work like you think it should. So, I guess I’ll back up to your previous question. Another thing that I want to try and do with CodeLive is teach people to debug.

Josh Birk:

Okay.

Kevin Poorman:

So, failure is not only always an option. It’s sometimes, but I also look for opportunities for us to highlight how we failed and how we corrected it. Right?

Josh Birk:

Yeah. I mean, I think, and this has come up in a couple of themes on the podcast before, that it’s not just… Failure is almost a requirement in development.

Kevin Poorman:

Yep.

Josh Birk:

You’re not going to get it right the first time out of the gate, and it pretty much, unless you’re already copying existing code, and even then, good chances you’re probably going to have to modify it a few ways. So, what are some tips and tricks that you’ve learned to kind of get that debugging into your normal lifecycle of development?

Kevin Poorman:

Debugging into the normal lifecycle of my… So, not to get on a soapbox, but…

Josh Birk:

It is a podcast. Bring your own soapbox.

Kevin Poorman:

All right. I really find that one of the things that helps me understand my code, helps me identify where I’ve got a logic problem or where I’ve got an issue where I didn’t think things through all the way is writing unit tests. So, I’m a huge proponent of let’s write some code, and then let’s write some unit tests, and make them as specific as possible so that if something later is a typo, then you’re going to catch that immediately.

Josh Birk:

Yeah.

Kevin Poorman:

Sort of a corollary to that is running your unit tests all the time.

Josh Birk:

Yeah.

Kevin Poorman:

Yeah.

Josh Birk:

When I was a consultant, I actually got into a groove of writing the unit test first, and what I found was that writing the unit test first actually helped me cement what the code was actually supposed to do. It was kind of like the contract that I was going to actually go to. So, it was sort of like I would get all these business requirements, and then the first thing I did was try to kind of convert some of that into code. I think a discipline of test-driven development is all your unit tests are supposed to fail first because you don’t have any code to work against them, and then it’s a matter of checking those things off to green. Is there anything specifically from a tools point of view or anything that you do to kind of help expedite the debugging?

Kevin Poorman:

I am a liberal user of System.debug.

Josh Birk:

Okay.

Kevin Poorman:

I find that the replay debugger is also quite helpful. We haven’t often had an issue where the replay debugger has come up on CodeLive, but we have used it once or twice. The replay debugger is quite handy. The System.debug is sort of the bread and butter of debugging. I remember reading a quote once. Somebody asked [Carrigan 00:11:26] how he debugged, and he said he printed everything to the screen. So, it may be old school, but it’s effective.

Josh Birk:

Well, and a little bit more on that with how you’re actually producing CodeLive, what are some of the tools that you’re doing to help with the peer programming itself? Because you’re doing that all remotely.

Kevin Poorman:

Yeah. We’re doing it with a combination of a streaming platform and with some plugins for our IDE, our editor. We use Visual Studio Code, so if you want to be on CodeLive with me, you’ll be in Visual Studio Code, and there’s a plugin for Visual Studio Code called Live Share, and Live Share allows for remote pair programming. So, I’ll open up a Live Share session, give you a link, you join it, and then whenever you type, the people see you typing. Everybody viewing sees you typing, and then when I type, we can sort of have dueling keyboards, as it were.

Josh Birk:

Gotcha.

Kevin Poorman:

It’s really quite a joy to use that, and then we combine that with our streaming platform, Trailhead Live, so that we get the headshots and the audio and that sort of thing. So, we use a combination of tools.

Josh Birk:

Nice, nice. Now, I want to highlight a few specific episodes. For instance, you just recently had our fellow evangelist slash advocate, [Julio Endukay 00:12:44]. Am I saying his name right?

Kevin Poorman:

I believe so.

Josh Birk:

I think I got it in one there, to talk null coalescence in one of my favorite languages, JavaScript. What is null coalescence?

Kevin Poorman:

Null coalescence is… It’s an operator, so you got to think in terms of left side of the operator, right side of the operator, and in your head, if you look at the null coalescence operator, what it does is it says, “Is the thing on the left null or nullish in JavaScript?” because JavaScript likes to invent words, so nullish in JavaScript, and if it is nullish, it will return the right side of that operator.

Josh Birk:

Got it. I just have to say this. One of my favorite parts of that episode is the slide that breaks down nullish and falsy, which are now two of my favorite words. Give me a little bit more detail for people that may be in Apex and not in JavaScript. What exactly do we mean by nullish and falsy?

Kevin Poorman:

Oh. See, now you’re playing stump the chump here. So, I am not a JavaScript expert, so please don’t quote me on this, but-

Josh Birk:

Gotcha.

Kevin Poorman:

… the idea of something being falsy is that there are certain values that are understood to be false, and it’s more than just false, but there are some values that are understood to be truthy, and it’s more than just true. So, if you have a zero, zero can be an integer and be truthy, but it might also come back from an API as a false in understanding. So, that’s your falsy versus truthy, and then nullish is not only null, but also things that are understood to be equal to null. Yeah.

Josh Birk:

Like empty-ish, almost.

Kevin Poorman:

Yeah.

Josh Birk:

Like quote, quote, with nothing in it. Is that a value, or is that a null?

Kevin Poorman:

It’s like an old-school Apex where you had to check and see if a variable is null, and then if it was a string and we wanted to make sure there was something in it, we had to check that it was not zero length or that it had some contents, and now we have an Apex that is blank or is not blank.

Josh Birk:

Correct. Gotcha. Got it. Now, what are some use cases that null coalescence really helps out with?

Kevin Poorman:

So, let me back up. We don’t really have a null coalescence operator in Apex yet. We have the safe navigation operator, which is a related concept, but in terms of the null coalescence operator, it’s great for when you’re dealing with languages that have that concept of nullish, or other languages call it optional values, where you know there’s a variable, but it may or may not have a value, and then giving a default. So, if I’ve got Josh’s website as a string, great. Use it. Otherwise, saying, “No website provided.”

Josh Birk:

Got it. Got it. Are there any other lessons that Apex could learn from this?

Kevin Poorman:

I enjoy sort of working on the extreme edges of Apex, so I tried to write a null coalescence operator in Apex.

Josh Birk:

Yeah, yeah.

Kevin Poorman:

As it turns out, you can’t actually overwrite or rename to build a class out of null. You can’t have a class null, which would be fun, but dangerous.

Josh Birk:

That’s kind of taking nullish to a whole new level, I feel like.

Kevin Poorman:

Right, right. A fun fact, you can overwrite the test class, so if you create a class called test-

Josh Birk:

Oh, really?

Kevin Poorman:

… you can dig yourself into all sorts of holes.

Josh Birk:

Oh, gosh.

Kevin Poorman:

Yeah, but not with null. So, I actually wrote it, but it actually is a method, and it’s really simple and easy to pull up, but it’s interesting to try and think about what you might use that for in Apex, and the biggest use case is for doing things like providing a default where a value has come back null.

Josh Birk:

Okay. So, moving on to another popular topic, John Daniels, Episode 42 of this podcast, by the way, talked a lot about unlocked packages, and we’ve done a couple of episodes on unlocked packages, but I feel like this is just one of the things I like repeating because it’s just something I really want developers to know about. So, level set for us what is unlocked packages, and what did you and John put together in that episode?

Kevin Poorman:

Yeah. So, let me answer those in reversed order.

Josh Birk:

Okay, perfect.

Kevin Poorman:

John and I spent the time we had on CodeLive, we took a bit of Salesforce Apex code that I had previously written, and we packaged it, and we created an unlocked package that people can then install into any org they’ve got, but not their production org, I think is the way it works. To be honest with you, unlocked packages versus beta packages I get a little confused on myself.

Josh Birk:

I think one is a variant of the other in that you can create an unlocked package, which is flagged as a beta, and because you’re flagging it as a beta, then people can play around with it, but they can’t use it in production itself, and then if it’s not flagged as beta, then it works kind of like… I don’t want to say quite like NPM, but a little bit like NPM where you can basically install it into the org of your choice, bring in dependencies and stuff like that.

Kevin Poorman:

Yeah. So, it’s not that you can’t install it in production. You can install it in production, but they’re available, kind of like NPM. I like the analogy you drew there. That’s a good one.

Josh Birk:

Well, what occurred to me is because you’ve got a blog post on this, and the package you created was on your promises work with Apex. Right?

Kevin Poorman:

Yeah.

Josh Birk:

Yeah. At the end of that blog post, you’re just like, “If you want to install this, it’s just SFDX package number, and away you go,” and it just seemed really, really elegant a way to get code like that up and running, and something that somebody can play around with.

Kevin Poorman:

Yeah. It’s a really nice way… I mean, it seems redundant to say, but it’s a really nice way to package things up, puts a nice bow on it.

Josh Birk:

Right, right. Okay. Then you also had the famous Salesforce wizard, Mr. Brian Kwong, who I am also still trying to get onto this podcast, by the way, about moving an app from Visualforce to LWC, which is something we’ve written about a lot. We have a video series on this. So, it’s kind of a big topic amongst developers, but take me through the journey that you went through with that, and tell me, what was the pain points of moving something from Visualforce into LWC?

Kevin Poorman:

Yeah. So, let me back up here. When LWC was first launched, I was out on maternity leave.

Josh Birk:

Oh, that’s right.

Kevin Poorman:

So, I was hanging out with my kid, doing that sort of stuff, and then when I came back to it, we started doing these CodeLives, and I was just like, “I want to do something with LWC.” So, I was talking with Brian, and we came up with this idea of doing this Visualforce-to-LWC CodeLive episode, and it was one of those things where we’re both kind of new to this, and we both wanted to… We’d both done the Trailhead modules and quick starts to get all the tooling set up and all that sort of jazz, but we were both very new to the entire process. So, what were the pain points? Lack of experience and knowledge. Right?

Josh Birk:

Right.

Kevin Poorman:

But we had a lot of fun working through those. I think the biggest pain point that we had, it was a conceptual one because how you communicate between components is way different than Aura, and we had these preconceived notions about how it should work, how we thought it would work, because we had experience in Aura, and it turns out those are wrong universally.

Josh Birk:

Right, right. I thought there was a good moment there where it was like… I feel like you and Brian both had this aha moment of why should a component [inaudible 00:20:39] It’s almost weird to think back to the Visualforce days where it was actually kind of convenient for your code to basically be constrained to a single page, and it’s like you need to change something, you could just go to that page, and you know that’s where that field is. But making things into discrete components, I think the way you described it is that it’s simply more agile and flexible. Does that sound about right?

Kevin Poorman:

Yeah, I think that’s a good way to put it. I think when I’m trying to teach something, when I’m trying to convey a concept, I always try and look for what is a convenient, understandable metaphor, and sort of the obvious one, right down to the image you’re going to use for Lightning Web components, is this sort of building block setup, and it’s almost a perfect metaphor. It’s just that the thing that you don’t realize if you’ve got that as your metaphor is that you’ve got this magic box over on the side, and every time you hit a button, you can get another block out of it. Right?

Josh Birk:

Right.

Kevin Poorman:

You don’t have a finite number of blocks. So, if you create your own blocks, which is another function of our magic box, then you can use those wherever you see fit, and it makes sense to be able to have a very tightly-focused, does one thing well block that plays nicely with others.

Josh Birk:

I like that analogy in part because everybody who’s ever played with Legos has gotten to that point where it’s just like you don’t have that one block that’s either the right size or shape or color.

Kevin Poorman:

Exactly.

Josh Birk:

This is not a problem anymore because you can just pull it out of the magic box.

Kevin Poorman:

Exactly.

Josh Birk:

I want to put a cap on that one with also that I think that’s about the fifth time that I’ve heard Brian state that he’s not a developer, and I strongly disagree with that opinion.

Kevin Poorman:

Brian says a lot about not being a developer, and I’ve seen some of the flows he’s worked on, and they give me a headache just looking at them, let alone trying to understand them, so in my book Brian’s a developer. He just doesn’t know it yet.

Josh Birk:

I think that’s a great way to put it. Okay. So, I want to move on to one of your other projects, but first, and I’ll kind of give you free rein with this because I know it’s a difficult question, and I’m dreading the day that somebody asks about some of my own content, but do you have other episodes that are kind of the favorite amongst your children that you really want to highlight?

Kevin Poorman:

Yeah, I have two that I think are just really good content. They may not be the best recording, but we’ve got really good content. We did a CodeLive live at Forcelandia a year ago.

Josh Birk:

Nice.

Kevin Poorman:

I had Simon Goodyear with me, and we built a trigger framework that was cross-package compatible and was based on metadata.

Josh Birk:

Cool.

Kevin Poorman:

So, you could package up your metadata for triggers, et cetera, that you wanted to be run, and the one trigger handler was good for all objects, and as soon as that fired off it would go grab the metadata and run those classes.

Josh Birk:

Nice.

Kevin Poorman:

It was very elegant. I was pretty proud of that design. So, that one’s a good one. Now, because it was live, there’s some audio quality issues there.

Josh Birk:

Sure.

Kevin Poorman:

The other one that I really like is I did one on… I got to the point where I just had an itch I wanted to scratch development-wise, and I created an… This sounds oxymoronic. I created an Apex class that gives you a generic-type safe collection utility.

Josh Birk:

Nice.

Kevin Poorman:

Yeah, and that’s playing on the very edges of what Apex is capable of doing, just messing with the type system and getting it to work in such a way that you can pass in any kind of strongly-typed collection and get a map back out of it that is equally strongly typed-

Josh Birk:

Got it.

Kevin Poorman:

… but it’s still generic enough to use with whatever you pass in.

Josh Birk:

Nice, nice. Okay. Well, I think that segues to my next question because I think that’s actually part of this project. You also just recently released Apex Recipes as a GitHub repo. What is the mission statement for Apex Recipes?

Kevin Poorman:

To be bite-size chunks of code that demonstrate a plausible use case and the proper way, the best practice way, to use a buzzword, of making that happen.

Josh Birk:

Gotcha.

Kevin Poorman:

Yeah.

Josh Birk:

So, I think in programmer terms, you are being slightly opinionated about how the code should actually look and behave?

Kevin Poorman:

I think if I’m honest, I’m being very opinionated, but yes.

Josh Birk:

Okay.

Kevin Poorman:

Yes.

Josh Birk:

Nice. How do you see people using this repo?

Kevin Poorman:

A couple of different ways. One, if you just want to start reading code, one of the things that I have learned over my career as a software developer is I learned other patterns and techniques by reading other people’s code, so come read this code, basically.

Josh Birk:

Gotcha.

Kevin Poorman:

The other part of it is if you’ve got a very tactical question, how do I write a queueable class? We have a recipe for that. Go see, okay, this is what it looks like to write a queueable class, oh, and then this is how I test that queueable class.

Josh Birk:

Yeah. Nice. I think there’s also a nice layer of discoverability to it because, especially with Apex kind of being its own special snowflake, sometimes you don’t know… For instance, the existence of a queueable class may actually be interesting information to somebody who’s trying to do something in an asynchronous world these days, especially if they have code that predates some of the newer stuff that’s out there.

Kevin Poorman:

That’s very true. One of the things that we did to try and make it as accessible as possible is we’ve got it set up so that when you install the package or you install the code into a scratch org, there’s actually an in-org UI that you can go and navigate, and you can see not only the code and the documentation, but also related code-

Josh Birk:

Nice.

Kevin Poorman:

… like tests, or if something depends on something else, you can see that related code there too.

Josh Birk:

Got it. So, basically, by installing it into a scratch org or a sandbox, I can browse the code, I can browse the documentation, copy and paste to my leisure?

Kevin Poorman:

Yeah, yeah. It’s all probably overly-commented.

Josh Birk:

I think that was a design goal, if I recall correctly.

Kevin Poorman:

Yeah.

Josh Birk:

Yeah. So, it just came out a couple weeks ago, but it’s an ongoing project. So, what kind of updates are you looking at for it?

Kevin Poorman:

We have a whole roadmap of things that are coming, everything from approval processes, how to deal with those, to everyone’s favorite, the chatter API.

Josh Birk:

Oh.

Kevin Poorman:

Yeah.

Josh Birk:

Brave.

Kevin Poorman:

As new features roll out, we are incorporating those as well. So, one of the ones is an example of this we did a few weeks back, was we did one on transaction finalizers, and transaction finalizers are a great Apex feature. They’re not in GA yet, but they are coming to open beta.

Josh Birk:

Gotcha.

Kevin Poorman:

So, as that comes into open beta, we’ll drop that branch we did on CodeLive into Apex Recipes, so now you have an example of how to do finalizers.

Josh Birk:

Nice. Yeah. It feels like with the three-release cycle that you’re going to have your work carved out for you.

Kevin Poorman:

Yeah. Yeah, and it feels like every day I go to Chris, and I’m like, “Hey, I’ve got an idea.”

Josh Birk:

Yeah.

Kevin Poorman:

So, we’ll see. Maybe he’ll bring us the null coalescence operator.

Josh Birk:

Nice. Kind of on that note, this is an opensource project. It’s all up on GitHub, and I assume you’re taking pull requests.

Kevin Poorman:

We are taking pull requests, and we actually received quite a few. Some is things like somebody gave me a pull request to help speed up the org setup for Apex Recipes on Windows.

Josh Birk:

Oh, cool.

Kevin Poorman:

Yeah.

Josh Birk:

Nice.

Kevin Poorman:

Then other ones were like, “You’ve got this sort of naming convention here, but it would make more sense if it was this way,” and it turns out they were right. So, we changed the names of some of the methods, and pull requests are very gladly accepted.

Josh Birk:

Awesome. To kind of wrap all of that up, I think it’s safe to say that you are at least somewhat opinionated on Apex. If there was one thing you wish people did or didn’t do with Apex, what would it be?

Kevin Poorman:

One thing I wish people did or didn’t do with Apex? Wow. I did not see that question coming. As I think about it, I think I would like to… How do I put this? I’ve seen a lot of things that I can’t unsee in Apex. I’ve seen code where every string was a constant to find the top of the file.

Josh Birk:

Oh, no.

Kevin Poorman:

I’ve seen triggers that were 2,000 lines long, and I think I would just like to see more Apex code that was not built of patterns, but built wholistically with the idea of maintainability.

Josh Birk:

That’s our show. Now, before we go, I did ask after Kevin’s favorite nontechnical hobby, and it turns out he’s got two of them.

Kevin Poorman:

I have two.

Josh Birk:

Okay.

Kevin Poorman:

I’m a music person, so I play many instruments. If you ever see me on CodeLive, you’ll see there are guitars and mandolins hanging in the background.

Josh Birk:

Gotcha.

Kevin Poorman:

Then photography.

Josh Birk:

I want to thank Kevin for the great conversation and information, all the great content he is putting together to help level up our community. I want to thank you for listening, and if you want to learn more about this podcast, 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. I’ll talk to you next week.

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