Get ready for an incredible journey as we chat with Jeremiah Peoples, a Senior Developer Advocate for Slack at Salesforce, and explore his fascinating career path. From his earliest computer encounters to joining the Air Force and teaching himself to code, Jeremiah’s story will inspire you to chase your dreams. Learn how he became a freelance YouTuber and ultimately landed his dream job at Slack, where he now shares his unique perspective on the power of Slack as a development platform and its potential to make the other 98% of software more efficient.

But that’s not all – we’ll also dive deep into the world of building modular Slack applications. Jeremiah walks us through the new tools available for Slack developers, the starting point of the Slack CLI, and the different ways you can trigger a workflow. Discover the magic of Block Kit, a tool for building surfaces with JSON, and how modularity can be used to create powerful applications. Don’t miss this enlightening conversation that will leave you eager to explore the endless possibilities of Slack development!

Show Highlights:

  • Exploring the world of building modular Slack applications, including the new tools available for Slack developers.
  • The three main pillars of modular Slack applications: functions, workflows, and triggers.
  • The different ways to trigger a workflow in Slack, including event triggers, shortcut triggers, webhooks, and scheduled triggers.
  • The upcoming features for Workflow Builder, including conditional logic and a greater contribution to the ecosystem of apps in Slack.

Links:

Episode Transcript

Jeremiah Peoples:
… For the most part, yeah. I’ve always been interested in computers. I believe my first videos on the internet were me trying to break open a phone and explain what’s going on in it.

Josh Birk:
That is Jeremiah Peoples, a Senior Developer Advocate for Slack over here at Salesforce. I’m Josh Birk, your host for the Salesforce Developer podcast. And here on the podcast you’ll hear stories and insights from developers, for developers. Today, we sit down and talk with Jeremiah about the next generation of Slack development, how developers can interact with it. But we are going to continue on as we often do, with his earlier.

Jeremiah Peoples:
Earliest memory of a computer. I believe it’s around the RuneScape era. I mean, there’s obviously stuff before but the RuneScape was one of the most interesting parts about the internet for me. I’m like, “I can talk to other people around the world and I can do stuff online with them? Wow.”

Josh Birk:
Right. What I love as a gamer myself is, 7 times out of 10 when I ask that question, the answer is in the form of a video game. It’s just that moment of time that we’re like, “Oh, this is what I’m going to spend a lot of time on.”

Jeremiah Peoples:
Absolutely.

Josh Birk:
Out of curiosity, how did joining the Air Force impact your career?

Jeremiah Peoples:
That’s an interesting question. So I didn’t join the Air Force with a computery job. I was a Intelligence Analyst to start, but about halfway through my sixth year enlistment, I’m like, “I don’t really want to do this for the next 20 years, so I need to figure out something else I want to do.” So that’s when I started teaching myself how to code. And alongside that, I started to document the journey, and that’s how the transition to developer advocacy came about.

Josh Birk:
Got it. I just have to ask, an intelligence analyst, does that mean you were a spy?

Jeremiah Peoples:
So next question, Josh.

Josh Birk:
Best answer ever. And I think this is actually now blending, what was it like being a freelance YouTuber?

Jeremiah Peoples:
Amazing, actually. I had no idea what I was doing. I believe I started in COVID, so I was just trying to express myself in a time where we couldn’t go outside, but I just had some amazing opportunities come to fruition because of YouTube. The best being this job because it’s essentially what I did on YouTube, but now I get to do it full-time.

Josh Birk:
That’s awesome. When did you first start getting involved with Slack?

Jeremiah Peoples:
I just hit my one-year mark about a month ago, so I’m still pretty fresh in the company.

Josh Birk:
Nice. Were you involved with Slack development before you joined Slack? Or was it, you took your skills and approached Slack that way?

Jeremiah Peoples:
The second option. I had no experience building on top of Slack, but once I onboarded, then I learned all the things and now I can teach all the things, which is probably the main thing a developer advocate needs to do.

Josh Birk:
I love it. So riffing off of that, how would you describe your current job?

