Katie Kodes is a Data Developer and the author of the Katie Kodes blog. Today, I’m sitting down with her to talk about APIs, integrations, and dealing with data. 

After being introduced to the world of database design at a young age, Katie shifted gears and studied French in college. However, she eventually found her way back to the tech industry. Tune in to learn more from Katie about automation, data modeling, and more.

Show Highlights:

  • How Katie’s fast typing abilities led her to enter the world of technology.
  • Her journey from data entry to Salesforce.
  • Why she got interested in automation.
  • What admins really do.
  • The benefits admins get by using Apex.
  • Similarities between Apex and Flow.
  • Why you should run Flow tests.
  • How Katie does data modeling.
  • A simple description of API.
  • What a schema is and how you create it.
  • Why you should always get lots of people involved in the projects you take on.
  • Why she posts her blogs in English and French.

Links:

Some of Katie’s articles:

Episode Transcript

Katie Kodes:
And fortunately, my dad knew what a database was. He said, “Oh, well, what you need is called a database, not a spreadsheet. And let me set up Microsoft Access, and I’ll show you a few things, but you can read the tutorial.”

Josh Birk:
That is Katie Kodes, a data developer and the author of the katiekodes.com blog. I’m Josh Birk, your host of 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 Katie about APIs, integrations, and dealing with data. And in that clip, you are hearing her first introduction into the world of database design, after an exercise given to her from her dad. But she didn’t really stick with it, and she actually started studying something else in college: French.

Katie Kodes:
Yes. So, I did that. I got out of college, I realized I did not want to be a professional interpreter or translator, and I thought, “Well, what else do I know how to do?” And I can type very, very quickly, over 100 words a minute. And I knew some things about databases, or at least I could tell a temp agency that, “Yes, of course, I know Microsoft Access,” run to the library, grab a book called, Easy Microsoft Access, and by the first day know more than my boss. Yeah. That was my entrance into the world of technology, was just being able to type fast and getting a data entry secretarial job.

Josh Birk:
I mean, I have to give you props, over 100 words a minute is actually really quite fast. Right?

Katie Kodes:
Yeah. Yeah. I had a really great typing teacher in school.

Josh Birk:
Okay. So, then, describe the slippery slope to me. How’d you go from a data entry job where you know more than your boss to working with Salesforce?

Katie Kodes:
Well, I would say that… Okay. So, once I made my way into data entry in the nonprofit world, the great thing about the nonprofit world is that it’s highly collaborative and super short-staffed. And so, if you ask the same person to do something for you, somewhere between 10 and 20 times in a row, they’ll teach you how to do it, and just give you the keys and say, “Please don’t break anything.” So, that was how I was taught what a cross joint is and not to do it when you’re writing a SQL query. And I would actually say that my first ETL job was Word Mail Merge, from taking a bunch of spreadsheets and trying to get them to do very fancy things.

Josh Birk:
Oh, wow.

Katie Kodes:
Yeah. I put mailing labels on envelopes.

Josh Birk:
Oh, that’s a trial by fire right there.

Katie Kodes:
Yeah. So, really, when a Salesforce admin job opened up, I said, “Hey, it can’t be that much different than any other database.” And the other people who didn’t really know Salesforce said, “If you say so, sounds reasonable to us.” No, it wasn’t quite that simple. But I had a couple of skills that they were looking for, and so I was able to get a Salesforce admin job.

Katie Kodes:
And about a half a year into that, I was starting to formally study computer science and PLSQL and TSQL for Oracle and Microsoft SQL Server databases, and as we were waiting to get triggers developed by outside consultants… And you have to go through business analysis and planning, all of which are great ideas, but also slow you down when you already know the requirements internally, I just thought, “I should learn to do this.” So, that was how I got into Apex. I’ve a little bit stayed away from the JavaScript’s visual side and really have a love for all things data integration, business process automation, all that, making data move from point A to point B, kind of programming.

Josh Birk:
I just love the overall theme here of your interest stays very focused as long as it’s going to help you do less work through the day.

Katie Kodes:
Yes. I have never actually automated myself out of a job, even though I keep trying.

Josh Birk:
Nice. Larry Wall would very much approve. I want to talk a lot today about that weird, fuzzy domain, which is part admin, part developer, and how these programmatic skills can dip in and help. So, walk me really quickly through a term that I am right now trying to remember the first time I heard it, but how would you define an adminelepor?

