David Schach is joining us again! We started our conversation on being a trusted advisor last week and are finishing it off today in part two.

David is a Salesforce Application Architect over at Spot On. He consults on all things Salesforce and has a wide range of experience with it. Therefore, he has some great tips and tricks to share. Tune in to learn more of them along with how to become a trusted advisor.

Show Highlights:

  • What the basic database theory is.
  • David’s favorite tools he’s pulled off GitHub.
  • Why “prettifying” code is so helpful.
  • Why negative testing is so important.
  • The difference between being dependable and being trusted.

Links:

Episode Transcript

David:
Corollary and Apex is like, there’s a way, I mean, how do you find the last day of the month? Eventually they came out with a method was last day of the month.

Josh Birk:
That is once again, David Shock, Salesforce application architect over at Spot On. I’m Josh Birk, your host of the Salesforce Developer podcast. And here in the podcast you’ll hear stories and insights from developers for developers. Today we continue on with our discussion with David about Salesforce consultancy, tips, practices, and some war stories. And we are going to take where we left off there talking about things you can do in Apex.

David:
I remember John Barnes was telling me that we had to go to the next month, the first, and then subtract one, which is legit. I understand that there was nothing there at the time, but Salesforce comes out with methods. Salesforce makes your life easier with every release.

Josh Birk:
Right.

David:
Just take it.

Josh Birk:
Exactly.

David:
Those are the kinds of things, but you actually are reminding me of basic database theory. Yeah. Don’t put a field on case, on opportunity, on I don’t care what, if it belongs on the account. So come on.

Josh Birk:
So well delineate that. So basic database theory. How would you describe that rule? Like, don’t over complicate things? What’s the-

David:
No, no, no. Take it back to the beginning. When we describe a database, if I’m doing a requirements gathering, I’m like, “Josh, how do you run your business?” And you start talking, nouns become objects or tables, right? Some nouns or adjectives or attributes become fields and I’m writing and that’s how you requirements gather. So I want to track people and I want to store their driver’s license number. So there’s an attribute, driver’s license number, or we track their birthday. There’s an attribute, that’s a field. I mean, that’s basically how it goes. So as you tell me about your business, I’m looking at what applies to the entire organization versus what applies only to something that happens once on a sale or could happen multiple times. But I start getting interesting conversations about how do you treat… A lot of people, a lot of companies set up for the first opportunity, but don’t think about the second. So they’ll convert fields into, and this is going the opposite of what I just said. Let’s say that we’re selling on, name an industry, there’s a competitor, so I don’t know, we’re selling Salesforce. So you’re currently using Lotus 123.
So let’s say that I close a deal. On the opportunity, when lead gets converted, Lotus 123 is your current CRM. Yeah. That is valid only until you become a Salesforce customer at that point, it really doesn’t matter. So that your existing provider was Lotus 123 belongs on the opportunity, not on the account.

Josh Birk:
Not got it. Yeah. I still remember the great Quentin Wall had, back when we did our intro to Salesforce workshops and he had exactly that on a slide when he was trying to tell people how custom objects work. And he’s like, “Here’s two paragraphs of people describing what their business process is.” And then the next slide had the exact same things, but all with nouns and verbs in bulk. And he’s like, let’s build an application. And it’s like, you’re already telling me what your data modeling is without telling me what your data modeling is.

David:
Exactly. You’re telling me everything and you’re telling me. I mean we can get into specifics. What’s a stage, by the way, another thing is a stage is a stage. A stage is not a task, like demo complete. I will be always be demo ready, whatever anyway. But yes, if you give someone enough time to talk, they will tell you everything that needs to happen.

Josh Birk:
Yeah.

David:
Just don’t do a lift and shift. Zendesk is Zendesk. You don’t need Salesforce to look like Zendesk. And when you’re migrating from Zendesk, use the Salesforce features. Don’t want to tell me my users are used to how Zendesk looks. I’m like, “That’s great. Exactly. But they’re now Salesforce customers.”

Josh Birk:
Right. And that is the next thing I was going to say is I’ve had other people on the show who’s like, “The other part of this dimension is not asking what’s your business process right now? It’s like what are your humans actually doing?” What is the human-centric version of what they’re doing today and how can we make that better? And how can we implement it for you better?