Jeremiah Peoples:
It’s a fun one, that’s for sure. The thing about developer advocacy is, it’s just really hard to explain it, but I have I think three pillars of my job. One is the public speaking portion, to where events occur outside in the world, like Dreamforce and TrailblazerDX, and I get to do keynotes and talk to audiences there. So that is one of the pillars. My favorite pillar is the content creation aspect where I get to make YouTube videos, internal videos, and just a lot of videos and documentation about what the next generation of Slack platform offers. And then the last pillar of developer advocacy that I do is internal or external workshops with companies.

Josh Birk:
Gotcha. I sympathize. I had the title, Developer Evangelist. And when I first told my dad about my new job, he thought for about three months that I was writing religious software.

Jeremiah Peoples:
I get that a lot as well. When people say that evangelism, my parents were like, “Oh, so you’re preaching Slack?” “Not quite.”

Josh Birk:
I fought the trend to go from evangelist to advocacy for a long time. And then I’m like, “No, this is a good trend.” I think it’s easier to say that I advocate for this platform as opposed I evangelize for it, so I hear you there.

Jeremiah Peoples:
Well, I’m glad that we have a similar background and experience. We’re synced up.

Josh Birk:
Yes. And yes, most of the people I know find it very difficult to describe my job, so I very much appreciate. Now, a lot of people think of Slack as a collaboration tool, and I think I’ve had a similar issue with this with Salesforce, because sometimes my job, the first thing to do is tell them that it’s actually a platform as well that you can build applications on. When people approach you and you’re like, “No, Slack’s also a development platform,” how do you describe it as a development platform?

Jeremiah Peoples:
First, want to get an understanding of what they know about Slack, because I feel like a lot of the people that I meet at conferences that are unfamiliar with the Slack platform are like, “It’s a great place for communication.” And that’s fantastic. If that’s what you’re using Slack for, that’s great. But the Slack platform is the cherry on the top that makes it really amazing. So I think a lot of people in Slack say that Slack is the 2% of your software that makes the other 98% more efficient to use. But to have that 2% be the thing that enables the other 98%, you need applications and automations. And that’s essentially the Slack platform, the automations, the things that make it really efficient.

Josh Birk:
When you’re learning Slack specifically and things like that, did you have an aha moment where you’re like, “Oh yeah, no, this is the jam”?

Jeremiah Peoples:
Could you explain more about the aha moment?

Josh Birk:
So I’ll tell you what, I’ll flip it over. For me, my aha moment with Salesforce was when I realized that, so I have a wide variety of history with development. One of the things I have always been terrible at is database design. I once created a PHP application for my family, and one time my brother was like, “Hey, can we delete all of the data from everything from the last year since we’re not using it anymore?” I’m like, “Sure, of course. It’s a database, that’s easy.” Unless of course like me, you forget to do things like add a created date field. So my aha moment was in Salesforce, you can’t do that. You create a custom object and instantly they force you to have good database design. And I’m like, “Aha, this is a development platform that I can get behind.”

Jeremiah Peoples:
Got it. I had I guess two aha moments. One was the aha moment of someone who’s using Slack to get their job done. So when I first onboarded, I was like, “All of these little workflows and applications, I’m going to use them because it helps me.” And then I realized, “Oh wow, I don’t have to go to Google Drive to give you access. I don’t have to go to Zoom to join a meeting.” I can join and do all of these things from one place, which saves so much on context switching.

Josh Birk:
Right. I love it. Was there a second one?

Jeremiah Peoples:
There was a second one. On the second one it was using the new features that have come out in the last year for the developer experience of, “Wow, not only are these applications really powerful, but I can now spit up an application in just three minutes and get started and deploy it.” And that is super amazing because when I first onboarded, I started building applications the traditional way just to test it out. And it was great, but it took a bit of time to do and it took a bit of configuration and time to set up before I got that Hello World. But with the new features, the new developer experience tools, that is a lot quicker.