Katie Kodes:
An adminelepor, oh, I love that one.

Josh Birk:
And also, am I saying that correctly?

Katie Kodes:
I think so. I think Forcelandia, did they coin it?

Josh Birk:
That might be right.

Katie Kodes:
At the Forcelandia conference? Yeah, honestly, I got a chance to go to Forcelandia a year and a half ago, and that was the term that made me want to go to the conference, that used the term. I was just like, “This is the best ever.” But to me, I think an adminelepor, I mean, it could be someone who thinks of themselves as a developer, but they’re stuck being a solo admin because they are the Salesforce team. But I think it’s more common that it is someone who comes from the admin world and needs to be nimble and just has a job to get done and, as you said, is trying to automate away the boring stuff. And so, they end up picking up development skills here and there, not necessarily to any degree that they’re looking to do that full-time, but just enough to make sure that their job is always full of only the most interesting stuff.

Josh Birk:
Yeah. That sounds like a good domain to have. And I just, right now remembering conversations I’ve had with people in the past when I would go to developer groups and I would spend 10 minutes working with somebody, talking about like a visual force problem. And then I’d ask them about their day job, and they’re like, “Well, I’m not a developer.” And I’m like, “You just spent 10 minutes putting together a visual force page. You are in fact doing some developer-y type things whether you identify with that or not.” So, I appreciate a term that allows somebody to hold onto that admin identity, but also basically confess that there they’re getting some programmatic skills under their belt.

Katie Kodes:
Yeah.

Josh Birk:
So, this keeps changing, I feel like. Right? We’ve got flow, we’ve got external services, we have tools that allowed admins to do more and more without any programming. Can you tell me some specific advantages that an admin can get if they just tip their toe in a little bit into the Apex world?

Katie Kodes:
Sure. I think, for me, none of the number one things that you can potentially get is avoiding CPU limits and query limits. I haven’t had a chance to play with flow as much as I would like because I actually ended up learning Apex before Flow.

Josh Birk:
Yep. Yep.

Katie Kodes:
And so I had incurred a lot of technical debt. Most of my code base was in Apex, so I just needed to keep going that way. So, I know Flow has an impressive amount of bulkification, according to everything I hear, but there are certain things where you might just… If you’re in a trigger context and so things need to happen in real time and you really can’t afford for triggers to time out, if you’re not getting what you want out of Flow, you might want to try the same thing in Apex.

Josh Birk:
And it’s been talked about on the pod before, like, and I guess I’m trying to think of… Because we’re inviting an admin who might be used to Flow to take a look at Apex, which is a strongly type programmatic language. So, you went the other way around. You started with Apex, and now you’re starting to look at Flow. When you are poking around Flow, what kind of overlap from a functional point of view do you see between Apex and Flow?

Katie Kodes:
Loops, conditional branching, if statements, variables, parameters, the idea that you design a thing that is self-contained, especially with the world of subflows. I’m a really, really big fan of subflows because that’s how you put everything into little boxes when you code with just text on a page. Otherwise, it would be overwhelming. And again, a whole bunch of flow boxes can be overwhelming, so the idea of subflows and that they’re being certain data you pass from one flow to another, all that is so, so similar.

Josh Birk:
Because you’re basically describing a function there.

Katie Kodes:
Yeah. And it’s interesting, I watched a couple of years ago a Harvard computer science 50 course that started out showing people how to code in MIT Scratch, which is like Flow. It’s a drag and drop visual language that was, at first, invented to teach children how to program, I believe, and they’re teaching college students on their first day in that. And I find Scratch and Flow very much alike. It’s very much the same concepts, it’s just a matter of whether you drag a box onto the page that says “if” or you type the word “if.”

Josh Birk:
Right, right. Yeah. I’ve seen Scratch used in IOT projects. I’ve seen Scratch used to teach kids how to build cardboard robots, which is still one of my favorite IOT moments of my entire life. And I did actually have this moment, and this was when we had Process Builder and we had Flow and everything was still kind of nascent, but I was kind of like, “What would Scratch for Apex look like?” And I think you just answered it. It’s basically where Flow is right now.

Katie Kodes:
Yeah.

