How to get more Developer skills in your toolbox with Josh Birk

For this episode of the Salesforce Admins Podcast, we team up with Josh Birk, host of the Salesforce Developer Podcast. We come together about the difference between admins and devs and how you can get more dev skills in your toolbox.

Join us as we talk about why it’s easier than ever to learn to code, and how you can put those skills into action.

You should subscribe for the full episode, but here are a few takeaways from our conversation with Josh Birk.

Thinking like a dev.

While Flow and code can feel like two different things, the thought process behind it is the same. “The admin roles are very process-driven,” Josh says, “whereas in the developer role, you’re really trying to figure out what is the appropriate functionality and what is the appropriate tool to bring that functionality forward.”

The important thing to realize is that these skills are totally obtainable if they’re of interest, and Josh has tons of examples of people who have started without a computer science background and gone on to great things. But even more importantly, understanding how everything works is important so you can communicate effectively with your developers and create something that works together.

What happens when an admin learns to code?

One other thing that gets people tripped up is the idea of task versus identity. Just because you’re doing an admin or developer task doesn’t mean that it’s your identity—things aren’t always so black and white. Sometimes you need to developer tasks, even if you’re an admin at heart. As Josh puts it, “having the developer role and role understand their strengths and their weaknesses helps each other do their job better.”

There’s also the fact that you need someone to help you troubleshoot when something goes wrong. Failure is an important part of learning, and having someone over your shoulder can be a big help. If you make the transition to being a dev or acquiring dev skills, there are a lot of options out there for where to go next.

There’s a lot more in the pod about how to get code skills and what to do with them once you acquire them, so be sure to listen in!

Links:

• Salesforce Developers Podcast: Becoming a Developer with Lexis Hanson

Social:

• Josh: @JoshBirk
• Salesforce Admins: @SalesforceAdmns 
• Gillian: @GillianKBruce
• Mike: @MikeGerholdt

Full Transcript

Mike: Welcome to the Salesforce Admins Podcast, where we talk about product, community, and career to help you become an awesome admin. This week, we are diving into a really great discussion with fellow podcaster and host of the Salesforce Developer Podcast, Josh Birk. You may also know him for Trailhead.
In this episode, we will have a fun discussion about the identity of developers and admins and the tasks that they perform. So with that, let's get Josh on the pod.
Welcome to the podcast, Josh.

Josh Birk: Thanks for having me, Mike.

Mike: So, since we last chatted, somebody started their own podcast.

Josh Birk: Oh really? Who was that?

Mike: Yeah. I don't know.

Gillian Bruce: I know. I know.

Mike: Spoiler.

Gillian Bruce: Josh, it's you.

Josh Birk: Oh, since we last recorded. Oh my God. That was so long ago.

Mike: Yes, it was.

Josh Birk: Well, that was a whole pandemic and a half ago, at least.

Gillian Bruce: Yeah, the way time moves these days, it's like 10 years ago.

Mike: So, you have the Developer Podcast now.

Josh Birk: I have the developer podcast now. We are rounding up towards episode 75. Like y'all, we have gone out weekly since two Dreamforces ago, basically. And, and yeah, no, it's, it's been great. We've got episodes that are, these days lasting somewhere between 20 to 40 minutes, about 30 minutes usually.
And honestly, going back to the pandemic joke, it's like the timing couldn't have been better, because I am catching up with people from the community around the world and having lengthy conversations with them. And I don't think I even was going to be able to do that in the normal world. I don't remember the last time I actually sat down and talked with, and hear about and for more than 20 minutes at a time. And so, it's been really great to be able to have those experiences.

Mike: Yeah, no, it's a great podcast. I'm always glad there's more podcasters for our audience to listen to. Well, we're bringing you on. We did a whole bunch of, of course everybody's doing video content these days, and we got some questions in the community and one of them really stood out that I responded to. It was during our release readiness and I know the developer release rain has got this question too, but there's a lot of people out there and they identify as admins, they identify as developers, they identify as architects and so many different identities. And one of them was, "Hey, I'm doing this, but I need some developer content."
And what's interesting is I sent the question over to you and your response wasn't exactly what I expected, because I really just wanted a link.

Josh Birk: Yeah. Yeah. And it really isn't just a link, I think, would be my answer there. And I'm trying to remember what I actually pointed her to, if it was Trailhead or any of the podcast episodes, do you recall?

Mike: Well, I think it was a combination of both, but your response, because I got you on a hangout because our calendar was free. Your response got me thinking, which was, does she want to learn the skills or she want to learn how to think like a developer?

