Join us as we welcome Rob Cowell, a renowned DevOps advocate, on a journey through his personal and professional life in the world of programming and Salesforce. Starting with his early experiences tinkering with a Sord M5 computer, Rob shares how he transformed his passion for programming into a fulfilling career. We trace his evolution from working with Microsoft Access to .NET, C Sharp, and ultimately Salesforce and Apex, highlighting the importance of continuous learning and adaptation in the fast-paced tech industry.

Transitioning into his current role, Rob pulls back the curtain on what it truly means to be a DevOps advocate. Emphasizing the significance of communication, collaboration, small incremental changes, and automation, he discusses how a commitment to quality is integral to delivering excellent results. The episode also explores the role of a Salesforce DevOps engineer and how to adopt the required skill set.

Tune in to glean invaluable insights from Rob’s vast experience and deep knowledge of the Salesforce ecosystem.

Show Highlights:

  • The role and importance of Salesforce DevOps in delivering quality results efficiently.
  • The key components of Salesforce DevOps include communication, collaboration, small incremental changes, and automation.
  • The transition from traditional development stacks into Salesforce and the unique elements of the platform.
  • The role of a Salesforce DevOps engineer and how to adopt the necessary skill set.
  • The introduction of Rob Cowell’s project, ‘Shirt Force,’ which combines humor and philanthropy by creating Salesforce-themed t-shirts and donating the profits to charity.
  • Insights into continuous improvement and the importance of adapting DevOps to your way of working.

Links:

Other resources:

Episode Transcript

Rob Cowell:
One of the things that I want to make… Of course, at nine years old I played a lot of computer games, but I was very much hooked on the, if I tell it to do this, it will do it, and then, if I change this, it’ll do it slightly differently. Many hours designing little characters and moving them around the screen with a joystick.

Julian Duque:
And that’s Rob Cowell, DevOps advocate at Gearset. I’m Julian Duque, your host for the Salesforce Developer Podcast. And here in the podcast, we share stories and insights from developers for developers.
Today, we are going to talk with Rob about DevOps in the Salesforce ecosystem. But before we will start, just as we left off, as we often do, with his early years.

Rob Cowell:
So, way back in 1982, the dawn of 8-bit home micros and them becoming affordable for general usage, so it was Christmas of 1982, I was nine years old, and folks can do the math, I received my first computer for Christmas. It was a Czech rebrand of a Japanese import machine called a Sord M5. It had 16 kilobytes of memory. It had a Zed 80 processor. And yeah, it was my first entry, and I’ve been hooked ever since.

Julian Duque:
Wow. What do you do with that type of computers? This is maybe two years before I’m born, so I don’t have an idea about what you’re talking about.

Rob Cowell:
Yeah. No problem. Yeah. These machines were interesting, and from a development perspective, actually, some of the best ways to get started with that world. Because a lot of these machines either had BASIC, the programming language built into them on ROM, or they had… In the case of this machine, they had a basic cartridge. And in fact, there were actually a few different BASIC cartridges for that machine.
There was BASIC I, which supported in integer math. There was BASIC G, which had built in graphics functions, and so, you had to be quite creative and think about, “What are the things that I want to make here?” Of course, at nine years old, I played a lot of computer games, but I was very much hooked on the, “If I tell it to do this, it will do it. And then, if I change this, it’ll do it slightly differently.” Many hours designing little characters and moving them around the screen with a joystick.
And yeah, that’s what really kind of spawned my interest in computers, technology, programming, and many, many, many years later, here we are.

Julian Duque:
Nice. Back in the day, how you learned that BASIC? It came like with a big book, because there’s this pre-internet, so you didn’t have that opportunity to learn that.

Rob Cowell:
No, absolutely. And, yeah, I mean, it came with a manual and a few examples of programs that you could type. And then, much like we learn programming even to this day, you start with an example and you start changing things and tweaking things.
But in those days, the BASICs on different brands of machine were slightly different. So, Microsoft had a BASIC, and they licensed it to a lot of companies. But then, other companies would do their own implementation with a slightly different syntax. But it was always possible… As you say, there were books available and you could pick up a book for one brand of computer and you could kind of figure out, oh, okay, I see what that’s doing here. I just need to do it slightly differently for my machine.
And yeah, you just tinker. That’s the thing that I miss a little bit about programming for a living versus doing it for a hobby, is that freedom to tinker and experiment and try things. We talk about sort of fail fast, there was a lot of that going on back in those days before it became fashionable.