Josh Birk:
So, I guess, I hope people are hearing this and thinking, “Okay, if I am doing things, even though there’s this wrapper on top of it…” But you are still dealing with parameters, you are still dealing with the functions, you are still dealing with variables, you’re just not calling that in Flow. So, maybe Apex isn’t going to be quite as scary as you thought. And another point that you’ve made before, and credit to Bonny Hinners on this, how can Apex be used to help test Flow?

Katie Kodes:
Yes. I think the nice thing about Apex that I can’t wait for there to be, basically, a Flow equivalent, but right now, when you write Apex code that creates records and destroys records and checks their values and you put seven little characters at the top, @istest, It does magic. None of those inserts actually happen in the real world. None of that data stays afterwards in the real world. You basically just get a blank Salesforce org that is shaped like your org to start from scratch in. And so, you can hit “run” as many times as you want on a quality check, and it always behaves the same way. It’s never going to pollute your org. And so, over on Pluralsight, Bonnie has created a really great… I think it was a play by play with Don Robins. [crosstalk 00:11:04].

Josh Birk:
[crosstalk 00:11:04] so probably.

Katie Kodes:
Yeah. And Pluralsight does free weekends if you can’t afford Pluralsight, so keep your eye on their Twitter, David Liu’s Twitter. It’s often widely publicized when they have a free weekend. And definitely watch that episode. If you’re an admin who wants to dip your toe into the water of Apex, I think doing apex to test the quality of your record triggered flows is probably a really great place to start.

Josh Birk:
That makes a lot of sense because unit tests, I do feel like, have that… They’re interesting to write sometimes, but you’re always trying to do the same thing. You’re creating records, you’re testing records, you’re deleting records kind of thing. And I can’t tell how many times I’ve talked to developers and we just start geeking about the importance of testing. So, not only should somebody learn Apex to do this kind of stuff, but what’s the value of adding unit test to the flows themselves?

Katie Kodes:
Ultimately, it’s to dummy check that you did it right. There’s this philosophy called test-driven development, where if you’re trying to create a flow that takes two numerical inputs and outputs their sum, then you’re going to want to put it through the ringer and see what happens when your two inputs are one and one and verify that the answer is two. You’re going to want to do three and negative three and verify that the answer is zero. And you can just do this by hand with Flow, but if you do it in the unit test context that’s built into Salesforce, first of all, not only can you just have a test suite that you can run every time you change your flow, just to make sure you didn’t break one plus one equaling two, but you can actually…

Katie Kodes:
This testers and development concept is that first you think about the fact that you’re going to be writing a thing that does addition, and you have a flow that just doesn’t even really work yet. And you write the test first, and you say, “Pass one, pass one, expect two.” And then you go write the flow. So, there are some ways that you can think about programming that, to me, I’ve found Salesforce makes very easy to do and often increase the quality of my work. There’s nothing more frustrating than building a huge loop or decision process and you just realize you did it wrong all the way at the end, and you don’t even know why. So, it can be really great to have these tests that you run bigger and bigger tests as you work, which is another great reason to use subflows and small pieces.

Josh Birk:
Oh, yes. Taking the small parts of the car as opposed to trying to fix the whole thing.

Katie Kodes:
Yeah.

Josh Birk:
Yeah. Yeah. I got introduced to test-driven development when I started doing bigger enterprise contracts, and it was like I became a huge advocate of it. It’s kind of nice to have that checklist of things that you know your code wants to do, and everything starts red and then you just start building the car, and eventually they all turn green, kind of thing. I also just feel like it’s a nice getting things done kind of feel to it, too.

Katie Kodes:
Yeah. Here’s an example, actually. We took a massive sales rep to territory owner ID assignment process and moved it from process builder, in this case to Apex. Probably if I were starting now, I might be interested in doing it with Flow, but at the time, we didn’t have the record triggered flows that we needed and it needed to be highly bulkified So, it was in Apex. But the first thing I did was I wrote a unit test in Apex that said all of the sub… It had all of the one plus one equals two, three plus negative three equals zero, extreme cases in it, and I made sure that it ran with the process builder in place.

Katie Kodes:
Then I built it with the Apex, I turned off the process builder, and I made sure that it still ran. And then I turned off both of them and made sure that it didn’t run. And every time I’ve had to majorly changed this because they change how sales reps are assigned to territories, all I’ve had to do is just rerun it and make sure it still works, and it’s been a lifesaver and probably saved me weeks of rework just having something in place that I know I can trust to verify that one plus one still equals two.