Josh Birk: Mmm, yes, yes. Yeah. And it's come up on in a lot of different conversations that, for instance, if we start comparing Flow to coding, for instance, and people like to call Flow "low code." But even developers brace at that a little bit, because they're like, "No, Flow is actually more like visual code," and the thought process between putting behind a Flow together versus putting an apex class together is actually really, really similar.
And I think a lot of developers would agree with this too, if you just throw them a bunch of stuff and they just repeat it, that they're not necessarily learning how JavaScript works, for instance. But if you take a step back and actually start looking at the functionality of it, then you start looking at the precise things that you as quote unquote, "the role of developer," is really interacting with.
And so, I think Trailhead is a really good resource, but I think there's also a lot of different resources that bring you through that experience of being a developer that might help bridge going from admin skills to developer skills a little bit more.

Gillian Bruce: So I think that's interesting, because I think we focus so much on the skills and like you said, Trailhead is very skills focused, but that thinking, that strategy, can you dig into maybe what some of those differences are?
You know both the admin and the developer personas pretty well, what would you say are some of the top thinking strategies or shifts between those two personas that stand out to you?

Josh Birk: So, I think the admin roles, they're very process driven. It's very much a getting the right things into the right boxes at the right time for the right people kind of thing. Whereas in the developer role, you're really trying to figure out what's what's the appropriate functionality and what's the appropriate tool to bring that functionality forward.
And so, I think there's a lot of exercising, mentally to do, to go through that process. I would caveat that though, with like... And this has come up a lot in the pod and conversations, it's not a mad scientist skill. It's not an ivory tower kind of thing that you have to get into. It's really just, are you willing to spend some time and mental energy to start getting into those habits of writing code, testing code, proving your functionality, and things like that?
And I have multiple examples of people who have virtually no... They didn't come up computer science geeks, they didn't come up with a Commodore 64 on their desk when they were a kid, they just out of nowhere, were like, "I want to learn these skills," and they just started going through those exercises and it's 100% attainable. Your background does not necessarily limit the kind of role that you want to slowly get into.

Gillian Bruce: I think that's interesting Josh, because I know my personality, I would never have the patience to sit there and write a bunch of code and test it and troubleshoot it for hours and hours on end. I just know that that is not something that even appetizes me in the slightest. But there are people that just love that, and it's like tackling a really complex problem and getting in there. And so, I definitely would have a very hard time being a developer, I know that. I could probably learn the stuff, learn the skills, but actually having that kind of mindset and that kind of approach to my work would absolutely not do it for me.

Josh Birk: I want to add though, quickly, I sound like I'm almost diminishing taking time and learning some of the skills and getting a grasp of triggers and things like that. And I think even if you acknowledge that, that adding developer into your role is it's not something for you, getting your eyeballs on it is still very useful. I've had people in workshops admit to me, "I'm not a developer, I'm not a programmer, I'm never going to code the stuff, but I need to know what you're saying so that I can actually talk to my developers."

Gillian Bruce: Yeah. I think 100%, that's the difference between understanding versus building it yourself. And I think I've also, very similarly, I think it's so interesting to understand how the LWC works or understanding how to troubleshoot and use [SOCO] and some of those more complex things, but I would not sit there and come up with that stuff on my own. But I think that that is an important distinction there.

Josh Birk: Yeah. I have an anecdote for my workshop days, where somebody came to me and said that to me. They said, "I'm not a developer, but I need to learn some of this because I think my developers are lying to me."
And I was like, "No, no. I understand. It's easy to have miscommunications. And sometimes developers, maybe they're not communicating you too correctly, but I'm pretty certain they're not lying to you."
And it was back in the days of remote objects and being able to do things asynchronously. And so, I showed the difference between being able to just load a bunch of stuff on a page. And this was back in the visual force page, those days. And it's like, you have this whole task that's going to just, every time you press the button, this huge amount of data is coming back to the server and then back down the client. And you could just feel the web browser shake when you're trying to do it.
Or you could do it this other way, which is really lightweight and fast and you press the button and it just comes back quickly. And I showed that demo and that person came to me and she's like, "That. That's what's happening." And she pulls up this browser page and it's got this visual force page with a hundred check boxes on it because every single check box has every single attribute that's on the lead object. And you click one of them, and it tries to update basically the entire database all at the same time. And she clicks one of them, and once again, it's like you can almost see the laptop just cry in pain. And she's like, "y developers are telling me this can't be any faster or any better." And I'm like, "They're lying to you. Sorry."

Gillian Bruce: That's hilarious.