Julian Duque:
Yeah. That happens to be, like today, that pretty much the job that I have, was my hobby.

Rob Cowell:
Yes.

Julian Duque:
So, you have that change, it makes things a little bit different.
So you started when you were nine, what happened next? You continue with other different computers, or you started going to different hobbies. How was that evolution?

Rob Cowell:
So, as the machines became more advanced, I moved with the machines. I went from 8-bit machines to 16-bit machines. I got involved with a very sort of digital arts subculture called the demo scene, where people are doing programming and artwork and music for the sheer joy of it. And then, it becomes a little competitive, and we have parties when people vote on the productions that people make. I still do that to this day, although not as much, because I have children and wives and jobs and all the boring adult stuff.
But, yeah, I continued doing that as a hobby. One of my favorite stories around that, actually, was when I was still young, my mother… Because this is in the early days of computing, right? And so my mother said to me, “You want to go outside and play football with the other kids? You never make a living messing about with computers”.
And every so often, I do remind her of this, because I make a quite good living messing about with computers now. But yeah, I didn’t actually do programming as a career, as a paid job until I was about 22, 23. So, it was a long time coming in terms of turning that hobby and that interest into a career.

Julian Duque:
And when you started seeing it as a career, what was that first professional interaction? So, you were building software, or what type of software?

Rob Cowell:
Yeah. Some of the folks listening will be able to remember, way back in the midst of time, I was a Microsoft Access developer, specifically Access 2.0. So, we’re talking, I think probably somewhere around 1996, I think that would’ve been. And yeah, and I went through a few iterations of Access 2, Access 95, Access 98. And then, I kind of made that leap over to Visual Basic. And then, from there, to .NET and C#. So there’s definitely an evolution there.
And I think it was when I got onto the .NET platform using C#, that was my first entry into proper object-orientated programming. And the interesting thing is, is that… We’ll talk about the evolution of that into the Salesforce world, I’m sure, but having got those fundamental concepts of object-orientated program and the syntax of C#, when I did eventually land on the Salesforce platform and saw Apex, it didn’t feel alien to me at all.
There was definitely a feeling of comfort, this isn’t dissimilar to what I’ve seen before.

Julian Duque:
Yeah, it’s like when you know one specific language and you are learning another one, there is a familiarity.

Rob Cowell:
Absolutely.

Julian Duque:
You’re not going to have like that, this is super strange, I’m just jumping from one thing. It’s the same logical programming behind, the language is just syntax.

Rob Cowell:
And I think one of the interesting things about transitioning from those kind of traditional development stacks into something like the Salesforce platform is, as a developer, I didn’t need to learn Apex quite as much. I needed to learn the unique elements of the platform in general, things like governor limits, things like the object model, things like the multi-tenant aspects and how you interact with the config side of the platform.
And so, the Apex thing came naturally, but how to use it wisely within the context of Salesforce overall, I think that was the greater learning curve when I came to that platform.

Julian Duque:
Nice. And this was how long ago?

Rob Cowell:
So, I can give an exact date on that one.

Julian Duque:
Exact date.

Rob Cowell:
Yeah.

Julian Duque:
Okay.

Rob Cowell:
The day I discovered Salesforce was March the 26th, 2010. I remember it, because it’s my mother’s birthday.

Julian Duque:
Okay. Makes sense.

Rob Cowell:
But that, again, is an interesting story. So I was like a freelance consultant, and I was brought in by a company to be an application support developer. So, one of those sort of traditional hybrid roles that used to abound in companies.
And on my very first day, the hiring manager said, “Okay, so if anybody asks you’re a Salesforce expert, because the only way that HR would sign off budget on a new headcount is if we told them we were getting a Salesforce expert”. And I said, “Yeah. Okay. No, that’s fine. What is Salesforce?” And… Yeah, they’re in, right… the last 13 years of history.

Julian Duque:
Fake it until you make it.

Rob Cowell:
Exactly right, yeah.