David:
Yes. And let’s focus on the last thing that you said because how can we make it better is a really hard thing. And I’m not criticizing anyone here. This is where a consultant skill comes into play. Yeah. Because let’s say you’re my client, Josh, and we’re talking, basically, I’d rather you not ever say the sentence, “Well I don’t think Salesforce can do that.” I’m not going to suggest this because it isn’t possible. Don’t dream crazy but dream. Tell me how you want the business to run. And we’ll see. Because sometimes it’s so easy. Yeah. That’s a workflow update.

Josh Birk:
And I had so many clients who would focus on what they thought the implementation was. They had something in their head that’s like, this is how it should work. And it’s like you’re telling me the wrong thing. You need to tell me what your pain points are and what you need and then we’ll make you an implementation that fits for that. And my favorite example, and it’s come up on the show a couple times, it’s like when anytime anybody said I need this in real time, I would be like, “But do you really?”

David:
Right?

Josh Birk:
If you get it in three seconds, are you going to be okay?

David:
Yes, exactly. And then I turn around and say, “If we wait three seconds, then it all comes up on a dashboard.” I sold Salesforce to a bank by actually talking about Adam Kaplan, our former boss. And this is the truth. I said, “My old boss used to start every meeting by hitting refresh on a dashboard and we became, what’s the word? We became conditioned.” We became conditioned to start the meeting when the dashboard refreshed because everyone knew that if you got a sale closed five seconds before the meeting, you made it on the dashboard.

Josh Birk:
Right, right. Yeah.

David:
So yeah, real time. Yeah, you’re right. What does real time mean? I don’t even know anymore.

Josh Birk:
Well, it’s a complicated world these days we’ve got [inaudible 00:06:42] and all these really cool tools and ways of doing it.

David:
Absolutely. And I’ve got a queue of whole stuff that’s running in the background and I can run that. And then you hit go and yeah, you wait 10 seconds and-

Josh Birk:
This is why I’m not the best Apex developer on the planet anymore. What I used to tell them is like, “Well, you’re telling me two things. You’re telling me you want it in real time and you also want 50,000 rows of data at your fingertips.” You’re going to have to pick one of these two things because I can’t develop warp technology for you, there’s just physics involved here. I could be wrong on that. I haven’t tried loading 50,000 rows into a single [inaudible 00:07:19] response or anything like that. So I don’t even know how fast is anymore.

David:
Well let’s actually talk about that for a second, Josh, because I think that I don’t have an answer to what I’m about to bring up, but this is the kind of thing that keeps me thinking. Should a platform event have a separate field for each item in it and then we just fire a bunch of platform events? Or should we do one huge long text area JSON and combined a bunch of stuff and batch into one platform event. And even that part, saying that second one actually hurts me because I lose all of my field visibility. Salesforce tracks where you use the field better, but there are people that really look at this stuff and I just think, you’re over-complicating it, maybe let’s just fire a ton of platform events.

Josh Birk:
Well, and to pull it all the way back, this is one of the things I love about Stack Exchange is that you can go to Stack Exchange and be like, “I have these two things that feel like they’re both philosophically sound and I believe they would both technically work, but let’s nerd out about which one’s actually better.”

David:
Yes. The person who nerded out with me on using the case statement versus else ifs when doing trigger context.

Josh Birk:
Yeah. Because it’ll, in this context, it’ll be 0.3 seconds faster, but when you get into bulk mode, it’ll be three seconds faster. You’re not going to see it until you’re under pressure, but when you’re under pressure, you’re going to want to have these little tweaks.

David:
And there are people who show the debugs logs.

Josh Birk:
I love it.

David:
I’m like, “Don’t you have day jobs?”

Josh Birk:
So that should be the next form of hackathons. It’s not come and do some weird vaporware that’s never going to get see the light of day. That’s the developer competition I want. Who can make this go faster. And people have done it online. I’ve seen it every now and then on Twitter and and I adore it.

David:
There’s an entire field of computer science who does that. There’s an entire field of how do I write my code so it goes past me. I don’t mind doing extra loop, but other people reverse it, so whatever.

Josh Birk:
Right. Let’s go to one other category, and this is kind of also because you’re talking about open source and we’re talking about sharing code and all of that kind of stuff. What are some of your favorite extensions and tools and things that you’ve pulled off GitHub that help you in your day to day?

