Peter Chittum is Senior Director, Developer Evangelist at Salesforce.
Peter grows from Theater Arts and French education to Developer Evangelist and Manager at Salesforce. He also shared how the Salesforce front-end evolved, how to learn functional programming, imposter syndrome challenges, etc.
Sponsors
This episode is sponsored by FormAssembly.
22 Ways to Use FormAssembly for Remote Work Success – Learn how to streamline remote work processes with FormAssembly’s all-in-one form builder and data collection platform
Links
Video Teaser
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] I'd like to welcome our sponsor Form Assembly. You can find out how Form Assembly helps streamline remote work processes in the free ebook that we've linked in today's show notes. Form Assembly's all-in-one web form platform lets you create forms for just about any use case. From contact forms to donation forms, all while take advantage of useful features such as notifications, e-signatures, and more. Not only that, but you can also connect data to systems you already use. Forma simply integrates with Salesforce, Podio, PayPal, and many other common solutions. Whatever your data collection needs are, you can be sure that Form Assembly keeps your data secure with encryption at rest and in transit on all plans. Plus compliance with GDPR, CCPA, and more regulations. At the end of the day, Form Assembly helps you save time, money, and effort while getting the maximum benefit out of the data you collect. And I remind you, when you support our sponsors, you support the show.
[01:24] Hey everybody! This is Xi Xiao. This is yet a new episode of Salesforce Way podcast. Today I got a wonderful guest with me from Salesforce. His name's Peter Chittum. Hello, hello, Peter. Hey, Xi. How are you doing? I'm doing great. How about you? Pretty good. Pretty good. So, Peter, why wouldn't you introduce yourself? Sure thing. So, I am Peter Chittum. I lead the developer evangelist team for North America and EMIA for Salesforce. I am also a developer evangelist, so the role is a player coach kind of role. I am still a developer. I still write code. Still share that with people. I just also have a team to run. So, your team is across North America and EMIA. Yeah, that's right. So, okay, there is. Five developer evangelists who are on the team. Two in also in Amia and three in the U.S. Is Philippe Otzi part of your team? Yeah, Philippe is. He was on your podcast a few months ago, right? Yes, yes, yes. Talk about the Lightning Web Component. Yeah, yeah. It was a good. It was a good show. Oh, thanks. So we have you to hear your story around your career path. It was really interesting when you shared a bit your story with me, and I think it would be a wonderful topic for us to just talk and then share with all the listeners as well. I understand you at the early stage, you programming language was like Java. Am I right? Like Object Oriented. Or how did it all start? Yeah, actually, backing up
[02:54] even before that is probably helpful in understanding my background because I didn't study computer science. You could say that I I happened into the career. I had worked with computers for a long time, and around the time of the sort of early internet era, I was looking around for work and. All of the sudden, there were loads of jobs working with computers. So I managed to find my way in, and my first programming language that I actually used properly was Visual Basic. In fact, specifically VBA for apps. So, as part of actually a tech support job, I was doing, I would write VBA macros to help analyze data that would help troubleshoot what was going wrong with certain clients' problems and that sort of thing, and eventually. I started working for a CRM company. Initially, they were using Microsoft Stack, the really early MSMQ, your two thousand nineteen ninety nine era MSMQ, and then they ported their entire CRM. Functionality into J2EE around 2002, 2003, early J2EE stuff, and that's really where I would say. I kind of went from dabbling, maybe in in programming, to actually really feeling like I was a developer for the first time. Ah, yeah, I had because
[04:25] in my early career time, in the first five years, I wasn't a programmer at all. My task was really just to tweak around the code, adding some if else here and there, fixing some minor bugs. So I couldn't consider myself as a programmer either, till I joined the Salesforce ecosystem. Okay. So for you, what was your background in the college? So I took a degree in theater, and. French, so nothing to do with anything technical at all. And sometimes I even joke about how I took one maths class my entire time at university. So I often feel like I'm playing catch up when it comes to like really thinking out a like a mathematically complex programming problem. But you know, I make do. Do you still get the chance to use those skills? Well, since since since my job is developer evangelist, and I share a lot in front of people. I would say that you know I use those presentation skills frequently and often. I think I share a lot with people. I've I've helped other people prepare their talks, and so being able to share with people how to have a stage presence. And how to get beyond the technical content, but to really communicate and connect with people, I think is a big obstacle for technical people who are going into presentation.
[05:55] And so. I definitely feel like I bring I bring stuff to the table there, and the the French part has helped as well because well actually until I hired Philippe, I was the French speaker on the developer evangelist team, so I've I've spoken a lot in French. In fact, the first time I. Delivered a keynote for one of our community conferences was at North Africa Dreaming. That was in French, and tonight I'm actually sharing for the Morocco, the Casablanca Developer Group, and I will probably deliver most of that in French as well. That's so good. You know your skill. It's come in handy. So you mentioned at the early stages you J two E E, so that's the the time you start to use Java, am I right? And then you kind of shift to Apex, I would assume, since you joined Salesforce. Yeah, exactly. So I actually worked with that CRM software for six years. I then worked for a company that built a JVM application performance management tool called Introscope. And that was really interesting, getting to understand the JVM from the inside out, and not just understanding how the code worked, but how well the code worked. That's interesting. That's really like a lower layer things how the JVM works. Yeah, for sure. So
[07:26] that was that was really. Helpful. I went back to that same company when I moved here to the UK, or that same software, I should say. They had been acquired at that time, but yeah, when I joined Salesforce in twenty ten. I kind of shifted all of my development into Apex and Visualforce at the time, of course, and that's really where I I would say it like that. It was a transformational time in my career as well, moving from something that really had a big sort of open source ecosystem about it. Into something that you know, I like to think about about Apex as a as a domain specific language, and to see the difference that that made in developer productivity and being able to make certain things happen. That when I was dealing in the J two E application, there was a lot more blocking and tackling that had to take place to to make that work. Is there a separation between like front end evangelist and the back end evangelist in Salesforce? No, we're too small of a team to really be able to be afforded that. I would say. Okay, so you need to have both skills. Yeah, we really need to have folks who can stand up and be competent and share all up and down the Salesforce stack. I watched some of your recent presentations in YouTube. It's about the Lightning Web
[08:56] Components. So, what's the kind of shifting? I don't know. Do you have the mindset shifting from the O O to the JavaScript? Because to me, it's hard. JavaScript is hard. Definitely, if yeah, in going from an imperative object-oriented programming language, moving also from the kind of heavy. UI framework that is the server-side compiled UI framework of the early 2000s. I found those those frameworks to be really like positive to work with on the one hand. From the standpoint of, you know, from what it would take to actually stand up an enterprise application, without that, it would just be mind-boggling. And then, you know, with Visual Force, it was so tightly coupled with Apex. The amount of thinking that had to be done about what the browser was going to do when you did something was so minimal, it kind of abstracted away the browser in a way that I think really, really worked well at the time. And you know, when I first joined Salesforce, I spent a lot of energy kind of really getting to understand the the nature of the Apex object oriented model. And the ways that that differed a little bit from other object-oriented models, or you know, also the ways
[10:26] that it was similar. But most of the effort was really around Apex, and then you know, Visual Force was just kind of this layer that you put on top of it. And if you understood how to properly structure an Apex controller. Getting your Visualforce page to work wasn't that hard. There were certainly plenty of things that were exposed through that. I think the most important thing about that was understanding that at that time, what you were writing down as a tag, what was going to be out in the browser. Of course, there was this whole process that went place that took place to. To parse that, render it, and turn it into something that the browser actually would understand. But that was incredibly powerful because you could produce some fairly complex user interfaces, really highly customized, without really spending a lot of time on the the nitty gritty of. All the little details that that the browser had to understand to make that happen. It was in my kind of word. It's like it's wrapped in those components. You can even create your own custom component. And in the early days of JavaScript, it was also kind of messy and chaotic since the browser standard that defined. But nowadays, I think it's getting so much better for all the frameworks, not just the Lightning Web Components, and also the browser standards. It's getting so much better. Yeah, I totally agree. The I think the browser wars were a huge factor in. I don't know. It's hard to say. Were
[11:56] the frameworks a response to the browser wars themselves, or were the browser wars like? Did they? Trigger the you know, I don't know. It's which came first is probably really hard, and it's something that's now in the annals of history. But certainly, a lot of those frameworks were dependent on certain browsers more often than not, Internet Explorer, just because of how Microsoft had dominated the business-based IT space. So yeah, like that the you know that CRM company I worked for before that their UI framework was like a hundred percent dependent on the customer had to have IE six and if they weren't using IE six then they didn't get to play. And customers were okay with that. Like that was just that was those were the rules of the game then. And I think there were a lot of things that happened over the course of that time. Certainly, the evolution of. Frameworks that were trying to abstract away the differences between browsers, like when jQuery came about, when Node.js was born, and actually, as I understand it, I think a big thing that really matured JavaScript and made people think start to to think they should take it seriously was Google creating Google Maps, and for the first time, there was this super. I mean, I remember how magical Google Maps felt when I first opened it up. And and looked at it. I didn't have that experience. Mine was like a Gmail. That was wow. Yeah.
[13:26] But that—that's what I understood. I forgot which podcast I heard this on, but there was for the first time people were like, "Oh, that JavaScript thing can actually do something pretty amazing." So then jQuery, no JS, kind of brings it into into the world of the server, you know. And then here we are today, where it's hard to imagine just how hard it was to get a consistent JavaScript API between two browser manufacturers. Back in two thousand one, two thousand two, two thousand three, how did you start to touch JavaScript? Was it because you need to learn Lightning Web Components? No, actually. So my first exposure to JavaScript was weirdly enough a. Server-side JavaScript engine. This was a little inbound marketing engine that essentially used JavaScript as the way for a developer to customize the tools that would be used for a marketing department. I mean, think about all the advertisements that we see on the web. You know, those were a brand new thing in the early two thousand s and. People wanted an engine to be able to not just serve up an advertisement, but to do it in a way that was dynamic and responded to the user. And you know, these were things that were kind of new at that time. So it was before Node.js. This was pre-Node.js, and I've always meant to go back and I'm sure I could find out what engine it was. But it was JavaScript on the server side, and so you know, I'd already
[14:57] started to learn Java. And at the time, it just didn't really dawn on me how different they really were. So I worked with that tool, and then I walked away from JavaScript for a long, long time. When I first started to pick up JavaScript, the second time was right after I joined the Developer Evangelist team here at Salesforce. And at that time, Visualforce had started to make available much more granular and fine-grained control of. What parts of the Visual Force page the rendering engine would decide to touch or not? So when I first joined Salesforce Visual Force. Owned kind of the the whole DOM, and if you wanted to, if you wanted a custom head section, you sort of had to make do with whatever Visual Force was going to put in there, and whatever else you wanted. If you didn't want the Salesforce style sheets, too bad. I mean, there were like all of these things that you know the at its inception, Visual Force made an assumption, which was. Of course, our developers in the ecosystem want to reproduce a user interface that looks just like Salesforce, and so the framework made that assumption. It built that assumption into how pages would be would be made. So, a couple years later, the with the rise of jQuery, the rise of things like Ember and Backbone, and you know, more and more. Customization,
[16:27] you know, nicer feeling user interfaces. The evolution of JavaScript. People wanted their own JavaScript skin, their own rendering engine, really, on top of what Salesforce was serving them, which was at the time Visualforce, of course. So Visualforce started to add controls where you could exclude the. The Salesforce stylesheets—you could control the entire rendering of the page or the head and the body yourself. And so that was right at the time I joined the developer evangelist team, and we built this whole project around. We called them mobile templates. And so there were there were projects on. Essentially, it was a way to show how you could take something like Angular or Backbone or jQuery. You could use that as the engine for presenting the user interface, and then use a mobile CSS library on top of that, so that you could have a mobile user interface served directly from Salesforce via Visualforce, or you could even potentially have something like Node.js server that had the same. Skin on top of it that was then integrated with Salesforce, for instance, and that was really when I started to get back into JavaScript. And Peter, I understand you also touched some functional programming language as well in the back. Yeah, what was that experience? How you know it's like a different
[17:57] paradigm. It's always interesting to hear. What are the people's experience and thoughts? Yeah, at this time, my initial exposure this was like a month or two into being on the developer evangelist team. My initial experience was. Like I chose to do something with Angular at the time, so that you know I built a little, like a sort of a handheld mobile device type of application where you could be standing at a booth and like going through kind of a decision. Tree and then you know give somebody an offer kind of thing. So I built that. It was basically Visual Force with Angular, and I just about eked it out and got it posted into this mobile apps gallery that that we were building as a bunch of reference apps for you know how do you build mobile user interfaces using Visual Force. And I realized how painful it was because I didn't really understand what I was doing. I mean Angular was great from the standpoint of. You could pretty much understand how to build your Angular user interface with the you know how the router would work, you know where your views would go, and if you just. Did the you know if you sort of change the right things in a template, you could kind of have an Angular user interface, but that wasn't really satisfying from understanding what I was doing. So I started to spend more time just trying to understand JavaScript, the language, and JavaScript, the platform. I one book that I read that I think you know is really widely recognized as a
[19:27] kind of a a game changing. Work in for JavaScript was JavaScript the good parts, and that was really useful to understand like you know why I should be doing certain things and why I shouldn't be doing certain things. I read a book on functional JavaScript was which was essentially a functional library on top of JavaScript, and I was also starting to attend more developer conferences outside of just the Salesforce ecosystem. And at one of these conferences, I just I happened to have a conversation with somebody who introduced me to Erlang. And at the same time, you know, in one sentence, completely intrigued me with it, but also really put me off. Wanting to ever write Erlang myself, you know, by describing it as a very syntactically complex language, and so you know, at the same time, I was really fascinated because here is a language and a platform that is designed for a distributed architecture, which is more and more what the internet was becoming at the time. And then, really soon after that, I was introduced to Elixir, which is A second language that sits on top of the Beam virtual machine that came with Erlang, and this idea of a something that's more syntactically sugary really attracted me. So I spent some time getting to know Erlang at that point. Sorry, Elixir at that point. For the listeners who don't know much about Erlang,
[20:58] it's a functional programming language, and it has its own virtual machine as well. If I understand, it's similar to. To Java or to yeah, so the Erlang virtual machine is called the Beam virtual machine, and then built into Beam is a completely different method of concurrency and a a set of primitives in the language that make distributed architecture. Almost invisible to the developer. So, if I'm going to make a distributed, make an API call, for instance, to some other machine somewhere on the internet or somewhere on my network, I need to know everything about where that thing is and its address. I need to, you know, know the right protocol to reach that thing, and then I need to know the right way to call it. And the way that that beam works is that there's something that's called a process, which actually lives differently from an operating system process. And when that process starts up, where it starts up. Doesn't really matter if you just tell it to join another process. They become a little process cluster, and they can send each other messages, whether they are on the same machine, on two different virtual machines, or two different physical machines on different parts of the planet. So it makes Having
[22:28] a distributed architecture much more transparent. So that was what intrigued me technically about it, but that wasn't actually what I would say I took most from learning Elixir. What I probably took most from that is a better understanding of functional programming. Paradigms, and then how to take some of those things that I learned into JavaScript. Exactly, the big hurdle for people like me is that we're writing too much object-oriented. Now shifting into JavaScript, everything we're using for loop, we're using a class to you know wrap stuff. So it doesn't feel functional at all, even though it works. But that's kind of like a mindset shift we need to do somehow. I think so, and I think where I see getting to know you know any functional language, I happen to pick Elixir, but. You know there are a dozen other ones that are popular and easy to access. That I would you know if if somebody's struggling to get their minds around what they're doing with JavaScript, go spend a while swimming in a purely functional pool swimming pool, and you'll start to you know I think understand things a little bit better. Especially you know just getting my head around first order functions. Particularly, the first time I saw a function passed by another function in JavaScript, it completely blew my mind.
[23:58] I didn't know what I was doing, but I just sort of was like following the recipe, and so I like, okay, I'll do that, but I don't really get what's going on. You know, eventually learning that what you're doing when you're doing that is you're you know you're passing this off to some other process to do something with that you can now forget about that, and then understanding underneath that the structure of the JavaScript runtime and how. You know, if if that thing is executed asynchronously, it just gets put, you know, in a queue to wait for the next cycle that is available, and then it will execute eventually as well. And I think that those are all things that really, you know, that very much fit in with how a functional programming model works, where You know, I'm going to execute this function, or I'm going to pass this function that you know something inside that other function will execute for me. Like those are all things that come right out of functional programming. In the past, I had a conversation with people outside of Salesforce. In this podcast, we talk about the Haskell. We talk about the closure, so those are like the pure function languages, and really popular and really engaging people from the community point of view. So, if our listeners are interested, they definitely go back to listen to those episodes as well. Interested in asking? I don't know if it's a confidential or not. Is Salesforce happen to in the
[25:28] roadmap to support some functional programming languages? Well, I I don't know of of any beyond you know beyond what we're supporting with JavaScript right now you know which. Can be functional. No, I don't. There's nothing that I know of that is heading in that direction, and that's part of the reason why you know Elixir ended up being sort of a a an experiment and a learning experience for me. But it's not something that I use today as much as I enjoyed learning what I did. The interesting thing that I noticed that when I talk with the younger generation programmer who started to programming maybe after 2010. That their university education about programming are really pure functions, so they are using Haskell instead of back in my days it was Java, C, C plus plus. They don't learn those object oriented anymore. They Right away, jump into the functional pool, which is really, really interesting to me. I think that's probably a healthy thing. You know, certainly when I was learning to program. In kind of the late nineteen nineties, early two thousands, when you would pick up an object oriented programming book or read something about it, being somebody who didn't have the educational experience or you know what I would have hoped would have been a more broadly rounded. Exposure to different programming
[26:58] models. The way that those books talked about object-oriented programming was sort of like there is no future beyond object-oriented programming. Yeah, like we have figured out the right way to program computers forever. Yeah, this is how you do it. Yes, this is the world. This is the end. And so I I think it's a really healthy thing that kind of JavaScript came along and exploded that for real in in real practical terms. I don't think you can be working as a developer and not learn some you know not be. Not use JavaScript. Let me say. Let me say that a little bit differently. A minority of developers who can go about their work these days and not learn JavaScript, but so much depends on it. Apart from Lightning Web Components, the the main way that I use JavaScript today is actually just writing tooling. So it's a really great portable language now that runs everywhere. So why wouldn't you, right? So, Peter, I understand you have like fifty percent of time used for manage the team nowadays. Am I right? Yeah, that's probably about right. Okay, and the rest of time still do the doing the evangelist tasks. Yeah, exactly. Yeah, so. Which means that my actual programming time is probably a lot less than that. You know, as as a role, your developer evangelist. You know, as a developer evangelist, your job is to write code, but that's only the beginning. You know, so once you've written that,
[28:28] whatever that class, that user interface, uh, you know, that Lightning Web component, your job is only part done because something somewhere in there you've learned something. And your job is to then go and share what you've learned. So if if you haven't, yeah, if you haven't done that last part, then you've really only partly done your job. That's why evangelists do a lot of presentations, catch the conference, write the Trailhead modules to help people to. To get the hands-on more experiences. Yeah, exactly. Do you now have a imposter syndrome since you didn't write that much code anymore?
[29:11] So, between so when I first when I took up the management position that was about twenty sixteen and. 2016, 2017 in particular, I wasn't writing a lot of code. I was, I was kind of just doing like barely enough to keep up. I would say I was also probably spending more time and energy on what I would say is sort of like coding for you know as experimentation as opposed to coding that. Somebody could then turn around and use. So, like twenty sixteen, twenty seventeen, were a bit lean, and from that standpoint, from. About midway through 2019 onward, there have been more and more opportunities to actually write code that gets shipped out that people use. I mean, most of what we write in developer evangelism, it's not code that's meant to be run in production for our customers. It's code that is. Written so that other developers can see what we've done, and then go and take and learn from that. But if we're doing that right. You know, hopefully that code is as as real to life as possible, and that does give us a a lot of um a lot of experience to go in and share. Especially, part of our position is getting access to features and functionality earlier, so that we can kind of prime the pipeline and make sure that there is good content in place when a feature launches, as opposed to like
[30:41] the feature launching and then playing catch up. So Peter, before let you go, do you still have something else to add? Boy, I don't know. Like we're probably talking about the twenty years or thirty years of your career journey. Yeah, no, I think I think it's really. It's interesting that you bring up imposter syndrome in the context of having less time to write code. When I saw that in in your notes. That you shared with me, I sort of expected that to come up more in the context of my background. You know, not being in computer science. I don't know. I just randomly brought it up. Yeah, yeah, yeah. Show notes are meant to be just there. Yeah, yeah, yeah. So you know, I I think despite my answer, impostor syndrome is definitely something that I have struggled with, and even to this day struggle with from time to time. And a lot of it does have to do with how much I'm able to spend my time really investing in getting to know the tools that I'm sharing with people. So I do think that's that's something that many many people struggle with imposter syndrome, especially if you're going to be standing up and presenting yourself as an expert in something. So the more opportunities you get to be working with that thing, but then also to share in and of itself, you come to realize that. That's not the most important voice that's going on in your head, and you know inevitably somebody has something to learn from what you're going to share. So I think that's probably the most important thing that I take away from imposter syndrome. You know that's one of the reasons that I so much more
[32:11] enjoy the host role in the podcast instead of the guest because I'm also a bit afraid that what I'm gonna share, you know, I'm not expert of anything. So yeah, cool. Well, well, I don't know. I mean, maybe we should have you come and share on the Salesforce podcast. Maybe five years later, let's see. Turn the tables a bit. I'll, I'll, I'll be sure to mention your name to Josh. Okay, okay. That's that's okay. We can talk about that later. All right. Thanks, Peter. It was great chatting with you. Yeah, she. So it's been a lot of fun, and I've really enjoyed it.
[32:49] Hi, I'm constantly looking for good guests. If you have any guest recommendation, please reach me out. I'll make sure they are joining to the show to share their knowledge. Otherwise, thanks for listening to the show. I'll see you next Thursday.