Julian Duque:
And there you are. I mean, when I met you pretty much online… I joined the Salesforce ecosystem four years ago, exactly joined the Heroku team, and you were one of the first persons that I started to interact with. You were very interested in Heroku, but you were also recognized within the Salesforce community already. So it is good to have you. And we are long over due to have you here at the podcast.
So, how was that transition from being just like a Salesforce developer consultant now to what are you doing today, which is the DevOps side of things?

Rob Cowell:
Yeah. No, absolutely. And I think DevOps is and always has been a strong part of what it means to be a developer. Nobody codes in isolation and does nothing with it, right? You have to deliver that change to the hands of end users or customers. And that kind of way of thinking and that sort of delivery focus, ideally, is DevOps-driven. There are other ways of delivery, but hopefully, folks realize that that’s not the optimal way to deliver things.
And I think DevOps can be small, incremental changes or it can be a full end-to-end process. And I think the transition from that was that, I work for a vendor in the Salesforce DevOps space, and I was using the product and it saved me so much time. I’m not certainly here to pitch a product, I’m here to pitch a mentality. But, yeah, saving developer productivity time is a passion of mine.
We had a discussion earlier today, and we were talking about how developers are, or good developers are inherently-lazy, right? And the thinking behind that, is that you want to drive efficiencies. You don’t want to be doing dull, repetitive tasks. You want to optimize and you want to leave plenty of time for the fun stuff that you really enjoy. And so, the DevOps mentality is kind of eliminating that repetitive task that can be easily automated, much like many development tasks.
And so, I kind of grew my interest in that, but equally, many years ago when I started my Salesforce career, I met one of your counterparts, actually. It was a developer evangelist at Salesforce. And I said, “Evangelist? What’s that all about?” And he explained the role, and “I’d like to do that someday”. It took me 10 years to get there. But the nice thing is, it allows me to kind of bridge those two disciplines.
So, as a developer, and I’ve only been in this role for a little over a year now, but as a developer and certainly as a consultant, there were times where I’d be up late delivering a client project, getting a deployment, particularly, thorny, tricky thing delivered. And now, I’m in a position where, not only do I not have to do that, but my role is geared around helping other developers not have to do that. Right?
It’s the educational element of that that I think I really enjoy, taking all those many years of programming, whether it’s for hobbies or whether it’s for working and everything that I’ve kind of experienced, and then, using that as a means to help others reach that kind of stage in their development journey a lot quicker than I ever did.

Julian Duque:
And this is what I love about this role, being myself also an advocate, but just for developers. For me, it’s, first, the constant joy of helping folks to be better, learning best practices, how can they succeed about what they’re doing, and also, it’s a constant learning exercise for me. I’m always learning from the people that it’s asking me questions. They are coming to me with certain specific challenges, that it makes me go further to be able to learn and understand how to give them the answers. So, it’s a very interesting job.
How is this DevOps advocate role… I have known about the developer advocate role, but I think this is the first time I hear about the DevOps advocate. So, tell me a little bit more about it.

Rob Cowell:
Yeah. I mean, I, sometimes, jokingly say to people, my job is to stop you using changesets. And I’ve had some interesting conversations with Karen Fidelak from your Salesforce world, who is the product manager for DevOps center.

Julian Duque:
Yep.

Rob Cowell:
And largely, she has the same goal, to stop people using changesets. But in a more sort serious and broader sense, I think we just want to educate folks about what DevOps actually is, the benefits that it can deliver, and how actually, as part of that overall development piece, again, it comes back to removing the tasks that you have to do, so that you can have more time to do the tasks that you want to do. But also, it’s about the changes that you make, getting them to where they’re actually valuable the most.
A lot of DevOps conversations are, oh, is the org the source of truth, or is source control the source of truth? But when you think of it from your customer’s perspective, the source of truth is production. As an end user, if you can’t use that today because it’s still in a test environment or a development environment, it doesn’t exist for you.
And so, we try and encourage this mentality of delivering value as efficiently as possible, so that people can get the most out of the changes and the enhancements that you are making to your organizations.

Julian Duque:
Nice. So, normally, folks associate the term or concept DevOps with operating infrastructure, like maybe taking care of instances, virtual machines, all the process behind, but Salesforce is different. Salesforce, itself is, a platform, and you are not taking care of those aspects. So, what are those key components of Salesforce DevOps?