Mike: Josh, I think one of the things that seems to come to mind for me is, task versus identity. And just because, to the point of some of the questions we get, an individual doing a developer or an admin task doesn't necessarily mean that that's their identity.

Josh Birk: Yeah. And I feel like we have a lot of like marketing and organizational cruft, which leans to having those very distinct concepts. But then when you wander around the community, that distinction is never as black and white as sometimes we put it in our organization or our training material.
I just had an interview, which is actually chronologically coming out next week, so I think it'll be two weeks behind when this actually airs. But it's with Katie Codes, and a lot of the stuff we talk about is like, what's an admin-eloper? And how did that role happen? And I think her response was something like, there were admins who were occasionally doing developer tasks who wanted to not get rid of their admin identity, but also assert the fact that there were these things in the quote unquote "developer domain" that they were still doing. And I think having that flexibility is good.

Gillian Bruce: Yeah, the admin-eloper a really interesting thing that popped up from the community, which I mean, this is always where these... Everything we get is because of what people are actually doing. And I think it is interesting because understanding the language, understanding the skillset and even understanding the different... A developer approach as an admin, can really add a great deal to your abilities, to either help manage your own Salesforce instance, or even work across different teams and up-level your game there, which I think is a really interesting way to think about it. So, even if you're not going to go down the developer path, understanding enough to be dangerous, kind of thing.

Josh Birk: Yeah, absolutely. And I think we've always said, from either side of the spectrums, having the developer role, an admin role, know their strengths and their weaknesses helps each other do their job. And so I always, and this is the classic example, but I remember being in a business requirements gathering meeting, and they were going through this automation process that was going to have to happen. And I get out of the meeting and I turn to my business partner and I'm like, "That's not that bad. I can put it into a trigger. It'll probably take me a couple of days, but I want to have a couple more days just to be able to test it." And he just looked at me blankly, and this will tell you how old this anecdote is, but he's like, "Or I could just put it in a workflow for you and we're done."
And it's like, I wasn't thinking in terms of how easy that would be for somebody in the admin role just to get it done and not have to worry about the four day process that I was describing. And he was 100% right. And it would have been a far simpler workflow than it would have been a trigger.

Mike: And it would have been native, no code.

Josh Birk: And it would've been native, no code, which, we get that with Flow these days as well. So, you still get that advantage of not having code, but you have a lot of the flexibility too.

Mike: Is some of that just a symptom of systems not having their own configurable backend, front end, prior to Salesforce?

Josh Birk: Yeah, no, absolutely. That's 100% spot on, because I come from a web development background. And so, my world is client server, client asking polite questions, the server thinking about it ponderously and then giving some kind of response. And if there was any automation at that point, that's an integration layer on the server, that's going and kicking something off or handing things over and things like that.
So, I didn't come from a workflow world, or an Excel world or a PL/SQL world, or any of these kinds of things where these configurable automation actions occurred. So, my world for that kind of thing was apex triggers. Doing that kind of automated process at that moment, as me as a developer, that's pretty much the only way I was thinking about it.

Gillian Bruce: So Josh, let's go back to our original question about an admin actually wanting to learn how to be a developer. You talked about like the difference in the thinking, the strategy. What are some first steps that someone in that category might do, from your perspective?
I mean, we do have Trailhead, so clearly we've got some content on there, but beyond that, what are some really good ways to start building your skillset outside of our traditional recommendations?

Josh Birk: Yeah, and we can put them in the show notes. I can point to a couple of specific interviews where this happened. And one of the most recent ones was Lexis Hanson talking about becoming a JavaScript developer. And Trailhead is great for what we were talking about. Seeing the skills and seeing how the code works and learning the nouns and the verbs and things like that.
But when it comes to that, I want to do the exercises and get that muscle memory for putting a function together, for putting methods together, for understanding class structure. One of the things I've heard now repeatedly, is that it's really good to be able to do this with other people. So, if you're learning from people who are expert programmers. And so, one of the things Lexis did is started going to developer group meetings and things like that.
She also utilized Codeacademy and some things like that, but it's having that person who you can throw code at, and do a little bit of peer reviewing on your code and things like that, seems to be a consistent thread of... You have a gym buddy. And so, if you're going to go through that process of exercising until it's muscle memory, having that gym buddy is a really good idea.
And there's RAD Women, I was just talking to Melissa Hanson and she talked about that same thing where it's like, she had people on her team who were pushing her to be like, "You could do Apex." And at this point she has no programming background. And the first two things, she learns is C+ and Apex, which is kind of triumphant.
And I was joking with her because the first thing they did was have her write the unit test so that she could see how that functionality worked against their functionality. And then as she learned how the org was being shaped, get more into the actual Apex side of it. But then that influenced her experiences to be a part of RAD Women and get into these programs where you can talk with other people and you can get coached and you have another human being there who's... I think it's a good analogy, helping you have that gym buddy kind of thing.