Josh Birk:
So I’m going to jump ahead a little bit because I had that one down the list, but let’s dig into that a little bit. Well, actually let’s start with what was the old, what was the traditional developer experience with Slack? How did I ratchet up an application?

Jeremiah Peoples:
That’s a great question. So the traditional way of building Slack applications is a good process, and many of the applications that we all use today were built the traditional way. And we have a couple frameworks that support JavaScript, Python, and Java. And with those, you can create an application. However, there was some problems that we were hearing from our developers saying that permissions and scopes and credentials and tokens, and it was a bit hard configure and manage. And not only that, they were very monolithic. So you would build an entire application, there’d be some great logic within it, but it wasn’t really able to be reused or repurposed. So with all those learnings, we built the next generation Slack platform to be one that is modular and reusable and flexible.

Josh Birk:
Got it. So prior to the new tools, it was an application in a jar thing. And other platforms I think do this, where it’s like, “That’s a Node application, we’re going to create a little hole to it,” but it’s just running in a folder somewhere. Now it sounds like it’s more, I could create a portion of an application and share that with you in your pre-application so that you would not have to reuse that or you would not have to rebuild that.

Jeremiah Peoples:
Absolutely. The application in jar was a great way of putting the traditional applications. Jars are very useful. I’ve used jars before in my personal life. I love jars, but there’s something about building blocks that I can now create a Taj Mahal of an application without having to build all the blocks myself.

Josh Birk:
Right. What’s the developer experience itself like? If I’m sitting down on VS Code and I have my Slack workspace, what’s my starting point there?

Jeremiah Peoples:
So the new starting point now starts with the Slack CLI. Are you talking about the new starting point or the traditional way?

Josh Birk:
Yeah, the new starting point.

Jeremiah Peoples:
Perfect. The new starting point is the Slack CLI. That’s the command station of how you can manage your applications, you can deploy them, run them locally. So it starts with the Slack CLI.

Josh Birk:
And so once I’ve jumped into the Slack CLI, you were saying you can do things in minutes, so it gives me that access to that Hello World application, basically?

Jeremiah Peoples:
Absolutely. And even better than that. So a lot of times the application that you want to create is very similar to an application that’s already been created. So if you don’t want to create an application from scratch, you can actually say “Slack create”, and then pass in an argument to a GitHub repo and it will clone that repo down to your local machine and you can just tweak it and adjust it as needed. And we do have about 20 samples that you can get started with and tweak to your liking as it stands right now.

Josh Birk:
Got it. Nice. Can you walk me through the working layers of a Slack application and tell me a little bit about how they actually function?

Jeremiah Peoples:
Now Josh, I would love to. So once again, you can create your apps at Slack create, and that’s going to build the files that you need. And essentially, there’s three main pillars of a modular application, and that’s the function, the workflow and the triggers. So for the functions, they’re atomic bits of functionality and there’s two types of them. The first type is Slack built functions, which make it really easy to do Slack native commands like send a message, send a dm, invite a user to a user group. So that’s one type of function. The other type of function is custom functions, which as you probably could imagine, you can make custom functions. So once you have your functions that you want, you can assign them in logical order and stack them, and you can wrap them in what we’re calling workflows. Pretty simple, just a wrapper to your functions. And then at the very end, once you have a workflow full of functions, you can pick how the workflow is triggered.

Josh Birk:
Got it. And what are some of the different ways you can trigger a workflow?

Jeremiah Peoples:
So right now I believe we have four, and the four different trigger types are event triggers. So when someone joins a channel, you can launch a workflow. The second one after that is a shortcut trigger. And this one is actually pretty cool. It’s my favorite one to use because it’s so easy for local development and sharing. You can essentially generate a link that ties to your workflow. So many people pass links within Slack, so you can pass this shortcut trigger, and it’s essentially your application. So [inaudible 00:11:57] into a card and the end user can then use your application from there.

Josh Birk:
Got it. And you’ve got two more.