David:
Okay, so I’m going to answer that in the… what do I put into my recommended extensions in VS Code. Number one is Apex PMD I think having that kind of feedback is incredible and making your own rules. Got to do it. And then I run PMD and GitHub actions because I just think GitHub actions are the coolest. Shout out to Apex DOX, A-P-E-X-D-O-X. It’s a wonderful way to document your code. If you look at my GitHub repo, you can kind of see that there’s a webpage that has the code in there for a large implementation. You group your code by groups, all your comments come in, it formats it. I love it. I mean look, I nerd out on prettier. I just think everything should be pretty, all those… What’s wrong?

Josh Birk:
Yeah, no, no, no, no. That’s the interesting thing is I used to be the biggest, just write your code the way you like it and let’s stop having… because I remember being in, this was after Model Metrics, it was at one of the other companies I worked afterwards at Organic. And I got on a phone call that lasted over an hour about using tabs versus spaces or semicolons or something like that. And by the end of it, I just wanted to scream, right? But I am a convert because once I actually started using it, the consistency of something like Prettify Code is just brilliant. And I feel like it also does the reorganization in a way that’s not just an abstract argument of how should code look. It’s actually, here’s how stuff is lighting up so that when something goes wrong, it’s easier to find out which block of code you need to start looking into. And I’m a huge fan at this point

David:
Precisely. And before I even knew about any of this stuff, the developer where I was working showed me her code and I said to her, “This is the most readable code I’ve ever read. And at that moment I realized there is an art to making code readable.”

Josh Birk:
Ian Pete, he is not in our ecosystem. So he is not going to be listening to this. But I worked at a startup for a while with my old friend Kevin Ruby, and then we hired our old friend John Clem. And as soon as John started writing his Java code, I’m like, “You bastard, this is so pretty. It’s so pretty. It’s so pretty. I’m just so jealous of you right now.” So yes, yes, agreed.

David:
Can I come back to just things that make your code look better? Anything that’s going to help you with indenting, there’s Indent Rainbow or Indenticator. These are amazing tools and I don’t know that I use beyond that, I mean obviously the Salesforce toolkit.

Josh Birk:
Well, and I’ll also give an update to what I got into the habit of doing because every now and then I actually do want to not put code on the next line or I want to block this little section off in a very specific way because that’s how I’m working on it. But then once I get it done, then I flip the switch and then just make it look like all the rest of the code. Because it was a focus thing. I want to put everything on the line until it behaves itself. But then after that, the fact that I did that doesn’t make any sense. It’s not going to make sense to the next… you always have to ask yourself what’s the next developer going to be with this? I was at a barbecue after I had left Crate and Barrel, I kept coming to the barbecue for a few years. I think they stopped inviting me because it was getting a little weird. And this might have actually been the moment because I was talking to these two guys and they were like, “Wait, who are you?” And I’m like, “Oh, I’m Josh. I used to work and did a bunch of the front end and integration stuff.” They looked at me with this expression of admiration and fear.
And fear was in their eyes, they were like, “Oh God, you’re the one who wrote that code.” They didn’t say that. Right. But I could see it behind their eyes. I had left five years of code in their hands and I think that was the last time I was invited to that party. Might have been like, “He triggers us. No.”

David:
That’s got to be a good feeling though.

Josh Birk:
The recognition alone was enough, right?

David:
Yeah.

Josh Birk:
I left my mark on you. Awesome point of validation. They did actually have to hire two people to replace me.

David:
But I want to be known for leaving behind really good utility classes. I don’t have all my old utility code. I need to go scour my stuff and collect it because I’ve written some pretty good utility stuff, which actually brings up the open source again. I mean I liberally borrow from other people’s code, the record type library that I finally found that Evan Callahan wrote. That’s in my GitHub repo because it was tucked away in the bowels of an old version of the non-profit starter pack that they deleted it. But I went back in time and I found it, I found it.
This is the kind of thing, but it is interesting. I’ll actually keep stuff on one line for a while and I guess now I realize do I need to? I mean if it’s a long debug statement, yeah, but maybe not, I don’t know. It comes down to style. I think that’s the cool thing. We each have our style. Yeah. I don’t want to admit that I have a style. Those hacker years were bad. But you watch the shows on TV, I recognize that hacker’s code. I’m like, oh, I’ll never put sizes greater than zero. I’ll do like, “Not is empty.”