Gillian Bruce: I mean, nobody goes to the gym if they don't have an accountability buddy, I totally get that.

Mike: And sometimes they don't go to the gym even if they do.

Josh Birk: Right.

Gillian Bruce: Especially when your accountability buddy isn't very accountable. But one of the things, so, I like taking myself back to when I first started at Salesforce and we were all in four floors in the landmark building. And I worked on the floor with all of our product team. A bunch of developers. And they actually did so much of that, I guess they call it partner programming or whatever, where they both sit at the same desk and are looking at the screens together and actually working together. And I think that's immediately what came to my mind when you were describing that process of having somebody to bounce ideas off of and work with, it's really important when you're getting the developer chops.

Josh Birk: Yeah. I think there's two things that are always true if you're really getting into that role of a developer, identifying as developer. One is that you get into that peer programming, and there's a joke amongst developers that, I'm glad I got you to look over my shoulder because that's the only thing I needed to know to see the bug in my code. Weirdly, just having another human being in your cubicle was the one thing that got you to get to the next point. So, there's always, I think, a social aspect to it, or it's easier if there's a social aspect to it.
And the other thing, that I'm curious to see how this resonates across what we're talking about here with identity and role, because I know it resonates heavily if we added in the architect role, but failure is an option. In fact, it's a requirement. You are going to write bad code. You are going to write code that fails. Your unit tests are going to go red. And this is going to be especially true when you first start learning it.
And I was just talking to somebody about the old days where you had to put in programs by hand based on articles that were printed in magazines. And I always say that this was almost a defining moment for me, because I got so frustrated at the code not working correctly that I almost just never wanted to program a computer ever again. And it's just like, eventually I just wanted it to work enough that I got over that hill. But it's going to be a hill that's there, and it's going to be a hill that's always there.

Gillian Bruce: Wow, writing code from magazines. That's a stamp in time right there.

Josh Birk: Yeah, I'm not young.

Mike: Those things are punch cards [crosstalk].

Josh Birk: It's just after that, yeah. Yeah, yeah, yeah.

Mike: I was saving my box tops and putting them in an envelope, self-addressed and waiting the six to eight weeks.

Josh Birk: Yeah, no, that was the generation right before me. That was, one of my old bosses used to say that I couldn't complain to him until I had to carry my punch cards uphill both ways. Because, that's what he says he had to do.

Gillian Bruce: That's hilarious. Well, I mean, the idea that failure is part of learning and it's very important part of learning, I think is something that is, as you say, it's embedded in the developer experience and developer journey. But from an admin perspective, I could understand how that might be a little like, "Wait, what? I'm going to fail? And that's part of the thing? Because my job is to make everything work and to make my users super happy. And that's why I have Sandbox, that's why I test stuff."
I sense a hesitance in that mental shift. So, that could be a little fear-mongering there.

Josh Birk: And I do like that there's a shared experience, and this is probably true across anybody working with the solutions that are for a lot of customers or clients. You are doing your job right when the trains are coming in on time. And it's like, then nobody's complaining. It's like that, if everything's running smoothly, then that's when things were actually going green. I think that's definitely true for both admins and developers.

Gillian Bruce: So Josh, let's talk a little bit about what the options are when an admin does transition into the developer realm. Can you talk to me a little bit about what those career path options look like? What kind of roles would a newly minted developer in the Salesforce ecosystem look for, and what are the different options in that space?

Josh Birk: Yeah, thankfully it's a pretty rosy picture, and it's also... I think I want to level set that you have different options if you want to expand in this region. For instance, Lexis is really a JavaScript developer and not so much a Salesforce developer, even though she works on Trailhead, so very much in Trailhead/Salesforce ecosystem. And JavaScript is a brilliant language to look at if you want to have wide opportunities within and without the Salesforce ecosystem. If anything, there's a lot of competition for it, which might make that a little bit more difficult. Whereas if you get into Apex and Lightning Web Components and that kind of thing, you can really look squarely at the Salesforce developer ecosystem.
So, as a junior developer, you are the person who is accepting those business requirements and being given some kind of parameters and then getting those that functionality built in. So, entry level developer roles, they're pretty straightforward. I think it's typically more complicated than that if you're trying to use your admin identity and then adding in some kind of developer roles, because I don't know if you're always jumping into a completely new job so much as, for instance, in Melissa's case, what it was, was transitional so that she could still do database stuff and admin stuff and things like that because she works with a lot of nonprofits. And nonprofits by their nature are generally small scrappy teams. And so, if you are somebody who can interface directly with developers, maybe even lend them a hand and have that ability to have a broader spectrum of what's going on with the overall architecture, it can be really, really handy if you're looking at smaller shops, SMB, medium-sized businesses and people who need those, those cross-transactional roles to help a team move forward.
So, it's definitely opening doors and there's some people who are now, they're senior developers and doing their dream jobs because they took those first step forwards and they started doing those exercises and they and found that gym buddy.