Jeremiah Peoples:
Yes, sir. After that we have Webhooks. So this is when a external piece of information outside of Slack changes, someone stars a GitHub repo that could kick off your workflow. And the last one is scheduled, which as you probably can imagine Josh, you can set a time in the future for your workflow to run.

Josh Birk:
Got it. Got to love a good old-fashioned crunch job. Like it.

Jeremiah Peoples:
Love that.

Josh Birk:
So you mentioned there for a second, a card. Tell me a little bit about what Block Kit is and how does that help in user interface design?

Jeremiah Peoples:
Gotcha. So Block Kit is our tool that we use to build a surface, and the surface isn’t synonymous with a modal or a pop-up or something that you can see. So with Block Kit, you can build a surface or something that you can see with JSON. And that JSON, if you format it correctly, it’ll appear as a pre-designed portion of an application. This takes away the burden of a developer having to worry about how something appears and it puts it on Block Kit. So a super formatted way to build and have your application represented.

Josh Birk:
Got it. Walk me through a little bit of the modularity about what we’ve been talking about so far. So for instance, you’re putting your functions, you’re wrapping them in a workflow, you’re exposing them through triggers, you’re creating surfaces that are going to represent user interface design. If I’m building something that’s similar to that, how do I access the portions that you’ve already built?

Jeremiah Peoples:
Glad you asked. So in the very near feature, we have the next version of Workflow Builder coming out. Workflow Builder is our no-code tool to where you can build a workflow without code by dragging and dropping. And right now, you can do that with very simple steps. When someone joins a channel, you can write them a message. However, developers and builders will be able to collaborate in the future. So when a developer writes a fantastic piece of code that accomplishes a task that many people will need, that developer can deploy it to Slack managed infrastructure, and it will show up as a step for builders. So they can drag in that very complex piece of functionality without writing any additional code themselves.

Josh Birk:
Got it. I like it. And don’t worry. And this is actually, I think the second time I’ve made this joke in recent history. I like to say that every now and then when you’re listening to an interview, you can hear when somebody’s using air quotes. My audience is very used to hearing the asterisk after a statement like, “In the near future…” When you say near future, what’s available now and what’s it looking like in the near future? What timeframe are you thinking? Again, asterisk.

Jeremiah Peoples:
Well, the near future is actually super near. So all the developer tools are GA, they went GA earlier this year in 2023. And the next generation of the Workflow Builder, that will be GA in just a few weeks actually. Summer of ’23.

Josh Birk:
Got it. What development skills are required to build on Slack?

Jeremiah Peoples:
So we have a wide range of ways that you can start building automations. As I mentioned before, even if you don’t have the technical background, you can still build very valuable workflows using our no-code builder, our Workflow Builder. So that is how you can get started, even if you have no programming or coding experiences at all. But if you do have coding experiences, we offer a wide variety of ways to get started. Our next generation platform currently only supports the Deno runtime environment, as well as TypeScript. So if you know those two languages in that runtime environment, you’re in a good start. But if you want to build traditionally, we also offer frameworks for Java, Python and JavaScript.

Josh Birk:
Got it. So the old ways aren’t necessarily going away. You can still build it that way, but you’re just not going to get some of the niceties, like being part of the Workflow Builder that’s coming up.

Jeremiah Peoples:
I believe the future is the next generation way, so we are still trying to support all the applications that have come before. But I don’t want to speak for the whole entire company, but I believe we’re moving forward with the direction of the next generation Slack platform and those tools.

Josh Birk:
And once again, always the fine line a developer advocate has to walk.

Jeremiah Peoples:
Yes, for sure.

Josh Birk:
I love it. And you can make it specific or generic or anything like that, but give me some of your favorite examples of applications that you’ve seen built.

Jeremiah Peoples:
I like the applications that bring people together in a way that’s meaningful, and I’ll explain what I mean by that. So one of the things that I like about Slack I mentioned before, is that you don’t have to monitor five different applications on your desktop all at once. You can do all of that from one spot, and you can go even further by having automations, and you can go even further than that by having them tied to Webhooks. So let’s say you have a issue occur in Jira or GitHub, that can automatically kick off a workflow that invites everyone to a shared channel, educates them on the problem and then points people in the right direction so that they can mitigate that problem quickly.

