Paul McCollum is a Salesforce Technical Architect over at Accenture. Though he pursued various interests in college, he eventually came to pursue a degree in Computer Science. From there, he began his first job as a Unix programmer and then found his way into architecture.
In this episode, we talk about just that: all things architecture. Paul shares some cool concepts with us regarding application design, UX, and big-picture architecture as well as what’s coming up for architecture in the future. Tune in to hear it all.
Show Highlights:
- Paul’s long history with computers and architecture.
- How he discovered Salesforce.
- Why the overlap between user interface and big-picture architecture is important.
- The level of planning and documentation an application owner can do without a designer.
- The rising importance of technical designers.
- Architecture blind spots Paul sees on the horizon.
- A hack that allows flow to work with infinite records.
- How Paul started getting involved in the Salesforce community and his current role in it.
Links:
Episode Transcript
Paul McCollum:
Nobody else had tried to give it more than the screen pixel width. So, I’ve been breaking stuff and breaking computers, melting CPUs for a long time.
Josh Birk:
That is Paul McCollum, a Salesforce technical architect over at Accenture. I’m Josh Birk, your host with the Salesforce Developer Podcast and here in the podcast we have stories and insights from developers for developers. Today, we sit down and talk with Paul about a bunch of stuff about architecture, about his history in computers and, of course, we will start as we often do with his [inaudible 00:00:40].
Paul McCollum:
Well, actually, yeah, computers weren’t a thing whenever, I set my focus on being a geneticist.
Josh Birk:
Ah, okay.
Paul McCollum:
So, I was always taking stuff apart to find out how it works, I expected it to be people and genes and computers weren’t really a career, they were just a fun thing you played with on the weekends or after school.
Josh Birk:
Got you.
Paul McCollum:
So, slowly but surely, that became a career but it wasn’t until after and I’m not one to give up on things. So, obstinance made me complete my degree in microbiology and then switch over to double in computer science, linguistics and mythology, Chinese, chemistry and ballet
Josh Birk:
And ballet. As a minor?
Paul McCollum:
As a minor, yeah. Minors in this.
Josh Birk:
That is awesome. I believe I’m outing maybe a little bit here. I think you share that past with Mr. Kevin Portman, I think he’s got a background in ballet.
Paul McCollum:
Oh, really? Oh, no, I didn’t know that.
Josh Birk:
Wow. And excuse me if I’m staying the obvious but did you go to France to learn French?
Paul McCollum:
I did a short study abroad at Paris studying primarily French language. It was more of an enhanced vacation because I’d been taking French for my whole life, I claim that as ancestry-
Josh Birk:
Oh, got you. Nice.
Paul McCollum:
… but it wasn’t. Fun time at Paris.
Josh Birk:
A nice way to put a cap on it.
Paul McCollum:
Yes, finally got the exposure. In Oklahoma and Texas, you don’t get the opportunity to speak French as often as you would think.
Josh Birk:
Yeah, I come from Decatur, Illinois, I hear you. I definitely hear you. Sometimes you don’t get that great of an opportunity to hear English, so that’s a thing. So, what’s your earliest memory of a computer?
Paul McCollum:
Ooh, earliest memory of a computer. I think I got introduced to it, it was a new shiny in the library of my elementary school.
Josh Birk:
Oh, nice.
Paul McCollum:
We had three of them, they were black and white and Apple IIs, [inaudible 00:02:31] and they had gone out on a limb and purchased the Logo logic board that made show turtle a thing.
Josh Birk:
Yes, yes.
Paul McCollum:
For people who know Carl the robot and then programmable, there’s been a handful of other rebadges of it. That show turtle was my first programming language.
Josh Birk:
Yeah, and in Logo, you could tell the turtle to go this way or go this way or do a little dance and all of that kind of stuff, right?
Paul McCollum:
Well, back then, it was a triangle and you could tell it pin up, pin down and go forward and right turn 90 and left turn of a hundred and I was the one that figured out that it could actually go off screen. Nobody else had tried to give it more than the screen pixel width. So, I’ve been breaking stuff and breaking computers, melting CPUs for a long time.
Josh Birk:
I so appreciate that. My earliest computer science class in college used Logo as its primary programming language for some reason. And I had a task to write a program that could convert from Roman to Arabic numerals and back and forth and it worked perfectly five times. And I tried to fix it and tried to fix it and, eventually, I just wrote the professor, I’m like, “This will work perfectly five times. If you can tell me why I would be” … And he never responded, I think he gave me a B minus or something like that and then we just moved on our life.
Josh Birk:
Now, some of your early thoughts are really pretty eclectic. Not a lot of people go from, say, Unix Development to director of web development. How does that transition happen?
Paul McCollum:
Interesting. Yeah, no, I started out with a lot of good and I was appreciating my exposure. My high school gaming friends and getting into a couple of different places led me to land with a lot. I watched the computer world build up from the modem era so I had an architect’s level experience by the time I entered the ecosystem. So, at OU I’ve been working with exploiting weaknesses and network to get my homework done and be able to print over the modem into the computer lab. So, I got to fast track, I got way too much experience early on. And so, I went in, my first job here in Dallas was as a Unix programmer and then went almost immediately to Nortel as an enterprise architect.
Paul McCollum:
The internet really wasn’t the internet until it matured from the LAN, so Nortel put a lot of that fun network infrastructure in place and I got to be there playing with that and those things. It was a nice playground, I was a kid in the candy store.
Josh Birk:
So, you were the Jack of all trades from the early days?
Paul McCollum:
Yes.
Josh Birk:
Got you. And on that note, I have to ask, okay, so what does a news editor for an online electronic store do?
Paul McCollum:
It wasn’t an electronic store. So, Engadget, you’ve heard of it?
Josh Birk:
Yeah.
Paul McCollum:
So, back in the heyday of prosumer gadget blogs, I worked for one of the top 13 news websites as their primary news writer. EverythingUSB.com is where I got a ton of exposure and started writing content and it was doing really well until the Google Panda algorithm changed and that killed our profitability.
Josh Birk:
Yeah, yeah.
Paul McCollum:
You don’t get much nerdier than talking search algorithms with people.
Josh Birk:
This is true, this is true. And when did you first discover Salesforce?
Paul McCollum:
It was around 2003, 2002. When I left Nortel and went to work for a startup, right before the director role, I was starting to see some of the bigger software patterns where platforms were turning into mature platforms or raw programming languages were turning into platforms and Salesforce started to peak out. I knew of it, I heard people tell me about it and so I just kept an eye on it as where it stood in the Gartner Roadmap of best of breed for what it does. And I worked in a lot of industries that had trouble making good technology investments because they were trapped in their own lingo. So, in real estate, if your software didn’t speak real estate lingo, they didn’t buy it.
Paul McCollum:
So, I was always watching and then I got a good trigger when we were doing our mobile workforce enablement at 7-Eleven and I was like, “Okay, if you take out the retail and the franchisee and you just talk mobile workforce, the tool you want is Salesforce.” And I spent two or three years learning it so I could make the case because I still believed and all of the Gartner enforced reports still said that I was on the right path and the right direction with the right tool. I learned too much and got addicted to the Kool-Aid and I decided, after making that pitch and landing it there, that this is what I needed to do from now on.
Josh Birk:
Got you. Nice, nice. It is. We’re so on the other side of the tunnel when it comes to mobile now that, during my evangelist years, I’d say three or four of them, mobile was, that was the hot thing. That was like we are going to prove we’re cutting edge because we’re going to run everything on the phone. And now, that sounds like, well, of course. But back then, it was like trying to shove up a big square thing into a little round thing.
Paul McCollum:
It was an interesting time. And I still have a buddy who I get Christmas gifts from, when he asked me about doing lap development and I told him no. Do not go into lap … The convergence is coming, you will not have to write lap code which is the old school feature phone, LCD screen web technology and I still don’t think mobile … With the fold, mobile has almost gotten there but that wide screen touchable interface is still where the peak of UX is and everything else is just temporary until we get to a more transportable version of that.
Josh Birk:
Yeah, exactly.
Paul McCollum:
So, I’m with you the same way. And it was so funny, there was a one year period where we couldn’t get people to use mobile phones and then the next year they’re like, “Why isn’t there an app for this?”
Josh Birk:
It was like the rise of the worldwide web and I had almost the exact same experience. Before I joined State Farm, I spent a whole summer going from businesses being like, “There will be a time that, if you don’t have a website, you were just going to lose people. This is going to be a core portion of your business.” and they were basically like, “Hey, skinny kid, get out of my lobby.” And I’m like, “But no, I swear.”
Paul McCollum:
Absolutely. Yeah, I approached my apartment complex that I was running in college, I approached them with the idea of wiring it up for internet as something that would be a good idea for their tenants and possibly a good side business for them to get in and they laughed me out of the office.
Josh Birk:
So, I think we’ve answered this question to a certain extent. You were always down the architect’s route. It wasn’t like you were doing a little development here, a little development there and you thought this was the shiny new route. This is how your mindset has always worked?
Paul McCollum:
Yeah, I’ve been a programmer by opportunity and that’s been the most in demand skill for a lot of my time. I’m not a very good shift gears programmer.
Josh Birk:
Got you.
Paul McCollum:
So, yeah, my wife and home life suffers whenever I’m trying to program if I can’t do it under eight hours. My head is still working on code over the weekend, overnight, during conversation. So, architecture and trying to help people understand different paradigms because I’ve seen, when I populated the chips on the motherboard to make stuff work and can see all that stuff in my head, I think that’s what’s given me an advantage of being able to break things down and share paradigms with people and they don’t seem to make up and that’s what I consider architect role.
Josh Birk:
Got it. And to dig into that a little bit because, when we were talking before, you were talking about the cynics and an overlap that I certainly hadn’t thought about much before. But overlapping user interface UX and I believe you described it as big picture architecture, walk me through what you mean by that and why it’s important.
Paul McCollum:
So, a lot of times, when you’re doing integrations and you’re doing big picture systems that have multiple systems together, there’s the cup and a string interface that you’re … I use the analogy that I’m bad at when I’m doing dev and I try to do UX at the same time, but if I get into dev mode, I see error messages and not error messages, very binary and I’m terrible at doing user experience. I think integration architects fall into that same trap of we need to get these two systems hooked together. Okay, well, we have this interface and this interface. Good, that’ll work, here’s the password, this is how we’re encrypting it, done.
Paul McCollum:
And I’m usually watching for it, okay, will you be able to get the right shape of data that the end user needs so you don’t come back and rebuild this twice? Do you have an elastic search interface or is it just a single byte for byte interface?
Josh Birk:
Got it.
Paul McCollum:
So, will you need that data in your system so you can run regular queries of it or can you query real time to do it? Is the dropdown okay to be populated asynchronously? Is it too big? And so, seeing how users are going to consume data, I think, makes me a better first draft architect because I’m, hey, no, we need a wider pathway. No, we’ll be just fine with a message queue, this is all we need for that.
Josh Birk:
Right. So, it’s come up on the pod and I won’t mention the company’s name but we did this work for this company and I kept asking them for production level data that we could develop off of so that we would be able to realistically build a user interface would work. And the first time they got back to me, they gave me 50 rows and I’m like, “No, no, no, no, no. I need data that looks like production.” They gave me 500 rows, I’m like, “I still don’t entirely believe you,” and they’re like, “No, this is what our production data’s going to look like,” kind of thing.
Josh Birk:
And so, then we deliver, deliver, deliver and we go into user acceptance testing, which was the first time we went to the sandbox with production data, and it was more like 175,000 rows. And so, I feel like this is indicative of exactly what you’re talking about. We were lied to about what the data structure is looking like. So, what you’re saying is, go one step further and figure out, first, what data structures are going to be friendly to the UI and then also what event structures are going to be friendly to the UI?
Paul McCollum:
Mm-hmm.
Josh Birk:
Okay. How do you do that? Who do you put in the room to make sure that that’s happening correctly?
Paul McCollum:
That is the harder part of the question and I’ve gone through trying to map out the roles that need to be alive, whether there’s somebody who’s data governance minded or master data management minded, and it always depends. It depends on the size of your environment whether those roles will even exist because of the scales that you need to have in order to justify them. If not, you really need to figure out … To me, it’s an application owner that understands the shape of their data or a functional owner and you have to put those requirements on them early and you have to start asking those questions.
Paul McCollum:
Sometimes those questions don’t get asked until, all right, we’re online. Yeah, the interface is terrible, I’m not going to use this. Oh, well, okay, but we’re finished.
Josh Birk:
Right.
Paul McCollum:
Yeah, that’s not okay. I’ve had a couple of projects head into mountains as a consultant and as a concerned stakeholder and it’s not fun.
Josh Birk:
Right. It is not fun and I have been on more than one unfun business trips because of exactly that kind of thing. Because it sounds like there’s a level of specification here that isn’t always there which is not just … Because when I think of this is what you need to build for me, here’s an object, here’s its fields and things like that but I don’t know if there’s a lot of discussion as to what the purpose of that object is. Is it going to be used in a platform event for real time, asynchronous or is it just going to be a lightning web component? Is there a level of planning and documentation that the application owner can do but he doesn’t necessarily need the designer in the room?
Paul McCollum:
Yes. For a good application or a functional owner that is versed in the data and where they play a role in that ecosystem, yes. What ends up being a problem is fairly flat rolls where I own these screens or I own this business process and I click these buttons and, when I push this button, I get my cheese or my fish pellets over here.
Josh Birk:
Right.
Paul McCollum:
As UX is spiraling off and becoming its own thing, UX is having to become very technical whenever you have smart platforms. The art of the possible in platform development is hugely important so you need to be highly technical. You can’t just say give me an interface with the data here in the center and three buttons at the bottom. Well, if that’s not a native version of the platform, then you’ve just prescribed custom and you lose some of the value of the platform. So, there’s highly technical across domain skill sets are becoming more and more important when you get to that scale.
Josh Birk:
It’s interesting to me because it feels like, as the various roles in our community have expanded their scope … So, for instance, at one point developers obviously have to have a strong understanding of the core functionality of the platform because that’s how they make things work. But eventually, we need developers and administrators understand each other’s roles so that we know where things pair up and then where an administrator should just come in and build that flow whereas maybe the developer’s putting in the application layer.
Josh Birk:
And then there was the rise of the architects and it’s like, well, we have to have people who are putting this all together in the first place. And I think you’re right, I think we’re seeing the rise of the technical designer who is going to be able to make decisions, not necessarily on how things are going to be pretty in the long run, but functional in the short run.
Paul McCollum:
Yeah, there’s a fractal complexity to the … You said one of my trigger words for Salesforce and architect and I get into fights all the times with the terminology I use. Especially with me trying to find a role when I’m very much a Jack of all trades from a systems perspective and Salesforce is a new platform and I consider myself an orchestrator of multiple systems coming together to form a solution and that, to me, is an architect. But the Salesforce architect, so each layer you dive into has components that you need to conduct together and architect together.
Josh Birk:
Right.
Paul McCollum:
So, I struggle calling the multi-domain Salesforce architect solution architects or saying that they’re different from an architect architect, which is stringing solutions together from multiple systems, because it’s appropriate at every scale. You can be an architect down at the … You can be a design architect and an integration architect when you’re bringing relationships together beyond what’s just on the screen. That, to me, is an architect and there’s in levels of architect. So, I get really specific, the domain has to come first on architects or else I start to flinch.
Josh Birk:
Got you. Nope, that makes a lot of sense. Outside of the UX side of things, do you feel like there’s another trend that we should be looking at? Is there another blind spot that people might have in their horizon?
Paul McCollum:
The only big one I see on the horizon that is looming is the virtual one. I’d really love to see people modeling their stuff in VR now to try and come up with how interfaces will work in three dimensions. There’s going to be the first web browser for VR and whoever gets in there first is going to set the pattern and iframes are going to take … Whatever we decide to do with blinky text and iframes in the first VR browser, it’s going to take forever to evolve away from. So, I wish people were getting more into that early but that’s a little out there, that’s maybe far outside the box for trends that you were asking for.
Josh Birk:
No, I think that’s a great one, it’s come up on the show before. I think Dan Appleman was talking about, if you’re not thinking about VR right now, then you’re going to regret it three to five years from now both from application and also just from a social point of view. I think I might have nightmares tonight about blinky text, what the VR version of the blink tag is. So, thank you for that.
Paul McCollum:
Sorry, yeah.
Josh Birk:
But I-
Paul McCollum:
The walking with the hand sticks side by side motion.
Josh Birk:
Right, right. Exactly. But you’re right, we hadn’t have those little, wow, we really thought somebody needed the blink tag and we just abused an entire generation of internet users with it. So, now, trying to walk back. So, would your recommendation be, because we don’t know what that web browser looks like and just in case people aren’t rocking it, you’re not saying it’s a web browser, you’re saying it’s a generic-
Paul McCollum:
Yeah, information parsing in three dimensions.
Josh Birk:
Yeah, some kind of information interface that we will acknowledge as this is a good, common way for us to deal with applications in VR, right?
Paul McCollum:
Yeah. So, I’ll tell you what I think is the easiest one and I think we’re not at the maturity level because nobody’s delivered it. When we’re navigating spaces in three dimensions, the most common one that we have is stoplights and road signs. I have not seen an information architecture browsing system that makes use of that yet. If you want something to look like a switch, you make it look like a light switch. If you want people to put money into something and take money out of something, you’d use an ATM model. You conform to paradigms that people are already used to to reduce cognitive friction and I haven’t seen that one come up yet.
Paul McCollum:
I did a presentation at Dreamforce where I used JavaScript to load in information into VR and, actually, I used a projector in my phone to print it on the walls so everybody could see what I was doing but the only way I could arrange the data was in a climbing tower. So, when I kept loading stuff in, I was using an X, Y coordinate system and you just had to go up 10 stories to see the new document and, to see the old documents, you had to look beneath you. That’s great but that doesn’t really bring in the full 360 option that you get with everywhere your head turns is 4k of pixels to give you information. It’s a very one dimensional take on three dimensions.
Josh Birk:
Yeah. It wasn’t VR but do you remember Pat Patterson’s classic Forcecraft demo?
Paul McCollum:
No.
Josh Birk:
So, Pat, who was an evangelist when I was an evangelist, made a Minecraft mod that accessed the Salesforce APIs and would create a village and every … Let me see if I’m walking through this. Every building in the village was an account and every floor on the building-
Paul McCollum:
Oh, I think I saw that.
Josh Birk:
… was an opportunity. It did a world tour spin for a little while and the villagers were the contacts and you could actually talk to the villagers and it would show up in chatter. And it comes to mind because he nailed exactly what you’re talking about. He used a structure that is already familiar to you. And if Pat wasn’t there walking you through the demo, you actually probably figure out what was going on just by walking around the village itself.
Paul McCollum:
Got you. Yeah, I think I remember seeing that displayed around Demo Jam. I think it was the year after one of my claims to fame, or not fame, but I feel like I had the first Salesforce and VR demo ever have been integrated. So, I’m always interested in the timeline. If somebody beat me to the punch, I want to know so I stop [inaudible 00:23:12] them.
Josh Birk:
Offline, I might be able to help you research that but he definitely didn’t beat you to that punch because Minecraft was not a VR game at that time.
Paul McCollum:
Uh-huh, okay.
Josh Birk:
Okay, so going completely on the opposite end of the direction, going down to the 2D world again. We were mentioning, and I’m always wondering what my first episode’s going to be that gets me in trouble and I’m curious if this is going to be it, because slow walk me through this hack that allows flows to … Checking my notes here. Work with infinite records.
Paul McCollum:
Yeah. So, speaking on one of those scale things, I had been put in a situation where I was working with a client and I’d asked them, “Okay, we need to have an X, Y, Z happen once a month for all of our accounts. Okay, how many counts do you have?” “Oh, about five or 600.” “Cool, okay. I’m going to do that in a flow and I’m going to walk through the flow steps and I’m going to go through all these logic gates to do these fairly complex scoring.” And it had to answer a bunch of questions and there was some heavy duty logic that I put into it. There were two or three branches, there were big groupings. I was really proud of the way I had it organized because there was all these spider webs that looked complex but I grouped them and overlaid them where they were easy to read and you could see, yeah, this is when it gets to this scoring section and it exits.
Paul McCollum:
And it was really pretty self-documenting and they moved it into production and it failed. And the admin said, “Yeah, I’m getting errors.” I’m like, “We tested it, you tested it. We went through it a dozen”-
Josh Birk:
We all agreed.
Paul McCollum:
Yeah, what’s going wrong? It’s saying too many accounts. So, I was like, “Well, how many accounts are there?” “Oh, about two or 3,000.” “You told me 700.” “Well, yeah, 700 active account but 2,000.” “Oh.”
Josh Birk:
Oh.
Paul McCollum:
So, then my choice was, okay, well, 2,000 is more than a flow’s iteration steps can handle so, if I’ve got a loop at 2,000, I can’t do it. And so, I started figuring out a bunch of really hacky ways to try and work around it and not throw away all my logic structure. And while I was participating, I kept doing the answers.salesforce.com and somebody else posted the same thing and I laid out all of the other headaches and all the ways I’d attacked the problem. My best approach at the time was to make five copies of the flow and then I got a little bit better and I scheduled it to run repeat at the same … Gosh, making seven copies every time you made a change, you had to change it to seven places was not good.
Paul McCollum:
So, I started scheduling it and I figured out a method. So, I’m just going to grab 300 accounts at a time and I’m going to mark a field saying I’ve processed them and then I’m going to have a schedule call it again and run it on the unprocessed flows. And as long as I remember where I was on each run, I could do it 300, 700 records at a time. So, I still give credit to the guy but I haven’t been able to get him to give me a handle to post on it but he replied back on one of the threads where we talking about ways. The only important part of the hack is that events break the transaction logic. So, if you emit an event out of a flow and the event does something else or triggers another flow, it’s not the same transaction. So, you-
Josh Birk:
Oh, got you. Because you’ve started a new thread, basically?
Paul McCollum:
It’s basically started a new thread with its own governor counters on it. So, if you can create a flow that can get through a certain set of records and mark that set of records has already been processed, when you get done, if you hit that number, you emit an event, the same type of event which was the one that started your flow to begin with. So, your trigger becomes, hey, it’s Monday night on the first, create an event that starts a flow that does 300 records. And, at the end of that record, it updates all of your accounts and emits an event that is the same type of event that triggered your flow that goes back and grabs the records. And I’ve seen this get through 1.3 million records.
Josh Birk:
Wow.
Paul McCollum:
Okay, it’ll just sit and spin. And I’ve also seen it slow down an environment because somebody wrote the traits are wrong and I started changing my name. It’s an infinite loop.
Josh Birk:
So, beyond safe harbor, shall we say, just to get this part out loud, use this at your own barrel.
Paul McCollum:
Yeah, use at your own risk. When I did get the presentation, I always put a squid game picture up. It was like, “If this doesn’t work and your org goes down, you do not know me.”
Josh Birk:
That sounds like probably the biggest performance and scale if you do it that wrong and you’re doing 1.3 million. So, it sounds like maybe the biggest risk really is just performance on your org but I, obviously, put the asterisk on that or the 13 things that Paul and Josh didn’t think about during this interview.
Paul McCollum:
So, I feel good. I have indoctrinated about 15 or 16 people that have used this pattern. And as long as you put enough test conditions in to feel safe, put a counter in, it should never go over 3 million, it should never be more than this and this much of a loop. If you ever get to this point, check this label and if this label still says keep going, you can put it in there and stop a thread. So, there’s a bunch of safe things that you can put in to make it work but I’ve had some people that, yeah, forget my name, you don’t know enough about flows to be doing this because I’ve had it spin off on me one time and I knew how to kill it. If you do it wrong and I really think you’re going to do it wrong, I think I need to distance myself from you.
Paul McCollum:
But the other 95% have been smart enough and looking to make flows do more real stuff. Because flows are very hobby if you can only do a couple records at a time but this makes it an enterprise scale solution.
Josh Birk:
Interesting. The analogy I’m coming to in my head, it’s like a nuclear factory. If you know what you’re doing, you’ll be safe but that’s only because you’re wearing the right gear and you’re going to have the right red, yellow, green, what’s the temperature of the room I’m walking into kind of thing. But if it’s done right, then it should just keep humming along.
Paul McCollum:
If you’re a developer, you’re supposed to know how to do recursive programming. This is just recursive flows, I just found a way to do it without it actually being blessed.
Josh Birk:
Nice, nice. Okay, so moving on to another thing that you’re hugely known about, when did you first start getting involved in the Salesforce community itself?
Paul McCollum:
Let’s see. So, Dreamforce, and I still credit Meighan Brodkey as my Ohana mama. So, I did that competition thing for AppVenture and I had run user groups for another stack for about the past eight or nine years before starting in with Salesforce and I had never seen a Salesforce user group. But when I walked into Meighan’s session and she talked about, yeah, reach out to the local Ohana and do such and so. And I wrote that down, I was like, “I don’t know what that means,” for help if you’re wanting to learn and I had not engaged with a community before except for the ones that I was spinning up.
Paul McCollum:
There were yearly conferences that I would go to but there wasn’t the interconnected conference. And so, when she said Ohana, and I researched what that meant, and I found, oh, you guys do user groups too and I went and joined my local user group and started trying to help there. And I fell in love with the feedback that Salesforce actually gives to people trying to learn it so that the community of help that everybody has this, hey, if you’re in Salesforce, you’re helping people. There’s no snobbies, there’s no I know it and you can’t because that makes me special.
Josh Birk:
Right.
Paul McCollum:
That doesn’t go over so well in our community which is amazing. So, I followed Meighan for a long time and finally got to go work for her and it was a neat thing to introduce myself to her in one of our first meetings. You were the one that told me Ohana and now I work for you and someday we’re going to present it to a Dreamforce on this because-
Josh Birk:
Da, da, dan. Oh, my God, that’s awesome. No, you’re spot on and this comes up over and over again. I feel like the community has been around long enough with this vibe to it, which is great, it’s difficult to shake that because we’re a community of people who got successful by helping each other. So, if you’re part of that community, you’re already in that vibe and you know you want to keep that going because, once again, it’s how we all got successful in the first place.
Paul McCollum:
Yup, yeah. And so, yeah, I love doing that. As a senior architect, man, I told you, I think, in a passing conversation that I got stuck on the term account for a couple of days. I need my login account and the word account used in Salesforce. So, now, I post on that everywhere. Anybody who’s starting Salesforce work, let me call you and tell you the 14 things that made me smash my head against the wall. And that may be my only value is to serve as a warning to others but I will do that.
Josh Birk:
And then what’s your current role in the community itself? You’re DT leader in Dallas, am I remembering this correctly?
Paul McCollum:
I run the Dallas Salesforce devs user group which I run as an architect dev user group. Meighan and I run the Road to CTA Salesforce Saturday user group and we meet weekly to either talk CTA exam or CTA level topics which is a lot of fun. I run a multi-cloud podcast with my old Microsoft cronies and then I tried to take over, COVID has shut it down, but I picked up whenever the old leader had decided to do other things, a thing called Salesforce for Youth. We try and spin up meetings at the local university and give freshmen in college and high school seniors an idea of what the world of hands on compute actually means or hands on programming and it’s been fun to turn those lights.
Paul McCollum:
On my best day ever, I’ve got a picture, one of some kids wearing a Salesforce stickers on their head. There were three or four kids that stayed while everybody else was going to lunch and I headed to lunch and they were all gathered around a monitor that looked like a LAN gaming party. I was like, “Okay, these are my people. What are we doing?”
Josh Birk:
This is my tribe, this is my tribe.
Paul McCollum:
Exactly.
Josh Birk:
I love it.
Paul McCollum:
And they’re trying to figure it out. It’s like, “Hey, that Salesforce code that sends email, can you do that more than one time?” “Oh, to spam somebody?” “Yeah.” I was like, “Yeah, let me show you the code. Here’s how you write a loop.” And I showed them a form loop that sent 10 emails to their Gmail account and the light that went on for being able to do illicit things with it was amazing. That was my favorite teaching day.
Josh Birk:
Oh, my God, that’s so cool. When you’ve convinced somebody that something slightly magical is possible, you see that in their eyes and I love it, I love it, yeah. Any projects you have in the works or that are coming up that you want to give a shout out to?
Paul McCollum:
Now, I’m trying to put a book together, I still haven’t gotten a chance to officially label that yet. But no, the Dallas user group and community cloud podcast and Road to CTA Salesforce Saturday are a mouthful but they’re all my favorite passions right now. I may be a little overcommitted at this point, I’m trying to make sure all my partners know that I have probably overcommitted myself and to put me on a performance plan if needed.
Josh Birk:
Well, and speaking of partners, you have a new project coming up with a former podcast guest himself Adam Olshansky, I believe.
Paul McCollum:
Yeah, Adam is a great guy. One of the first people that I was listening to in the Ohana space and he’s agreed with me when I talked about all of the first thing I tried to blog and write down is the stuff that I tripped over. He and I are putting together a series called Dev Up and we may change the name and rebrand it. You don’t need to have a formal background in programming to learn how to program in Salesforce. You can cherry pick some of the skills in Apex and LWC and JavaScript and Stockwell without having to have gone through pointers in C and learned logo.
Paul McCollum:
So, we’re trying to put together a series of video conversations where we talk through the lists of computing concepts that you need to know before you get into Salesforce. So, it’s like go learn if then else. Learn the difference between the different usage of the word account and go learn what a data structure is but you don’t need to know what a double and float is necessarily, they’re varying. So, that is a fun from the heart project and he and I are constantly struggling to find a time to keep that going. We wanted to get this done, I think, by June and I think we’ve only got three sessions out.
Josh Birk:
And that’s our show. Now, before we go, I did ask after, Paul’s favorite non-technical hobby and it turns out that it’s a sport that I’m pretty mediocre at and apparently he’s really good at.
Paul McCollum:
I still play and coach a lot of volleyball.
Josh Birk:
Oh, nice.
Paul McCollum:
That was a lot of my passion growing up. I get chided by somebody who said, “You need to lead with that. People will” … Okay, in 1991, I have won a gold medal from the Junior Olympic National Championship in volleyball. So, half of my team was on the men’s Olympic team so that’s my non-technical, weird hobby but, otherwise, I have all the other hobbies.
Josh Birk:
I want to thank Paul 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 hear old episodes, see the show notes and the links to your favorite podcast service. Thanks again, everybody. I’ll talk to you next week.