Rob Cowell:
Okay. So, we always like to say that there’s two core elements of DevOps. So, forget the dev and the ops split. I think that’s certainly for the Salesforce platform, is a bit of a red herring, because not all dev is code. And most of the time, the Salesforce teams, we don’t have a separate operations team that’s managing things. It tends to be the same.
But the split that we like to talk about is like the 80-20 split of culture and mindset versus the technology and the tooling. So, a lot of DevOps is about communication, collaboration, making cross-functional teams. I like to think of DevOps as starting with folks like the business analysts, right? One of the interesting principles of DevOps is, it’s small incremental changes, release early, release often and don’t try and do a big bang approach. And in my mind, that starts with the business analyst in terms of how they get the requirements, how they analyze the requirements and break them up into small and manageable chunks.
So, you, for example, could have a hypothetical example that you could have a task to create the new fields and add them to a layout. That’s one release. Then, another thing that actually does some calculations or intensive processing on those fields, that’s the next release. So, you’re incrementally getting that. And so, from that end-to-end life cycle, you’re getting people invested in it from the, okay, how do we break this up into small chunks? How do we develop it into small chunks? How do we test it in small chunks? How do we deploy it?
And so, you’re kind of getting everybody invested in that process, and the only way you can do that is through communication, collaboration, and into working between different teams. So, it breaks down a lot of the silos there.
That’s one of the viewpoints of the components of off platform, off technology. Then, on technology, there are… We strongly encourage people to use version control, the de facto choices usually get. And there’s plenty of material and tutorials on that, both in the wider sense, and also, from Salesforce’s own great materials and trailhead and whatnot. But also, it’s things like, well, how do we automate the testing? How do we actually have a commitment to quality to what we deliver?
So, it’s not just about how fast can we can deliver, but how fast can we deliver something that’s good. Do you want to deliver bad changes quickly, or do you want to deliver great changes slightly slower, but with that due diligence around making sure that we’re getting quality deliverables. And actually, if you think about how the traditional model of delivering code, something’s not right, you take it back, you rework it, you have to redeploy it in that, if you can eliminate that rework, then, actually, the commitment to quality becomes a faster path to success anyway.

Julian Duque:
And also, it entails the automation side of things.

Rob Cowell:
Absolutely.

Julian Duque:
Because like the whole process of fixing, deploying, testing manually will take a lot of time, and depending on the size of the team you have, if you don’t automate, things are getting more complex.
How do you know that you need DevOps in your org? Do all orgs need to have a proper DevOps team or like a DevOps practice or this is something just for big orgs, big projects? So, what about that?

Rob Cowell:
No, I know I’m a DevOps advocate and it is my role to promote this, but I do genuinely believe that everybody can benefit from DevOps practices. I was an independent consultant before I joined the company, and I was a one-man band, and I was using a lot of those DevOps processes because I had a lot of clients with a lot of projects, and I needed to get a lot of things delivered, and DevOps was the efficient path for doing that.
So, I think DevOps is never done, and there is no one size fits all for how you achieve that. If you are looking at how do I deliver small incremental change? You are taking on an element of DevOps. If you are saying, “Okay, we need to adopt a source-driven approach where actually we’re using source control, and that is our mechanism for delivering change and being the source of truth,” you’re doing DevOps. If you’re taking backups of not just your data but your metadata, that comes under the purview of DevOps as well.
So, you can take as little or as much of that as possible, and that’s kind of the nice thing. It’s not really prescriptive. One of the things that I encourage folks to do is adapt DevOps to your way of working. Don’t adapt your way of working to fit a DevOps model that you may or may not have read about, right? Not all of us are the Googles, the Amazons, the Facebooks of this world where we need that enormous cloud scale delivery mechanism. I mean, they do some great stuff with that, but not everybody is Google and Facebook and Amazon and all these other sort of huge players.
So, it’s really important to make sure that, as an organization or as an individual or whichever sort of way that you want to frame it, look at where you are today, look at, okay, what do we want to achieve? How quickly do we want to be responsive to the needs of our customers and deliver positive change to them? And then, look at, okay, what are the bottlenecks to that? How long is it taking us from ideation, or receiving a request for a change, to actually getting it out in the hands of the people that requested it?
And then, you start looking at, okay, what can we do to pull those times in? How can we be more efficient? And it’s that constant measure, adjust, re-measure, adjust. It’s much like the traditional development lifecycle, you’re constantly improving. So, DevOps is never done.