Josh Birk:
That brings up an interesting example, and it twist the next question I was going to have. Well actually, let’s level-set for everybody just so that they know we’re using the right notes. What is a Webhook and how does it work?

Jeremiah Peoples:
Webhook essentially listens to something that is occurring outside of Slack. So you can set up a Webhook to integrate with an application that supports it, and you’re waiting for some event to occur before you do X, Y and Z.

Josh Birk:
So it’s instead of an outward API call, I go to GitHub, I set up a Webhook based on certain parameters, and then back in Slack I can just go basically say, “Listen to this URL and react when it changes.”

Jeremiah Peoples:
Essentially. Yeah, that’s right.

Josh Birk:
Are there other modes of integration with other, you mentioned there’s Google Drive integration and there’s all these things. Is Webhook the main system or are there other options?

Jeremiah Peoples:
There are other options. So Webhook is a type of triggers. As I mentioned the four other ones, scheduled, link trigger, Webhook triggers and then event triggers. But under the hood, they’re all essentially using the same set of Slacks OpenAPIs to accomplish a task. How you trigger them, you can pick from one of our trigger types. But for the most part, they’re using Slack OpenAPIs to accomplish the task that is needed.

Josh Birk:
Got it. So Webhooks is one way to jump ahead, but if you’ve got the good old-fashioned REST API that you want to integrate with, that’s totally an option as well.

Jeremiah Peoples:
Right.

Josh Birk:
Got it. Very cool. Not the near future, is there anything on the longer roadmap that you’d like to give a shout-out to?

Jeremiah Peoples:
So it’s been highly requested, but Workflow Builder, not this next version of it but a version in the future, asterisk, will have some conditional logic it’s on. It’s definitely being planned for and worked towards, but conditional logic in Workflow Builder will be a game changer because a lot of our audience, our community is actually building Workflow Builder workflows. So enabling them to have more tools at their disposal will just be a greater contribution to the ecosystem of apps in Slack.

Josh Birk:
Got it. Love it. Let’s say I’m a developer, I know TypeScript, I’m curious about this, but woe as me, I’m not even a Slack user. How do I get started?

Jeremiah Peoples:
So if you want to get started building and you know TypeScript and you know Deno, you are in a really good position to head over chart documentation and check out a few of the samples that we have already created because you don’t really need to recreate the wheel if you don’t have to. So oftentimes, it’s a lot easier to see a sample, get a great idea and then tweak it to your liking.

Josh Birk:
Got it. Jeremiah, I’m going to show my ignorance here. What is Deno?

Jeremiah Peoples:
So I know you’re familiar with Node, is that correct?

Josh Birk:
Correct.

Jeremiah Peoples:
So Node was built by this amazing person named Ryan Dahl, I believe.

Josh Birk:
That sounds right.

Jeremiah Peoples:
He built that in 2009. But a couple years later, about a decade later in 2018, he was like, “I wish I would’ve built it a bit more secure with some modern web APIs and in the headache of module management.” And so he did, and he shuffled up the letters and now he’s calling it Deno. And at Slack, we’re early adopters of the Deno runtime environment.

Josh Birk:
And that’s our show. And before we go, I did ask after Jeremiah’s favorite non-technical hobby, and well, it’s one that’s sometimes a little hard to access here in the Midwest.

Jeremiah Peoples:
Favorite non-technical hobby? I mean, I like content creation but I don’t think that counts. So outside of that, I’d say Ultimate Frisbee and snowboarding. I live to play Ultimate Frisbee and snowboarding.

Josh Birk:
That is awesome. Where do you get to snowboard?

Jeremiah Peoples:
So I’m chasing mountains. I go to a new mountain every year, and I believe this year we’re going to a mountain in Washington.

Josh Birk:
I want to thank Jeremiah 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 have links to your favorite podcast service. Thanks again everybody, and I’ll talk to you next week.

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