Josh Birk:
Yeah. Yeah. I can remember almost everything about this night except for what the actual bug was, and we were bound to launch a big project for Salesforce. And we did that like we’re doing all the last minute unit tests before we actually go live, and one of them flags red. It took me, I think, four or five hours to fix the bug, in one of those late into the evening styled developer stories. But it was five hours of work in not a bug that went out into the wild, it would have affected thousands and thousands of people. And it’s like when people don’t… Unit tests are just so important. I’ll just leave it at that. So, if you were-

Katie Kodes:
It just really feels good to know that you found the error instead of your boss.

Josh Birk:
Exactly. Exactly. Exactly. So, if we can invite some admins into the wonderful world of unit testing, I feel we’re doing good work there. Okay. So, I want to start breaking down some of the big pillars of integration and walking through how you work with them, and we’ll start with the big one. And I’m going to try to be careful here, because I feel like talking to you that this could be, you know, like another 40 minute interview all on its own.

Katie Kodes:
Okay.

Josh Birk:
Okay. But you really can’t integrate anything without data. Right? Data is the point of what you’re trying to get to. You have your early experiences with data model, you do a lot of data modeling, and maybe this is too generic of a question, but how would you describe your approach to data model? When you have a new project and you have to start creating your new custom objects and your new standard objects in Salesforce, or you’re rolling up a new Oracle database.

Katie Kodes:
Well, I’m a big fan of drive alongs. If I get the chance, I like to see someone share their screen with me and say, “Well, when you’re doing this thing…” Because there’s always a person who wants their job meet easier, almost always with a data integration. And so, I say, “Well, show me your old phone. I’m happy to build you a new phone, but show me around your old phone.” And oftentimes, I’ll then ask them, “Now, does this go anywhere else?” and they’ll show me the other portal. And then I’ll say, “Now, who maintains the connection between those two right now?” And then I’ll ask the CIS admin who maintains the existing connection in between maybe two systems, I’ll say, “Okay, pop the hood and show me the old phone.”

Katie Kodes:
So, the first thing I like to do is just get a tour of what people all ready do and then what people are hoping to do. I really like to whiteboard, I really, especially in a business to customer organization, I usually draw a stick figure in the middle and write, “Person/contact,” under it. And then I start drawing bubbles that are a non-technical, accessible entity relationship diagram, going off into the extra space on the whiteboard or the screen. And so, I start talking about like, “Okay, can this person…” It’s a lot of one-to-one, many-to-one, many-to-many kinds of data model questioning. What should happen here? What if someone tried to do this twice, would you have two records, or would you replace the first record? And so, that’s a lot of what I do. It’s very much a matter of asking people leading questions that come from my education as a data modeler.

Josh Birk:
I mean, it’s very interesting because that sounds like it’s a very task-centric approach that you’re trying to figure out the things that the human is trying to get done, and then re-imagining it on a data level in reverse. Is that a sound paraphrase?

Katie Kodes:
One of the things that I probably almost sound like a robot myself saying, is I always tell people, “I’m sure we can automate that, but what I’d love for you to do before…” They say, “Can this be automated?” and I say, “Probably, but what I really think would be a good idea is if you could do it for about four weeks by yourself. And then let’s schedule a meeting for four weeks from now and tell me all the things that made you feel like a robot. And then we’ll put on a different list all the things that made you mostly feel like a robot, but every once in a while you needed some human judgment. And then we’ll put on another list all the things that you definitely need human judgment for. And we’ll tackle the ones that made you feel 100% robotic first, we’ll do a maybe for the things that made you feel like they need a little bit of judgment, and we’ll say, ‘Well, nevermind, we don’t actually want to automate,’ for the things that you feel need human judgment.” And so, I do definitely see automation and integration as a way of saving humans time.

Josh Birk:
So, keep the human in charge at first, but then divide and conquer what can safely be handed over to the machine?

Katie Kodes:
Yeah.

Josh Birk:
Nice. Nice. Okay. That’s really interesting, and clearly, your deep background of databases… And I’m going to confess before I came to Salesforce, before I was a Salesforce developer, I was a web developer, was mostly front end developer. I sometimes describe myself as an integration developer, but that was actually the middle glue layer between the server and the client, not necessarily talking to other services but sometimes so. But I was a terrible DBA. I once killed an entire database with like a select star simply because I hadn’t put close dates on it or something. Basic things that [inaudible 00:20:57]. I would go into more stories, but I fear that you’d never talked to me again. But when I started working on Salesforce, it’s like, it made it so easy to at least be a good DBA, because they gave you the fields that every object should have. You only were suppose to extend an existing database model and things like that.