Gillian Bruce: That's great. That's great. It's helpful too, to understand what your developer job would actually look like day-to-day. So, when you described, like you're accepting the business requirements and building thing, that is a shift from a day-to-day admin role. So, that's good. I always like understanding, so if I take this job, what am I actually going to be doing every day? It's a good thing to think about.

Josh Birk: Yeah. And there's another thing that's come up recently a lot, which is you have Flow. How do you unit test Flow? How do you keep Flow in check when you're moving it from Sandbox to production? And the correct answer, there's actually Apex unit testing. Having Apex pull the levers that the Flow is going to do and make sure that it does the right thing at the end. And so, there's a good example of, if you've got that domain knowledge between those two things, whether you started from an admin perspective or a developer perspective, your production is probably going to be a lot more stable that way.

Mike: I thought you just told it, it was a good boy and gave it treats when it went to production correctly.

Josh Birk: That's my usual strategy, but Flow and I have a very strange relationship.

Mike: Good boy, Flow.

Gillian Bruce: Josh, you spent many years cultivating that relationship. So, you've earned that.

Josh Birk: I have. There's been a lot of interesting conversations along the way. This is true.

Gillian Bruce: Well, Josh, thank you so much for taking time.

Josh Birk: Yeah, no, it's a delight and I look forward to talking to you two. And I also, just so you get this in audio, I want to thank both of you. Mike, you were instrumental in me thinking that maybe we should actually do a Salesforce Developer Podcast.
And Gillian, I tell people all the time, I am doing this because I trained under the wonderful Gillian Bruce. So, my thanks to both of you for helping getting the Developer Podcast up and running, because it wouldn't have happened without you.

Gillian Bruce: Hey, we love having new awesome Salesforce podcasts, and you have just taken it and rocked it. So, thanks for the kudos, but it's all you Josh. So, nice job.

Mike: Yep.

Josh Birk: All right. Well, thanks for having me. And I look forward to talking to you two, in the future.

Gillian Bruce: Well, huge thanks to Josh for taking the time to chat with us today. It's always great to have another fellow podcaster join us on the pod. It's like metapod action. If you want to learn more about all things, Salesforce Admin, go to admin.salesforce.com to find more resources. You can check out Josh's Developer Podcast at developer.salesforce.com.
And as a reminder, if you like what you hear on our pod, take a second and pop on over to iTunes to give us a review. I promise that Mike and I read them all. You can also stay up to date with us on social for all things admin @SalesforceAdmns, no 'I' on Twitter. You can find our guest, Josh Birk on Twitter, @JoshBirk and my co-host Mike, @MikeGareholt, myself, @GillianKBruce.
With that, I hope you all have a wonderful day and we'll catch you next time in the cloud.
My neighbor has a tortoise, Zippy, who walks around in the backyard.

Josh Birk: Because Paige was like, "I really want to go get a turtle." And we had forgotten about the salmonella scare which made turtles not pets anymore.

Gillian Bruce: Oh yeah.

Josh Birk: Yeah, so.

Gillian Bruce: Yeah, they are huge harbors of nasty salmonella, but the best part about Zippy real quick, is that, tortoises live for 80 plus years. So, my next door neighbor, Bernadette, she's older. She's got to be in her seventies and she's already having to create her retirement plan for Zippy after she passes because no one's going to be around to take care of Zippy. So, she's like, "I've talked to the zoo. The zoo is willing to take him."

Josh Birk: Oh, aw. Aw, Zippy.

Gillian Bruce: So, caution when you, when you invest in animals that live a long time.

Josh Birk: Yes, yes. You might have to consider that they're living well, true.

Mike: I think I read somewhere that there was... One of the oldest tortoises was like 180 some years old.

Gillian Bruce: Yeah, some of those Galapagos tortoises.

Mike: I'm fairly certain he doesn't care. Do you think he remembers his first owner?

Josh Birk: I think your one 180 is probably very similar to year 80, which is probably very similar to year 40 for him.