Julian Duque:
Never done.

Rob Cowell:
No.

Julian Duque:
Okay. And it is never done, it doesn’t end, but how can I get it started? If I have an org or a project, but I am not applying any DevOps technique, how can I get started at least with the most important, and then, iterating over the other aspects of DevOps?

Rob Cowell:
Yeah. And again, there’s a few things that come into play. I always think that source control is the technical cornerstone of any DevOps process and starting to think about, how can I get my metadata under that source control? And it’s not about pulling every piece of metadata out of your org and dropping it in there. It’s about looking at, okay, what changes over time all the time? What are the things that we work with on a daily basis? Okay. The pace of change for, for example, the account or the opportunity or the contact is quite high, let’s get those under that source control and start with those and grow out from there.
So, from a technical standpoint, that’s a great way to start. But as I mentioned earlier, 80% of DevOps is culture. Okay. So, getting started is thinking about how do we work? How do we want to work? What are the various stages of business process of how do we deliver that change? Do we have the development team do the deployments? Do we have an operations team that’s separate? It still does happen even in the Salesforce world, sometimes, that split. But it’s also about like fostering that culture of, okay, this is our new way of working. We’re not going to go into production and change a field directly. We’re not even going to do that in UAT. We’re going to go through this pipeline. And it’s about getting engagement, getting everybody aligned to, yeah, I can see the benefits of this way of working, because it means that my changes go in first time every time.
And actually, I know that I’m working on this change on the account objects, but somebody over there elsewhere on the development team has got a different Jira ticket, for example. They’re also working on that. So, we’re going to collaborate, we’re going to talk and make sure that we’re not overriding each other’s changes.
So, it’s kind of more of a way of thinking and a way of working. And I’d say, people that wanting to get started with that, it’s, start with the culture, start with the people, start with the teams, and work out how can we structure this? Even if we are still using changesets, how can we get better at that? Because thinking in that way and changing that mindset, you’re starting to do DevOps already. You are thinking about effective delivery.

Julian Duque:
Nice. What is the most hardest aspect of implementing DevOps for you?

Rob Cowell:
Hardest point of implementation. That’s a tough one. I think, perhaps, there’s always this temptation to try and do everything right. To walk before you can run. To have a completely automated pipeline, the developers finish, they press a button, and it’s delivered in production. It’s very rare that that happens in reality. So, that itself is a difficult piece.
Automation, I always encourage folks to try and do these things manually for a few releases, and then, slowly and gradually build that automation. Because trying to automate everything from start is probably one of the hardest challenges.
One of the terms in Salesforce DevOps and DevOps generally is CICD, so continuous integration, continuous delivery, or continuous deployment, there’s a couple of acronyms for the CD part. But the idea is that you are automating that point of, I finished my work, I’m saving it, to, I’m now integrating that into the org. And that is very difficult to do, and very few folks that are starting that journey are ready to do that. It’s really the mature DevOps practitioners that have gone through that journey and learned and burnt, to the point where they’ve refined that process that achieve that.
And it goes back to what I was saying about measure, improve, re-measure, did it make a tangible difference to how we deliver? No. Okay. Do we need to do more or less of something to get that right? And it’s continuous improvement, right? We talk about continuous improvement as a career piece. People, they want to keep learning, they want to improve themselves.
Processes require continuous improvement as well, like technology never stands still, and you need to keep thinking about, okay, how can we get better at this? Are we delivering faster, or are more of our changes not going in first time? What is causing that? Analyze, work out what the problem is, remediate it and keep going.

Julian Duque:
So, you will say that the Salesforce DevOps engineer is a role on its own, like Salesforce developer or Salesforce admin, or it is a skill that either an admin or a developer should have?

