Paul Battison, Salesforce MVP, the COO at Cloudgalacticos, joins to talk about Salesforce Performance.
Paul is a Certified Platform Developer I, II, and all-around geek (Ruby, iOS, Android, Java, Node, etc.). Paul has a passion for technology and mathematics and applying them to help improve lives
Sponsor
Proton Text is a complete SMS texting solution built for the Lightning Platform, and by one of our previous guests Pat McClellan.
Main Points
- Paul and I start to talk a bit about performance in B2B and B2C platform
- Paul’s self-introduction and multiple roles
- The impact of governor limits on performance in Salesforce comparing to other platforms
- How did Paul use the Salesforce platform to process heavy AI modeling?
- Why do senior developers love governor limits?
- Paul talks about the performance in the front-end and the back-end.
- Paul talks about lazy load or bulk load in the front-end, and what are the pros and cons of both.
- Using Chrome Dev Tools for front-end performance troubleshooting.
- Our talk briefly touch the flow and process builder performance
- Paul talks about multiple performance points we can pay attention to on Apex
- Paul also shares the attitude of paying attention to performance and learning-related skills
Links
- Paul’s twitter
- Paul’s LinkedIn
- Paul’s personal site
- Paul’s medium blog
- Paul’s YouTube Channel – CloudBites TV
- Paul’s Blog post – Other valuable thoughts on Salesforce performance
- Paul’s Video Talk – The Need for Speed: Building Performant Salesforce Applications
- Paul’s Video Talk – Machine Learning & Artificial Intelligence for Salesforce Developers
- Good Day, Sir! Podcast and its slack community
Video Teaser On Salesforce Performance
Outro Music
Kakariko is Saved – The Legend of Zelda: Twilight Princess
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:00] Our sponsor today is Proton Text, a complete SMS texting solution built for the Lightning platform by one of our previous guests, Pat McLehlan. Here is reason number three that admins and users love this app. It comes with the Proton Blaster. It's true, Pat built a Proton Blaster. It's a Lightning Web Component that lets users plan and schedule SMS blasts to campaign members or to a blast list created from any list view or CSV file. Whether you're blasting to a hundred students or volunteers or to fifty thousand leads, setting up a blast is as easy as creating a calendar appointment. It's not magic, just good design. Learn more at protontext dot com.
[00:57] Hey
[01:09] everybody, this is Xi Xiao. This is yet another episode of Salesforce Way podcast. Today I'm sitting with another super famous guy in our Salesforce ecosystem. His name is Paul Battison. Hello, Paul. Hi G, thank you for having me here. Really pleased to be here. You're welcome, and really glad to talk to you. You know, today I think our interest is about performance. So we decided to go with performance because it's a topic that not all the developers has focused on, and especially Salesforce's majority of time it's a B two B platform, so the performance people don't pay that much attention. If it's the B two C like a Facebook app, definitely the performance is the most important key features over there. So I want to still then pull people back to say that okay, what's the the things we need to pay attention to performance? So that's the main reason I want you to to coach me on this little podcast. Yeah, and I think it's interesting when you say about the the B two B and B two C side of things because the powerful things of Salesforce is that, and I don't don't want to sound like a marketing person here, but is it it has really kind of consumerized the enterprise a little bit more. You know, it. I mean, when I so when I first started working with Salesforce, it was just as What is now classic was being rolled out. So there used to be a previous thing called classic, and it was called the Aloha release. And so you know what the classic
[02:39] UI looks like. Well, that was brand new and very sexy and shiny to run, and it had skeuomorphic bends and all of this sort of stuff. Yeah. And there was a time when that was like the most amazing thing. Because it just didn't look, you know, didn't look very enterprise. I mean, the old, the old, old classic looked like you must have seen like a VBA form, or you know, like the really old Windows, like you know, ninety x. Yeah, that's Java, Java related, or exactly, yeah, anything that's got a grey box somewhere. And that's, and I think that's the interesting thing is that when we talk about why why performance is interesting, it's because. Because Salesforce has consumerized a little bit, you know what? It's not going to be, it's not the most sexy software. It's not going to be as good looking or as wonderful as you know, as you said, Facebook or Netflix or ever. But at the same time, if you compare it to most other enterprise systems. Actually, it's pretty good, you know. And so I think that there is there is a big thing around you if you, and especially as people are using it for more and more. Yeah. If it was just for sales, then yeah, Joe, you're logging an opportunity, you're making a call. It's pretty easy. But as you start to get into all these different things, performance can really have an impact. And especially as you now go out into communities and Heroku for engagement apps, you know that's dealing with consumers. There is a yeah. There's a really large even with your partners. You know, I mean, we've all used the Partner Community or
[04:10] the Trailblazer Community or whatever version of that you you might be on, and you're a consumer on that. If you're a If you're a partner logging into a community to just log a lead for for Salesforce or work with marketing teams elsewhere, you're a consumer, and so you've got to be treated in that same way. And that's that's I think one of the things that is really different now is that. People have had people have these expectations. They've changed. You know, I want I want my apps to look like Netflix because Netflix is super easy for me to work with. Yeah, those those are really good arguments. And also, I know Salesforce has this commerce cloud, which is really B two C focused. So yeah, I mean developers do need to learn that. Before we really dive into our meet today, I still want you to introduce yourself. Yeah, sure. So my name is Paul Battison. So I am a, I think five or six time MVP now. Kind of I've lost out. But I am the CIO of Cloud Galacticos, who are a UK based consulting partner. I've been working with Salesforce for about ten years now. Have done numerous different roles as product manager, TA, consultant, you know, developer. And yeah, been probably best known for some of the weird and wonderful talks I've done at Dreamforce and London's Calling, and and running the North UK developer group as well. So, you I'm pretty easy to find with a with a distinctive surname like that. All right. Let's start
[05:40] diving into our main topic. So, performance again. It's a big scope of a lot of stuff. So, how can we use our Thirty minutes today just to talk about the performance. How do you want to scope it? Yeah, I mean, so it was one of those things I started getting interested in a few years back. And again, it actually started off because I was being I was working with another language. I was doing some JavaScript work. And one of the things I think is interesting about Salesforce compared to almost any other development platform now is Salesforce has governor limits. So when I'm doing work on Heroku or You know, even on iOS nowadays. I mean, ninety percent of iOS apps don't need to worry about performance. You've got a supercomputer in your pocket, and all you're doing is rendering a list of items. I mean, like you know, the app I probably use most is. Know Twitter or Reddit or some that, and that's a really simple app where it says get a list of data and display it. Like you know that does not need a two gigahertz or four gigahertz or whatever it is now like sixty four bit supercomputer to do it. That's really simple. But on Salesforce, you know you have a set CPU time, you have a set. Um, set amount of heap. You have a set amount of resources, and Salesforce is also multi-tenants. Obviously, everyone else has the same. So the faster everyone can get things going, the faster everything will be for everyone. Um, and yeah, so it was just something I got interested in,
[07:10] and then started looking at. I was doing a bit of work on. I was doing a machine learning course. Um. And was getting into that, and I was like, I wonder if I could do this on Apex. And I had someone I was just chatting with a good friend of mine tell me, no, you can't do that on Salesforce. And as soon as they said I couldn't do that on Salesforce, I was like, I'm going to do a Dreamforce this year, and so we actually had like a a bet that I wouldn't be able to get this thing done. It was it was like just a pint of beer; it wasn't a big bet, but yeah. So, but to do that though, like your processing, yeah, AI requires thousands upon thousands of rows of data to be to be worked on, and so. You've got to do a lot of work with that. So performance is a key thing because if it takes three weeks to do it, well, it's not useful. And so yeah, I started diving into how can I make just this code more performant on Salesforce. How can I do that? And then started to release a few. There's a couple of YouTube videos on my CloudBytes TV channel where I talk about like loop speed and things like that. And yeah, that was really how I got into it. Was me, me looking at it from a really awkward angle. But I think it's a really important thing. Yeah, as you say, as we discussed around the consumerisation of things, but also just. If you look at the transaction lifecycle of something you're doing with Salesforce, there are big areas you can make improvements in, and it's only going to benefit your user and only going to benefit you. If you make it fast, you
[08:40] don't want to prematurely optimize. As Donald Knuth said, that's the root of all evil. So we don't want to do that. But on the same focus, like if we can, we can make this little thing as fast as possible. It means then when our customer then says, oh, and I also want this thing. Well, we're not so worried about like you know the dreaded 101 SQL limit or CPU timeouts or heap size or all of these other things or view state. You know, less of a problem now if people are using Lightning. But view state, God, everyone used to hit that all the time. So, see, that was that was kind of where I came from. It was just thinking about how can I make things more performant, and then it got me looking at. Really, the the life cycle of an Apex transaction and why it's so important to to kind of nail that down for you for your end users. So yeah, I understand for the machine learning, you need to load a large volume of data to train the model, right? You have to do that. So you try to put that loads the data and then process the data and do it in the Salesforce Apex, the Lightning platform. Okay. Yeah, that sounds really interesting. But yeah, I had the same puzzle. You know, I had the same question: Are you really able to do that? So that's where you start with your performance journey, right, in the Salesforce. Yeah, exactly. Yeah, so me and there was a colleague of mine, Jen Wire, who she did the talk with me. So the pair of us did that, did the work on that. And yeah, it was just us trying to bash our heads against how do we make this thing faster. And
[10:11] then from there, yeah, it was kind of like, okay, well, how do we make everything faster? How do we get better as a as an overall team? Because I think that's again, it's an area of Salesforce that I don't think a lot of people. Are looking at it's a very important area of Salesforce, and it's also more of an art than a science. So. In the past, I had the Dan Appleman coming to the podcast. I think he shares the same feature that you have: is that the. The governor limit is something he's really fascinated about. He loves to do things within the governor limit. He loves to improve and optimize his code, and to meet the governor limit. So I think that's like a one feature for good developers. I think there's a there's a really interesting thing where you talk to different different developers, and so um, uh, you know Simon Goodyer, yes, yes. I've had I've seen more than one talk by Simon over the years. He's always a really good speaker, really engaging. But he does one talk about about the governor limits. And he just says they're the best thing ever. And you know, I think there's a number of like senior developers on the platform who've been working with it for a while. So Dan, Simon, I think if you talk to people like you know, it's Nulty, Keir Bowden, you know, you know, Kevin Pullman, all of these people, you talk to Andy Forceit, they'll all say like, oh yeah, the governor limits are fantastic because they force you to think about it. And we think it's I think it's when you're coming in clean and you're like looking at it brand new that you're like, oh. Why why why is this happening? Why am I doing this?
[11:41] Isn't this on the cloud? And I think it's that's the difference is that kind of perception as to why it's there. Yeah, I think it feels like you go back to the good old days when you play with the embedded systems that has really limited memories and the CPU, right? Yeah, I think that's probably as well. I mean, most of those people and. Apologies to everyone I've just listed out there with the next phase, but most of those people are also old enough to have done programming before Salesforce. That's probably the bigger thing as well. Like, if you've done anything on other systems, especially like back in the nineties, then yeah, then you are really more aware of it. Whereas if you are, you know, if your first experience is. For a lot of, especially for a lot of computer science graduates now, their first experience is, oh, I've got you know a four-core laptop, and then I'm going to run it on AWS where you know processing is cheap as can be. Yeah. Yeah, you're less worried about it, shall we say, than if your if your first thing was deploying something to a client's app. Yeah, yeah, indeed. So about performance, as I like naively, I can put them into like two categories. We can say the front end has the performance, right? That's like the rendering on the client side, either on the laptop browser in the mobile app, and also on the backend we have Apex and like trigger and those contexts. So. Can we talk about these two different areas? Is that something you want to
[13:11] share with us? Yeah. So I think so. I think it's really important to see the the two. I like the way you separated the areas because I think the the two areas are dealt with separately. In the way you, in the way you analyze and what you can do on them, but I think it's also important to realize the two are very interdependent. So if you think about how your how your application runs, so say say we're talking about a Visualforce page for an example at the moment, yeah. There's a series of steps that happen. So obviously it makes the request to the server, and there's a bunch of things that go on. It loads up the data, runs the controllers, blah blah blah blah blah. If you're saving a record, it will do triggers and also then do workflow rules, processes, assignment rules, flows, blah blah blah, all of that stuff. But there's one part of this entire thing you can't control, which is where you need to pay attention to what you're doing as well. And it's really interesting because it's the it's that the connection between the two. And I'm going to share a little story. I once had a client who worked in a big bank in London, and he he rang me up one day just saying, "Oh, you know, it's Salesforce is being really slow." And I was like, "Well, you know, it's a bit of a generic statement. What do you mean Salesforce is being really slow?" He's like, "Well, I'm trying to load this page and it's taking." X number of seconds to do so, and it's slowed down. I'm not happy with it. And he was genuinely sat there with a stopwatch, clicking the button, starting the stopwatch, clicking the button, and then stopping the stopwatch when the page loaded.
[14:42] Yeah. And I sat there and you know I had to I genuinely had to record a video from my laptop, doing the same thing to show him that it was his internet connection. And that's the thing, like yeah, there's a lot of you. You can't control the speed of that connection. So you know, people are on 3G. You know, if they're lucky, people you know might be on mobile devices. People might be just in a bad area. You know, all of these different things. People might be in an office where someone's you know streaming Netflix at the same time. Yeah. So you've got to be aware of those things. There's that you can't control, which is fine. You know, you kind of have to almost forget that. What you can control on that is the amount of data going between the two. And it's then thinking about the impacts that has. So, let's just take the front end for performance as an example. Well, first of all, the there's the rendering. Okay, so there is there's all the Chrome Developer Tools that you can go through and think about how quickly things paint and when they're sharp and the first item to render and things like that. But when we're talking more about Lightning, for example, it's getting the data. So how is that data retrieved? How much of that data is retrieved? How many requests are you making? You know we're not living in a world yet where we're all on HTTP 2 and we've got this kind of long-term connection where we can make multiple requests. Most people are still on HTTP 1 or 1.2, I think it is, making requests backwards and forwards, and so every time a Lightning component goes and retrieves data, well, it has to go up to the server. And then back down to the server. And although you can control the speed of the other things,
[16:12] that network connection you can't control. So, how much data should you bring down at once? Should you bring down a lot to try and load it all up, or should you bring down part of it and then lazy load the rest as you go? And that's a really interesting thing to think about. Because of the fact there's no right answer to it. Yeah, it's it feels more like a really a software designing case here. So it really depends on the case and the scenario. So then you find the best one feeding into that context. And from the technology point of view, either method you you mentioned, for example, the lazy load or load everything down in one go. So they both of them have pros and cons, right? That's what you want to mention. And actually. I recently did an interesting thing on my website, the SalesforceWay.com. Is that I I went to the the Google to analyze the speed of the homepage. It was bad. It was forty score out of hundred. And then I did some analysis. I realized like a lot of CSS is not really needed. For example, I had this font awesome. This which can render the icons on the page. Oh yes, yeah,
[17:29] so I use like five icons. But that CSS is like hundreds, hundreds, even thousands of the icons into your CSS. So I finally decided I don't need those five icons. I just get rid of this, and then the the site speed immediately improves drastically. So that's the thing you need to at least to me is you need to analyze, you need to understand what things are happening, and then get rid of the things you don't need. Exactly. So one of the things, so I spoke about this a couple of years ago at another London's calling. So, but one of the things I talk about there is so the military have this this methodology called OODA, and it's observe, orient, desired, and act, and that's the way I like to think about doing these things. And you've just described exactly that process. There is that. Yeah, when we're when we're designing software as as architects or developers, we don't know everything. You know, that's kind of part of the fun of this is that you know you don't know what it's going to get there at the end. And I'm almost sure that as soon as you show someone something, they're like, ah, can we just make that one change? And that one change could have cascading effects. We need to rearchitect the entire thing. But when you get to doing The kind of the performance analysis things is that you should, like you did, you should observe. So you noticed, noticed that things were slow, and you had a look at where they were. You did some orientation,
[18:59] so you looked at the actual data. Why you know we're loading up fonts, awesome, that takes up a lot of space. You then decided, well, I don't need those five icons. And then you acted, and you had that correct response. Now another valid response is often going to be, I do need those five icons. I'm just going to get those five icons, or it could be I do need those five icons, and I want to be able to download the rest. So I'm going to have them all in there, but you've got to kind of make sure you follow that process. And I think from a developer's perspective, when you're talking to, especially talking to the business about this, is that the business only ever says this is slow or this doesn't work. Yeah, it's always a software development's quite a hard game because. Typically, users only come back to you when things are broken. No, no, no one ever reaches out to you three months later and says, "Gee, that that piece of software you built me, that that Salesforce system, absolutely cracking. Thank you for that." They they don't. They come back and say, "This isn't working. Why is Salesforce always broken?" Yeah, blah blah blah blah blah. Yeah. Um. And so, but to try and tell them why you're doing some performance things, um, having that defined methodology. Allows you to also capture those metrics as you go, and and that's the key thing is knowing what metrics to capture and what are important and when, with those business contexts in mind. So you know if they do want to see all of the things on the list, well, that's a requirement. But they then need to understand that there's the trade off of that of. If you're downloading a thousand records, it's going to be slower than if you're downloading ten.
[20:32] Hey, thanks for listening to the show. Salesforce Way podcast is all the time looking for both guests and topics. If you have guest recommendation or any topics you'd like to listen to, don't hesitate to let me know. My Twitter, LinkedIn, and email information is at the end of the show notes of each episode. You can also find it on the SalesforceWay.com website. I really, really, really need help from you on this matter because only you, my lovely listeners, know what yourself want. So, please help me invite great guests to talk on great topics so that we spread great knowledge. Now let's get back to the show. Indeed. So nowadays, since we're talking about Lightning Web Component in Salesforce, that's the future, and that's really close to the cutting edge JavaScript things. So tons of information and books, whatever you can learn JavaScript performance, right? Yeah. Yeah. So everything's there out there in the internet. So for Salesforce developer to learn. Yeah, and there's also, I mean, everyone should just get extremely familiar with the Chrome Developer Tools. There's there's even a feature now that I learned the other day where
[22:02] if you are running, so top tip for people, if you're running a Lightning Web Component and you have all the debug turned on correctly, if you then press record and reload the page, so you know you can record a page load on in the Developer Tools. If you then go and view the source code, the JavaScript, it'll tell you how long certain functions are running for. Really, so you can then see. Yeah, I didn't know this. I didn't know this. It was a new feature, right? I think I stumbled across it on like one of the Chrome Dev Tools team's blogs. But yeah, it's really, really quite useful because you could then go ah, like and obviously there's certain things in Lightning you can't change and control. Yeah, there's a bunch of boilerplate code from Salesforce, but within your code at least you go okay, I'm looping through these records and I'm doing two loops and I can do this in one if I use a a map or something. That's going to save you a bunch of time. Yeah, I had an instance the other day in Apex, not in JavaScript, where someone was doing two loops, and they were doing a loop within a loop. And it was one of those things. It was in a trigger, and yeah, just if it scaled, you know, talking about that kind of order of magnitude thing, yeah, it scaled, but it scaled in the wrong way. So if they would have had two hundred records, there was an edge case where they could have been running this thing like twenty thousand times. Whereas if they if they used a map, they were only even going to run it four hundred. And that's a massive, even if it's only nanoseconds or milliseconds running through each time. Do you know what? Twenty thousand milliseconds is two, you know, is you know a lot of time that we can save back for the user in the background. And
[23:32] yeah, I don't know if Christian Sandor Nap, another MVP, did a session at. He was. Your dreaming, or or check dreaming, I think it was called this year. Yeah, yeah, this year it was really recent, but it was comparing. Flow, process builder, triggers, and I think that was it to doing some processing, and it's really interesting to see how that scales because you know again yeah a lot of people are now using flows to do simple tasks yeah but a simple task done ten thousand times becomes quite a complex task and so every yeah it might only be point one of a second slower to do it in flow rather than code but if you end up doing that thousand times that becomes. A lot more time, yeah. So that's again the sort of things you need to think about on this. Yeah, that's a good topic. We know that the flow process builder is slower than code. The Apex code in most of scenarios, but we don't know how much slower and in what scenario. Is like a large volume of data, or medium, or small, and what's the the the differences? So I think that's a really good topic. I don't because Sandor was in my podcast, so but I did I didn't know he made this this talk. But I mean the data of that topic, if he can you know publish it out the slides. It would be really interesting for people. It's all it's all published somewhere. So I think if you go onto his Twitter, okay, you can find it there.
[25:03] Okay, I will ping him to get it. Yeah, but no, it's it's a really good talk. But I think it's also really interesting that. But yeah, there there is a really shot out to that, which is code is always faster. Code is always going to be faster than a tool like Flow or Process Builder, which is an abstraction of that code. That's just the way it works. In the same way that writing something in you know assembly is always going to be quicker. If you run it in assembly, then running it in Java, or then even running it in like you know Python or Node or whatever, yeah, or JavaScript, yeah, yeah. But it's the developer speed, and that's where Flow comes into its own is that you don't need a developer. So yeah, it's not just a pure numbers game on the performance side. It's also that developer performance, I suppose. Is an interesting way. We'll come up. We'll coin that term right now. Developer performance. There you go. That's for us. Which is how fast the developer or the team can get it done. Yeah. Cool. Cool. Since speaking of the backend performance, we talk about the flow and those declarative tools. But I understand if you are only process small number of records, for example, just one, like the controller, then those performance issue does not bubble up to the surface. But if you start to have medium or large size, those things start you really need to pay special attention to. Yeah, I'd say that's a fairly good way of of thinking about it in you know in kind of general terms is that yeah one record two records you're not going to notice it so much again you should
[26:33] be aware of it because. Yeah, we could. Maybe in future somebody will use it as a data loader or whatever, right? Well, not only that, but I'm sure you and I could sit down and write some horrendous code that runs really slowly, but is only retrieving two records. Like it's it's really doable. But it. I think yeah, as you get more towards those those limits of of use, yeah, as you're doing, yeah, once you get over twenty, thirty, fifty records, you know, then start really thinking about it. But to to go back to what you were saying about it's you know the the Google case is an extreme one. Well, yeah, I've worked on systems on Salesforce, so. We, I've worked with communities where there are well over half a million users. You know, I mean, if you, anyone ever goes through the TA review board exercise. They will. I can almost guarantee you will get a communities example on there that has over a million users just because they want you to come up with the correct answers for it. And so, it's you know I'm working with a client at the moment on a data archiving solution. They have like 75 million like customers. They've got loads of data, so yeah, there's there's lots and lots of situations where that easily builds up because it happens over time, and so yeah, yeah, you're right. Some of these things are edge cases, but there was one one system I worked on many years ago where it was a Heroku Connect system. It was one of the first Heroku
[28:03] Connect systems, and it synchronized around seventy million records on Heroku Connect. So a lot of data, but the reason being is that it needed to search through that data quickly, and at the time we couldn't do that on the standard platform. Yeah, we had to do that using Heroku because you can add different indexes and things like that on Postgres. And so, you know, there's a lot of although we might think of them as pure edge cases, these things can pop up just. Just out of the the woodwork, and I suppose my my other thing would be is you know you're being we're all developers we all want to do the best work we want to do. I genuinely believe that every developer goes in to do the work, and you know no one sits there and goes I'm going to do an absolutely terrible job on this because I hate it. Yeah, you want to go in and do the good work. So if you're gonna if you want to do good work. Try and make it as good as possible, and part of that being good is performance. Make it as performant as possible, and just you don't have to spend hours on it. You just have to sit down as you're doing it and think, could I make this better step by step? And if you do it there, you'll find it much easier than. Then, if you come back to it when there's a problem, because again, you a a limit that says you busted a governor limit that never happens at a good time. Yeah, you're gonna you're gonna break a governor limit when you're doing your initial data load before your go live weekend, and that's when you know. Everything's going to be on fire, you know. The things are going to hit the fan, you know. All of that stuff. So you don't want to do it then. You want to do your testing upfront
[29:33] because then you can have a nice easy weekend. You can click the deploy button, everything goes live. You can be sat with a beer at five o'clock on a Friday afternoon, rather than sat there going, "Oh dear God, why is this all breaking now?" And you know, narrowing down those uh. Those issues. I had a company I worked at once where I spent about four days just going through and trying to figure out why unit tests were failing, and it was just because of data volumes. And you know, just the code was really just not written to handle these things appropriately, and so we, me and another colleague, ended up spending time just like moving around the test dot start test just to try and figure out where we could move the context to try and get the test to pass because we couldn't. There were certain things we couldn't do because of the amount of data that needed to be set up for that test. Okay, and so this was this was before setup methods, before all these other things. So the only way to do it was a static block, which then was running and your consuming resources. And so yeah, like we had real issues. I'm doing it, and the time that that came up was when we were running all the tests just before go live. It wasn't when we were, you know, midway through a sprint and you sat with our feet up. It was as you know as it needed to be ready, and that's I think the the scary thing about this is that performance only matters when something goes wrong. So you're better off thinking about it early. Yeah, and also that comes from the working experience as well. Like me, I rarely working with a large volume of data, so I don't really have that experience
[31:03] in Salesforce. For example, you have worked in the banking system. You have a large data, and the transaction is critical. So you have the thoughts that other developers who are not working in the same industry, you know, you have more thoughts on on these performance things and how to guarantee the transaction will succeed instead of fail. You know. Yeah. No. There's definitely. I think there is, Joe. I think part of every everything, probably just in life in general, let alone just in development, is is you. It's um. It's breaking things enough that you know how to fix them. You know, it's I. I wouldn't say I've got any smarter. I probably just got better at Google and Gera messages. You know, that's that's really what you know. All senior developers and all technical architects are just really good at going. Oh, I've seen this before. What was it? I Googled for it to find it out. Yeah, there's even there's even instances where you'll see people like. I genuinely have found my own answer on Stack Overflow before for a problem I was having, so I have answered my own question because I've forgotten what I was doing, and that's that's just life and how it happens. But I think one of the nice things about the Salesforce community is that people are very willing to share these ideas. You know, it's if you have a Yeah, I mean, so there's another another Salesforce podcast I listen to, the Good Day Sir one that has a really vibrant Slack community, and you know, there's always people posting up there like, "Hey, I've got this
[32:34] problem. How do you how how would you go about it?" and You're effectively getting free consulting there from a bunch of really intelligent, way more intelligent people than me. Yeah, there's people like Chuck Liddell on there, and Jeremy Ross, and John de Santiago, and John Daniels, and loads of really smart people. Robert Sosman's on there, loads of super clever guys. That are going to give you that for free, and just because they want to help out, and just because they've got that experience, they're not going to sit there and go, oh, by the way, there's there's your invoice for like two hundred dollars, go for an hour's consulting. It's yeah, and that's. But I think that's one of the real nice things about Salesforce is that you can go on Twitter, you can go on some of the Slack channels, go on the communities, on the developer forums, on Stack Exchange, or different community events, and people will help out. People people like to help and share their ideas. Cool. So Paul, we started with performance. We talked a lot to talk at the frontend. We talked at JS, how to render the CSS and the things we cannot control. And then we continue to talk about the backend, right? The Apex, the all those. Batch different context and we end up in Salesforce community. How wonderful it is! Nice, nice little virtual. Yeah, yeah, virtual circle. I do. I think it's a good moment for for us to round up. I don't know. Do you still have something else you still want to add? No, I think that's good. I mean, I can I can talk about this and many other things for hours on end. So, I think we'll I think it's right to put a pin in it here, and you know we can always
[34:04] go into more detail another time if we want to. Really love have the conversation with you, Paul. Yeah, it's been great speaking to you. No, thank you for having me. It's been fantastic, and it's a great show. Thanks, Paul.
[34:32] Oh, oh, oh, oh, oh, oh, oh, oh, oh
[35:03] Oh, oh, oh, oh, oh, oh, oh, oh, oh I'm sorry, I'm sorry.