Josh Birk:
Coming from the reverse, like having a real background and databases, is that helpful to starting development on, on Salesforce? And do you feel like that there’s pitfalls that people like myself fall into because they don’t have your background?

Katie Kodes:
Well, it’s hard to say because I went Oracle to Salesforce and back Oracle. I very much miss the unit testing environment when I’m having to code in PLSQL. I have to set up and tear down my own data. It’s terrible. I think if you’re going from Salesforce to a traditional database, I think the number one thing you would underestimate is the power of the SQL language itself. Most of the things you would have to do the long way, in Apex you can do the short way in SQL. It’s much richer than SOQL. And I’ve actually read PL SQL books, PL SQL being pretty much equivalent to Apex and SQL being equivalent to SOQL, that caution not to try to get too fancy with your manual iterative programming and to let the SQL engine do the work, because that’s always going to be more efficient, whenever possible.

Katie Kodes:
And so, there are nuances like that, but I think that in reverse, I actually used to run a blog called Oracle to Salesforce as my very first blog because I was trying to get my head around the transition. It wasn’t until I went to a meetup that I realized that you often, to do a join, you have to do what I later learned in school is really a manual join where you’re just looping over, data checking equality, or you’re using maps to do the same kind of thing, and that you’re constantly storing things into temporary memory in a way that you might not in a more traditional database. And so, I actually think it was a little harder to go from the traditional land to the Salesforce land.

Josh Birk:
Because you felt like you had one arm tied behind your back?

Katie Kodes:
Yes. But on the other hand, again, unit testing, unit testing is great.

Josh Birk:
Unit testing is good. Yeah. And I will admit, a lot of my Apex work is basically starting with a bunch of maps, doing a whole bunch of stuff, and ending up with a different set of maps. It’s an extremely common task for an Apex developer.

Katie Kodes:
Yes.

Josh Birk:
Okay. So, taking it one level up, we have a data model. If we’re having databases talk to each other, APIs are the way that these systems can integrate with data. And schemas are one way to tell what an API does. What’s the importance of schemas, and what’s involved in creating them?

Katie Kodes:
Okay. So, I think what I actually want to rewind, and I know we’re on a developer’s podcast, but in case we have any admins listening, an API, it stands for application programming interface. And program is right in the word, but they are trying to… just like Apex is programming but you can do it visually in Flow, Salesforce is working on that here. And what I would say is that when a human navigated, for example, visually point and click navigated software application exists, but it also has a special alternate way of interacting with it that’s meant just for fellow computers, that special alternate way of interacting is the API. I think that’s the best way to describe it. And since most software these days runs over the web, you access it in a web browser as a human, a lot of the… Most of the APIs anybody talks about with cloud services these days, it runs over a protocol known as the hypertext transfer protocol, or HTTP, as you’ve seen it in all the beginnings of your URLs.

Josh Birk:
Right.

Katie Kodes:
And that’s a starting to get like an alphabet soup, but there’s actually not that much to know about it. It’s kind of like Spanish. Once you learn how to say, “Dónde está el baño?” and that you’re hungry, you’ve got 90% of what you need for a one week vacation. And I think that learning just a little bit about what an HTTP request from a client to a server looks like, and the parts that will come back from a server to a client as a response, that’s maybe 30 minutes of study. And I think it’ll really get you a long way towards then being able to read the plain English documentation written about various APIs about how they work, because the computers are almost always going over that protocol. It’s not a very complicated protocol, and so then you can read the documentation. And I had to get that in, and I forgot what you actually asked me, Josh.

Josh Birk:
Okay. So, no, that’s a great… I always love level-setting. That’s a great one-to-one, “Here’s what an API is,” and describe. So, at that point where you have that access point for one computer to talk to each other, what’s the role in the schema for helping those two computers out?

Katie Kodes:
Yes. Okay. So, schema, schema basically means structure, how something is shaped. And so, we are not necessarily talking about the schema of your data in either system as you, the human, perceive it. We are, in this case, talking about the schema which is the particular… So, you’ve got the HTTP protocol, which is a generic set of ways you… It’s a much more generic idea. It’s like the idea that you can have custom fields and custom objects. And then any given API will have its own rules. Like you might have set specific custom objects and specific custom fields in your org that nobody else has in their Salesforce org. And so, when you get a new person, you have to train them what objects you’ve created and why they’re important to your business.