Josh Birk:
Right. Okay. I want to give you the time to rant quickly on something that when we were talking on the prep call, you were like, this is something that’s really kind of important to me. So talk to me about your feelings about negative testing.

David:
Negative testing is the most important thing you can do in Salesforce. So here’s the rant. Let’s strap in because here we go. First of all, a good architect is like a lawyer, a good architect who thinks about what could possibly go wrong. So let’s take that statement and sort of hold it for a second. I will admit this is a familial thing. My father did some of the major research and if you put a button on a page, people will click it. It is actually proven scientifically. So if you give people a button and tell them don’t click that button, eh, they’re going to click it. In fact, that was research. So if you don’t want people to delete the account, don’t show them the button. So what could possibly go wrong is someone could click a button that you show them. And so a good architect thinks ahead. So negative testing is not only what could possibly go wrong, but it is admitting to yourself that there might not be that happy path with complete guardrails.
So we have to test for anything that can happen. So just on a lark once, I made a test account that only had a billing address and no shipping address on and it gave me an error and they’re like, no it doesn’t because the users are going to fill out both. I’m like, but what if they don’t? And I said, but what if they convert a lead and there’s no shipping address? And they’re like, “Oh.” So, but that’s what separates the rookies from the seasoned, whatever you want to say, not amateurs from professionals, but… Can you think outside the box for what else could possibly happen?
And then write those tests and make sure that you’re checking that things do happen. Think about all the way someone could take things through and just set up your data in weird ways. And then figure out a way. You have your style, I have my style, I do a tri-test with a boolean and this says “Has error.” So I start off with has error equals false. And then I only set has error equal to true in the catch. And then at the end I assert that has error is true because that’s how I check the validation rule or other things. You’ve got to check for negative testing. What else could it be? What doesn’t happen? How did it with-

Josh Birk:
Right. Because even really good unit testing, a lot of the ways that we think about it, I even used to teach this workshops and it was write down all… It’s basically it’s test driven development. It’s like write down all the things your code’s supposed to do and then write tests to prove that it’s doing it. And then when all your flags are green, you’ve got good code. Which is all true. True. Nothing I’m saying is false. But what you’re pointing out is you’re also leaving out the other part. What are the bad agents that might be out there that not just maybe just break your code but maybe might be breaking your org?

David:
Oh, completely, completely. I invite people that I work with to break my ideas. I say we’re going to do a thought experiment and we think things through. I’m like, “Can you break my idea?” And someone said, “What about unduly?” And I’m like, “Oh right. That’s an example where I should have thought of that.” But I mean that’s why you have good people you work with. Negative testing really is not just getting the coverage. Because don’t ever tell me you just write code coverage.
It’s not just I want to hit every catch. And by the way, if you put a tri-catch in your test that I don’t know, there are times to do it when you’re testing a validation rule. But don’t do it for the whole test I’ve seen because… Great, you just bypass the entire test. But really look at what people might do and say what permission might someone have? So yeah, I mean this reminds me of the time that someone says like, “Oh no one can delete accounts.” And I’m like 95% of your users have that permission. Yeah. Honest, honest. Don’t be afraid. Don’t be afraid, developers to think into pushback. And by the way, just to bring it back to the bartending, because I have to bring up bartending.

Josh Birk:
Right? Architects as lawyers.

David:
Architects as lawyers, bad developers are bartenders. And here’s the thing, so when I was bartending the rule was from this seasoned Chicago bartender who taught me how to bartend. He said, “If it won’t kill you, I’ll make it. I won’t necessarily respect you but I’ll make it.” so a bad developer takes the requirements and builds them. A good developer looks at the requirements and says, “Are you sure? Is that the best way to do it?”
And we can debate back and forth about whether you hard code an ID in a custom label versus maybe the record type name or whatever it is. But there are ways to do things. I just want all the developers listening to know that the best way to career advance is to speak up and say “I realize that this is in the short term, making things a little longer. But let’s give the client what the client needs.”

Josh Birk:
That’s not what they necessarily want.

David:
That’s right. Because they wanted a checkbox.

Josh Birk:
And they already used their one.