Rob Cowell:
So, it can be a standalone role for much larger organizations, but I still prefer as a way of working that everybody has a stake in a Salesforce DevOps process.
I think it is a skillset that everybody should adopt. Because to reiterate what I was saying earlier, it’s a mindset. It’s thinking about how can I break down this change, this requirement, this need into manageable pieces that I can deliver value the fastest? Okay. And it’s about decomposing that. So, that way of thinking is the skillset part. That’s not somebody’s job to sit there and think about how to deconstruct a problem into manageable tasks.
So, yeah, I would tend to, on the side of, it’s a skillset that admins, developers, et cetera should be taking. There are organizations that have dedicated engineers, but I think that the DevOps engineer concept definitely comes from non-Salesforce platforms where they do have to manage servers, virtual or otherwise, and instances and infrastructure and clusters and all the other great stuff that folks on other platform are doing, that we as Salesforce professionals, don’t have to worry about because very smart folks are looking after that for us.

Julian Duque:
Cool. For all of the folks that want to learn more about this skillset or profession role, whatever we are going to call it, what is your word of advice, where to go next? Do you have any specific resource to recommend, any of your talks that you have given on events?

Rob Cowell:
Yeah. So, yeah, I mean, I do talk at a lot of events now. It is very much the nature of my job. But I also, I write a lot of blog posts that you can find on my company’s website. I also contribute to our online self-learning platform. So, we have a platform called DevOps Launchpad. It’s a little trailhead-like in terms of its self-paced learning, it’s modular, it’s free. There are badges, there are certifications.
And what we try and do with that, is to make it about Salesforce DevOps, not about any specific platform or product. So, I’m quite proud of some of the stuff that we’ve written on there, because you can take the techniques and the lessons and the thinking around how do I do DevOps for Salesforce, and you can apply that to any platform, right? You could use DevOps Center, you could use our platform, you could use any of our competitors’ platforms.
Again, this comes back to what we we’re saying right at the top of the call, the short joking version of what I do is stop people using changesets. And these tools are going to help you do that right. The learning there, you can apply to whichever way. I want you to understand DevOps, not understand a specific tool for using DevOps.

Julian Duque:
Beautiful. I love that. And we will share those resources, obviously, to the folks that are listening to us.
Changing will be the topic here. I have seen that you are very active online in something called Shirtforce. Tell us more about that. I have seen some crazy shirt designs, and you were wearing one yesterday that say like this is my lucky demo shirt, something like that. So, tell me about that project.

Rob Cowell:
Yeah, that specific shirt. Yeah. I was doing a talk yesterday for Oslandia here in Portland, and I did have to do a live demo, so I did have my lucky demo t-shirt. But the idea of the t-shirts from Shirtforce is that, it was initiative started by Todd Halfpenny. He’s an MVP out of the UK community. He’s just got a golden hoodie as well. He’s a fantastic guy. I encourage you to connect with him.
But he had this idea of making these topical to Salesforce, hopefully, amusing t-shirts. It’s an excuse for three British guys to use all their best dad jokes on Salesforce t-shirts. But the idea is that we produce these t-shirts for the community and by the community, so we take suggestions for those t-shirts.
But the key thing about Shirtforce is that hundred percent of our profits go to charity, and we change that charity every quarter. So, we reach out to the community, predominantly, through Twitter. I think there’s a lot of contention around that choice of platform these days, but we’re not going to go down that rabbit hole.

Julian Duque:
Yeah, it’s the platform.

Rob Cowell:
It’s the platform.

Julian Duque:
That’s it.

Rob Cowell:
Go where your audience is. So, we’ll say to folks, give us some suggestions for charities that you want us to support for the next quarter. And then, the first three that we get, we put into a poll, people vote, and that becomes who we support.
So currently, for this quarter, we’re supporting Merivis Vets, an organization that helps military veterans and military spouses to transition into civilian technology careers, predominantly Salesforce, but I believe not exclusively Salesforce. And just help people, from that world to start their Salesforce journey.
We’ve done other things for various underrepresented communities or for humanitarian aid. Like we did some fundraising for one of the Turkey earthquakes. So, we try and make sure we do that. And as I say, hundred percent of our profits do go to those charities.
But one last thing I’d love to add on that, is, recently, when Todd got his golden hoodie, he was presented the golden hoodie by the CEO of Salesforce UK, Zahra Bahrololoumi, and she absolutely loved the t-shirt, but what she didn’t realize is that there was an homage to her on the back of the t-shirt. She recently received a CBE, which for non-UK folk, is the commander of the British Empire. It’s like the next thing down from a knighthood or a damehood.

Julian Duque:
Wow.