Katie Kodes:
Similarly, an API will have its own rules, and a schema is a way of writing down in kind of a code… You don’t program with it, but it’s a code the same way that like, I don’t know, like secret codes are codes. So, often, in a punctuation standard, a code called JSON or YAML, those are two different ones that are very similar, you will see a computer friendly way of documenting exactly how this API works over the HTTP protocol. And that’s what’s known as a schema. It’s basically the documentation about the API, but computer friendly.

Josh Birk:
Right, right. And not to plug my own show too much, but through the magic of podcast time travel by the time this airs, there will have been an episode by Tony Jiang talking about the open API specification that we are implementing at Salesforce, and a lot of that is about how when you have a good scheme, that computers can just understand how much easier things get. So, I will point to that material.

Katie Kodes:
That is perfect.

Josh Birk:
Okay. Accessing the data, and then to get to the data we have to get through security, and I’m quoting you here, “Ask for permission, not forgiveness.” What do you mean by that?

Katie Kodes:
I mean, there are definitely a lot of things in the world of what you do at work, where it’s almost easier to ask for forgiveness than permission and just get things done and please customers. In the case of security, when we are talking about APIs, we’re almost certainly talking about integrating between Salesforce and something that is not Salesforce, or that is some other Salesforce, we’re talking about taking candy from strangers. And so, you probably have sensitive data in your Salesforce and you probably don’t want to let hackers change the data in your Salesforce or get at it, and so you really… There are a lot of insecure ways to send data over the internet, and this is sending or receiving data over the internet.

Katie Kodes:
And so, to me, I would say absolutely, feel free to learn about HTTP, play with a dev org and an API that just does something silly and doesn’t require a password and go nuts learning how to do it. But when you actually have a real idea like, “I want to use Twilio to text people. How I do this?” Right? If you have a chief information security officer, talk to them and their team. If you have other developers who’ve used APIs before, talk to them, because they come… Developers, especially web developers, come batteries included with all these auxiliary skills, like knowing about security over HTTP and knowing about protecting passwords. Because there didn’t use to be admin friendly tools for doing this kind of stuff, and so it’s not that these are inherently programming skills, it’s just that only programmers had to learn them because only programmers could do anything useful with them. So, definitely before you do anything that actually talks between your Salesforce and your real third-party service, get a lot of other people involved and make it a big project. Because mistakes aren’t going to be pretty.

Josh Birk:
Mistakes are not going to be pretty, and I will put my data security hat back on for a moment and say security is really everybody’s job. That’s when security works best, is when everybody is focused on it.

Katie Kodes:
Yeah.

Josh Birk:
Okay. So, I want to ping on that example that you were just talking about. You had a Cactusforce presentation with Narender Singh about exactly that scenario. Can you tell me a little bit about what you two demo to Cactusforce?

Katie Kodes:
Yes. So, about a year ago, I demonstrated the idea of using Flow to engage in click-based API usage, and actually, I’m going to do another level set here if you don’t mind.

Josh Birk:
Go ahead.

Katie Kodes:
Okay. In Salesforce, there are three different ways you hear the word API, and they’re not the same as each other and it’s really confusing. So, number one, you have inbound built-in; number two, inbound customer; and number three, outbound, and today we’re talking about outbound. Inbound built-in is why you hear about custom fields having an API name. Every tool you’ve ever used that deals with Salesforce Data Loader, MuleSoft, they’re all using the inbound built in APIs that Salesforce is using to be a third-party to someone else. Inbound custom is you can use Apex to poke extra holes in your castle if Salesforce’s built in ones aren’t enough for you. And then outbound is where you can use Salesforce to go out and talk to others third-parties, computer service stores.

Katie Kodes:
So, we’re talking about this third type, the outbound. So, Salesforce has been investing in making Flow able to have declarative click-based ways to consume or use other people’s APIs. And about a year ago, I demonstrated this with a screen flow that just displays random, silly animated gifts, but Narender has actually been doing real work with this and going deep. So, he’s done text messaging with Twilio, scanned document optical character recognition with Google, and a whole lot more. And so, I asked him if he wanted to co-present, and we showed off his text messaging solution at Cactusforce. And we walked through how you put all the parts together with a basic structure is of external services with Flow.