David:
Exactly. They’re on a checkboxes. Yeah. I mean it’s the number of developers who are okay putting a trigger on a custom user lookup for customer success manager on the account where it’s like, that’s an account team role.

Josh Birk:
And it’s come up on the show before when we talk about the differences between being having a developer mindset or having a consultant mindset. The word you used when we were talking earlier was trusted advisor. If you’re the person in the room that your business guy trusts and your product manager trusts and your project lead trusts and the client trusts, then you’re going to get invited back. Yes. Which is good.

David:
And don’t confuse being dependable with being trusted because if you are dependable in that, you write the code that’s requested exactly in the way that it’s requested, that’s great. They will. But you are not useful beyond when they think you’re useful and in a way that they think you’re useful. If you’re a trusted advisor and you get invited into meetings where you’re just listening because they value what you have to say. And that is job security.

Josh Birk:
One of my favorite gigs at Model, and I don’t remember the name of the client so I won’t name it, they were great. What they would do is they would come to Model and be like, “We have this really weird problem, we just want Josh to sit in the room with us.” And it was so fun. It was so fun, because I got to just sit there and listen to them, walk through their problem and I’m like, “I don’t even have to actually develop this in the long run. I just get to sit there and listen and try to basically do a thought exercise with them and actually walk through it.” Definitely one of my hands down favorite.

David:
Isn’t it wonderful? I mean you just get to sit there and listen and then when you do speak it’s welcome. You’re not just a yes person.

Josh Birk:
Right. You’re actually there to question them. You’re saying, it challenged me, challenged my ideas, tell me why this isn’t going to work sort of thing. Because some of the stuff is just really… One of their concerns was whether or not they’re going to run out of Apex, that kind of stuff. Before we go down this rabbit hole, let’s like kind of walk through it kind of thing.

David:
And people, you have to get people to shoot holes in what you do. I know that I come across as pretty confident sometimes, but I’m really not because I know that someone else is smarter than me.

Josh Birk:
And that’s another thing I remember from the old days. Don’t try to be the smartest person in the room. It’s not actually as much of a fun position as you think it is.

David:
No, no. Cause everyone’s going to look at you as opposed to why don’t we all… I want to tell you one little story just because very few people know this story. I was at Financial Force, I was working at Financial Force and Chris Peterson was my coworker and Chris and I were working on a solution to… I think it had something to do with JSON serializing and de-serializing. But anyway, my point is we were often at one end of the office with a whiteboard and Chris and I are both… We talk with our hands. All I’m going to say is Chris and I are very close. We’re friends. This was a wonderful experience. We came up with a great solution. But someone in the office called HR, because it looked like we were fighting. Yeah. And we were laughing, but we were definitely telling each other and saying, “That’s not going to work. That’s not going to work.”

Josh Birk:
Right. No. My good friend Rick Callberg, you dropped him earlier… and I owe Rick a lot of stuff in my career, but one of the reasons we worked so well together is we would get into these drag out fights over something and then go out to lunch. You know what I mean? It was just like, “Boom, okay, we’re done talking about that now.” And then we just boom. And it’s like, I think in the tech world, you need that sometimes, you just need that person you trust enough to fight you tooth and nail on something and then go out to lunch.

David:
Yeah. Well that person who trusts you, that person who you trust to fight you will be your biggest advocate. A behind your back and B is in front of you because there’s all of that going on where they’re going to say, if someone puts down on your idea, they’re going to say, wait a minute, let me think about that because… And it’s better. It’s to have those kind of people around. Sure. My favorite consultants blow up my ideas.

Josh Birk:
Love it. And that’s our show and before we go, I did ask after David’s favorite non-technical hobby and it’s one I would never have energy for.

David:
Well my favorite non-technical hobby is triathlon. I got into it as a way to blow off steam and just lose some weight. Because we all age. And so yeah, I love triathlon. I love getting out there and I just love being outdoors on my bike. Yeah. Running or just…
Although I will say, I do have to say though, triathlon is a pretty technical hobby if you look at all the gear.

Josh Birk:
I want to thank David for the great conversation and information and as always I want to thank you for listening now. If you want to learn more about this show, head on over to developer.salesforce.com/podcast where you can join our community, hear old episodes, see the show notes, and have links to your favorite podcast service. Thanks again everybody, and I’ll talk to you next week.

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