Rob Cowell:
And so, Todd kind of alluded to that on the back of his t-shirt. And Zahra had seen this, and she’s actually ordered that same t-shirt. And she posted on Twitter yesterday, that she’d received her first Shirtforce t-shirt. So, yeah…

Julian Duque:
That’s an amazing collab. Oh, nice. Awesome. When you are not advocating DevOps or coming up with crazy ideas for teachers, what do you do? What are your hobbies, or what do you like to do besides that?

Rob Cowell:
So, I kind of mentioned this one in passing earlier, about my enthusiasm for making new software for old hardware. So, I have a collection of some of those old computers that I grew up with, and we still continue, me and some friends, we continue to make little productions on that.
Our most recent thing that we did was a set of animations and music and things for a Nintendo GameCube, of all things. So, within our little culture, we have our equivalent to the Oscars called the Meteoriks, and we were a nominee for that production this year. So that made me very happy.

Julian Duque:
Wow.

Rob Cowell:
So, yeah, I do these sort of creative things. I do like the artwork or the music, or sometimes, the coding, but then, I also make music. I DJ. So I unleash the creative side of my brain, rather than the technical side of my brain.

Julian Duque:
Have you ever seen or done these… It’s called live coding…

Rob Cowell:
Yeah.

Julian Duque:
… usually, in the community, but it’s making music live with code. Have you done that?

Rob Cowell:
I haven’t done that, no. But, again, sort of tying that question and some of the recreational coding that we do, we have something called Shader Showdowns. So, we use OpenGL and GLSL Shader language, and we do real time visualizations to music, and it’s done by code. So, yeah, there is a DJ playing. We’re not generating the music, but we’re generating the visuals that go with that.
And there’s the 3D swirling things and patterns and animations and stuff. But you’re doing that like head to head against the clock, and then, the audience is voting for who they think won that. So, yeah, that’s kind of a big part of it. It’s very similar to what you described, but it’s more the visual than the audio aspect of that.

Julian Duque:
That’s fascinating. And one thing I want to add before we end this episode, is also FoodForce. You publish a lot of pretty tasty stuff on your social, so tell us about that.

Rob Cowell:
Yeah. So FoodForce is a sort little sort of sub movement that we created on the Salesforce community. Again, sort of mostly on Twitter with hashtags. And it just kind of grew out from that, people posting nice food and recipes that they’d made. Everyone loves an Instagram food photo, right? And it’s just an extension of that.
But then, it kind of grew out from that. So we did a FoodForce cookbook, so Ines Garcia organized that, and it’s full of healthy plant-based recipes. And again, in the spirit of the way that the Salesforce community loves to work, the profits from that book, again, were folded back into charity for, particularly, food-rated charities, so helping support those that aren’t getting enough food or need support or better nutrition, you know, various projects along those kinds of lines.
And so, yeah, that’s just kind of grown out there, and there’s now a FoodForce website with a bunch of the recipes from the community. There’s constant talk of actually having a meetup across various geographic boundaries to get together and just, kind of like a potluck supper, everyone brings a recipe or something that they love making. Yeah. It’s fostering that sort of community spirit a little bit, but also, doing something for good as well. That’s what the Salesforce community is about.

Julian Duque:
I might need to participate in that. What is your signature dish?

Rob Cowell:
I do a particularly good Moroccan-inspired slow cooked lamb.

Julian Duque:
Wow. That sounds-

Rob Cowell:
That one actually made it into an official Salesforce cookbook that we did in partnership with the AppExchange.
Yeah, I can do a slightly westernized version of an Indian Kima matur, which is like a minced meat and peas curry. I’d imagine that our friends in the IndioOhana will probably not consider it too authentic, but it works for me. And that’s one of my favorites, of course.

Julian Duque:
Mine is the Peruvian ceviche…

Rob Cowell:
Oh, nice.

Julian Duque:
… so maybe that will be my first contribution.

Rob Cowell:
Oh, there we go.

Julian Duque:
Let’s see. Okay, Rob, thank you very much for sharing your story with us, and of course, for making us more aware about DevOps.

Rob Cowell:
Thank you for having me along and allowing me to talk about it.

Julian Duque:
Of course. If you want to learn more about this show, head on to developer.salesforce.com/podcast, where you can hear all the episodes and read the show notes.
Thank you, everybody, and talk to you the next time.

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