Josh Birk:
Nice. Nice. And you have the resources for the behind the scenes on that up on your website, correct?

Katie Kodes:
Yes. Yes. Katiekodes.com. Kodes is spelled with a K. Slash cactusforce21.

Josh Birk:
I’m going to ask you a little bit about Katiekodes.com, and I’m going to ask you a question you have actually on that site. Katie, why are you writing a blog about three plus programming languages in two human languages?

Katie Kodes:
The three plus programming language is because I am an easily distracted jack of all trades, and I love that. I’m proud of it. The two programming languages is… I was at Dreamforce one year, and I made a friend from France who said, “You’ll have to forgive my English, I really only can do presentations in good English. I don’t have a lot of social English.”

Josh Birk:
Oh, interesting.

Katie Kodes:
I said, “That’s amazing. I could never give an all day seminar in French, even though I’ve been speaking it for so many years.” And so, when I first started the blog, I had a goal that I have failed at, to try to get every post in both languages as a way of practicing my business French.

Josh Birk:
Nice, nice. I can deeply appreciate that. As a Midwesterner who even, at times, has trouble hearing dialects, much less speaking dialects, and I have what I lovingly call a handle on beer Spanish. Like going back to your example, I can go to a restaurant, I can order food. I can order a beer. I can find the restroom, I can pay my tab, and I can get home. And that’s bout it. And so, anytime I’m in a foreign country or anything like that, somebody like… They’re like, “I am sorry for my English.” I’m like, “Please do not apologize. You are all ready far more capable of walking around this world and talking to other people than I am.” So, kudos on that.

Josh Birk:
I did notice that you had section… Because I use Python extensively for web work and scripting and things like that, and this example, you’re using Python as a replacement for Excel. Can you walk me through that?

Katie Kodes:
Sure. I’ve found that oftentimes you end up doing a little bit of a manual extract transform load process as an admin for complicated things. You just download something through Data Loader, you crunch it, crunch it, crunch it in Excel, and then you push it right back into Salesforce. And particularly coming from the world of more traditional databases where it just would have been one massive “insert where” statement, and having not yet completely understood Apex at the time that I started this, I found that using Python against Excel was the closest I could get to that, “I have a massive amount of data crunching to do, possibly 10 times in a row as the data updates,” and people say, “Wait, nevermind, I have an updated spreadsheet.” And so, the idea of scripting something and having a “run” button was really appealing. And also, I found that Python’s pandas module is far more rich than V Lookup in Excel for comparing one spreadsheet to another. And so, yeah, it’s been a little bit of a way of pretending that my spreadsheets are inside of a database.

Josh Birk:
Making them just a little bit smarter.

Katie Kodes:
Yeah. I mean, a lot of people do that by importing spreadsheets into Microsoft Access, but I found that the overhead is just a little bit smaller in Python.

Josh Birk:
And that’s our show. Now, before we go, I did ask after Katie’s favorite non-technical hobby. It turns out it had something to do with when she travels.

Katie Kodes:
Farmer’s markets.

Josh Birk:
Farmer’s markets. Really?

Katie Kodes:
I don’t run a stand, but I have a habit of going to them. In fact, I have actually never been to a celebrity-based keynote, and I’ve been to Dreamforce four times. Because I’ve always been at some San Francisco farmer’s market instead. Because I really make the most use of my time during the sessions. I am at every session, but then I’m like, “Oh great, there’s a celebrity. I can go to a farmer’s market.” And so, I have my very expensive compost habit, is what I call it, because even though I love to cook, I don’t always actually cook it all. But I love the farmer’s market.

Josh Birk:
I want to thank Katie for the great conversation and information, and as always, I want to thank you for listening. I also want to offer a really quick apology because we plugged the weekly charity Fortnite stream that I play with some coworkers and community members a few weeks ago, but I think through the power of podcasting time travel, unfortunately, I think the first time people heard about it was a week that we had to cancel the stream, unfortunately. I swear we do almost always play Thursdays 5:00 o’clock Central Time. If you want more information about that, follow me on Twitter @JoshBirk, or over on Twitch, also @JoshBirk. Thanks again. If you want to learn more about the show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes, and other links to your favorite podcast service. I’ll talk to you next week.

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