In today’s episode, I talk with Claire Bianchi about a new product that was just announced: Code Builder. Claire is a Director of Product Management for Developer Tools and Experience here at Salesforce. She has experienced the frustration of configuring new code and knows the benefits of this new product. 

During our conversation, Claire explains what Code Builder is and how it can help less technical people work on the platform. If you know the basics of Salesforce but don’t feel comfortable with the more complex functions, listen in. You will learn how Code Builder can help you take that next step into development.

Show Highlights:

  • What Code Builder is and how it saves you time and energy.
  • The targeted audiences for Code Builder. 
  • The ease and access that Code Builder provides.
  • The integration that Code Builder has for the org you’re signed into.
  • What the experience coding directly within the org is like.
  • How DevOps interplays with Code Builder.
  • What the future of Developer Console is and how will it impact Code Builder.
  • Why Code Builder isn’t daunting but gives you power instead.
  • The features Claire’s hoping to get into by DreamForce.

Links

Episode Transcript

00:07

Claire: And I went and I spent two years on the big bucket team, improving pull requests, I owned our ecosystem. I did a whole bunch of work on pricing and the pipeline’s product. I learned a ton there. I loved working with engineers, and I love building developer products. And so when I finally decided that I wanted to move on, I interviewed a whole bunch of different places. And I ended up at Salesforce on the DX team, because I met Dave Carroll. And he wanted somebody who would think about dx in a way that they weren’t super, super technical, because a lot of the product managers who are all really wonderful. A lot of them are former engineers. And so they come at it from that standpoint of like, what is a pro dev workflow, and what we needed on dx at the time was Somebody did start asking, Well, what if somebody who’s doing Salesforce development isn’t a pro dev? How do we help them and that’s sort of where the niche that I found on on the DX team and that’s how I became a product manager here.

01:13

Josh: That is Claire Bianchi, Director of Product Management for developer tools and experience here at Salesforce. I’m Josh Birk, a developer evangelist with Salesforce. And here on the Salesforce developer podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Claire about a new product that was announced during the week of trailhead dx code builder, and how code builder can help but pro devs and less technical people work on the platform. But to kick things off, let’s talk about what is Code Builder.

01:41

Claire: Code builder is a modern web based development environment. And what’s great about code builder is it comes pre configured because I don’t know how you feel but whenever I open VS code for the first time and have to configure it for my project. I want to cry Because I don’t know what I’m doing, I don’t really understand node, why do I have to set this up? What’s this bash thing, all this stuff, there’s extensions, which extensions Am I have to search in? code builder comes pre baked. So you’re gonna, it’s a managed package that you install into your org, you go to our workspace manager, you create a workspace, when you go into code builder, it comes with all the Salesforce extensions already installed, as well as some of the extensions that we think you should be using, like es lint already ready. And we sort of pre baked it by you know, authorizing org that you’re coming from you, you need an SF dx project to use our extensions. So we’re going to give you one or if you already have one, we’re we’re going to onboard you into that really easily. So instead of setting up this local development environment or this development environment for yourself, like it comes with everything you need, but What’s also nice is it saves that stuff for you. So then Next time you go to that workspace, it remembers all the things that you wanted. So even if you really do like a light theme instead of a dark theme, or you wanted something really specific, or you’re also working on some other project that required this extension, right, you will remember that so you can configure it however you want. But I think for somebody like me, who, you know, feels comfortable, you know, editing a trigger, or writing an apex class, but maybe doesn’t feel fully comfortable, like building an entire app, and setting up that environment that I would need to do that. It comes with everything I need not, it’s sort of like an easy button for development and getting started. And I hope that it’s a good place that people who are ready to take that next step into development can learn from that and what’s great, it’s the same interface that they would be using, if they were, say, building a Python app.

03:50

Josh: Right. And so to kind of bring it back to what we were talking about earlier, when people think Visual Studio code, I think a lot of them like that. That Just that brand, almost you know it, I think it’s associated with like the power dev or the or the promo. But your purpose with code builder is really to, like, what are some of your other targeted audiences?

04:13

Claire: Yeah, we are really targeting Salesforce developers. And as I said, Salesforce developer, in my mind is anybody who is configuring the Salesforce platform. And so if you are using our builders 90% of the time and 10% of the time, you might need to write an apex class, or maybe you need to write a socko query, we want you to also feel comfortable using this tool. So anybody today who might use Developer Console, or workbench, we hope that this will be an inviting environment that they can jump into really quickly get their work done. And, and and move forward. We don’t want them to feel intimidated by it. And I’m doing a lot of so we’re going to pilot and we’re going to do it. ton of research with those pilot customers to make sure that we build a product that is inviting that you get quick wins from that helps you move forward and grow as a developer on the Salesforce platform. Because a lot of the feedback we’ve gotten, frankly, on VS code for that subset of people were like 50 to 90% of their time is really in Salesforce builders, which is great. It’s where they should be. That’s why we create builders is that VS code is intimidating. It’s daunting. They don’t know what to do, they don’t know where to go. And we want to create something that allows them to be part of best practices. We want to give them the IntelliSense and, you know, the inline help and all those things that we built for pro devs. That stuff is super helpful, like being able to hover over something and get a ton of information about what that specific tag does and an LDC component that’s valuable to a pro Dev. It’s probably even more valuable to somebody who’s completely new to Lw see development and just needs to understand how this thing works. But That doesn’t exist today in our tooling. And that’s what code builder really bring is that ease.

Josh: And you can get access to all that without complaining about what version of Java you’ve got.

06:10

Claire: Yeah.

06:14

Josh: That That would be great. Okay, so talk to me a little bit more about the integration that the code builder uses, specifically to the org that you’re signed into.

06:24

Claire: Yeah. So right now we’re working on figuring out how to fully off into sort of your portfolio of orgs. But when you when you launch, you launch from the org that you’re coming from, like that you had the Manage package installed, and this might be your production org, this might be your dev hub org, maybe it’s a sandbox, it really depends on how you work and your team works and where they want to have have that. When you launch. We will give you the option to authenticate into that org and we’re working on figuring out how to give you the to authenticate into any of the orcs you’re associated with Now, that’s a little bit, you know, behind behind the curtain, but there’s some some nuances there. But generally we want to when you are setting up your workspace, and by setting it up, it’s gonna be really straightforward. You click to create your workspace, it asks you, hey, we notice you’re in this org, do you want that to be your primary default port? Great, we’ll do that for you. Hey, do you have an SF dx project? Do you don’t have one? Awesome, we’ll create that. Do you want to do it from a template? Great. Are you doing source driven development? Or are you going to move your changes, you know, in between orgs manually, awesome, not a problem. We’ll create an SF dx project for you with a manifest. And then when you open code builder for the first time, you’ve got your SF dx project, you’re at least authenticated into the org that you came from. And maybe you’re authenticated into a sandbox or two, and you can get going

07:54

Josh: Nice, nice. And if I’m coding directly within the org, what’s the experience like to make sure that I’m seeing back if I, if I am that repo centric kind of person, how easy is it to keep the code that I’ve got in my org synced with that?

08:08

Claire: Absolutely. So there’s a couple ways to do that. So if you’re so what’s great about code builder, it will work with scratch orgs. So out of the box, scratch org come with source tracking, between code builder and the org. So if you’re using scratch orgs already, you already know the wonders of scratch orgs. But as you make your changes in your org, we track them. And then you can do a quick poll, and then you can get that into your version control system. If you’re using a sandbox, you have to still remember just like you do with change sets what you changed. And you can do that by specifically calling out the specific set of files. When you do a retrieve. We have this awesome thing called the org browser, which is actually available on desktop on desktop VS code as well, which basically gives you a full picture of all the metadata in your org. So as you can go on, do a ton of work in your sandbox, you go back, you open the browser, and you’re like, yep, I created this Lw C, I did this with the community, I did XYZ with this flow, I’m gonna get those all locally. So what’s great about building, the way that we built is basically get comes out of the box. Like there’s a good integration in code builder, because code builder is built on top of Microsoft Visual Studio Code spaces, which comes with get pre configured. And so if you are connected to your repository, which should be relatively straightforward, you can do anything you want in the way that you want to manage your source. So you can connect to a repo that your team is already using, and you can use that source and push that source into your scratch org, you can know that you’ve kept your source and I don’t know a lot of teams do this. They keep their source in line with either production or their like pre production sandbox and so on. make changes and a copy of, you know, developer sandboxes, a copy of that pre production sandbox. And then when you move those in, get knows that you’ve made changes. And the file names are similar and are the same, and you can move things around. But we have good integration out of the box, it’ll work really easily. And you just have to choose how you want to use version control in this space.

10:21

Josh: So code builders not being prescriptive of you, you must use get as your source of truth, but that handles itself as a centerpiece between all these potential touch points.

10:31

Claire: Absolutely. So for teams that aren’t there yet, we highly recommend using a version control system, right. But if you’re not there yet, you can still use code builder and the way that a lot of teams use it today where they have a sandbox, that’s their development sandbox. And then they’re authenticated into, you know, a full copy sandbox where they sort of have their pre prod environment, they can push their changes using the deploy commands or using that org browser. You know, they just talk about Between the orgs that they’re connected to, because they can authorize what’s what is not available in, say, a dev console, because it is specific to that org, which is available and code builder is you can be authenticated into multiple orgs. At the same time. Now you, you choose what org you’re working against. When you’re done working at that specific org, you can move your changes into another one.

11:20

Josh: Well, in speaking of something very similar in that vein, also through the power of podcasting time travel, in a couple of days, from when we’re recording this, we’re going to announce something called DevOps center. And by the time this is released, everybody hopefully will have heard of it. But how does how does DevOps center which does a lot of what you’re talking about? How does that kind of interplay with code builder?

11:41

Absolutely. So I think that So, Karen Fidelak, and I have worked really, really closely over the last couple of years and in fact, I did a ton of research on release management last summer that fed into a lot of the work that she’s been doing, which has been absolutely awesome and I’m super excited about release management is a passion A project of mine coming from Bitbucket and thinking about like, hey, how does somebody who knows nothing about DevOps make this happen? How does an admin who’s used to change that become part of this modern DevOps flow? Yeah. And that’s really where they went first is how do we include somebody who is not going to use VS code and isn’t familiar with GitHub? How do we get them into the mix? So code builder and DevOps center right now, sort of can act in very similar ways. So somebody because of the get integration within code builder, you probably don’t need to go to DevOps center all the time data center is, you know, it remembers the changes and it can see them so you could use that as your intermediate you can be making your changes in code builder, move those into your org, use DevOps center to then ultimately get those into your version control system or if you are tracking their changes or remembering what you’ve changed. In code builder, you can move those directly into your version control system. But what you get with DevOps center and with code builder is the ability for anybody on the team, no matter their level of expertise in release management to be come part of that release management process, and get them into the version trust system. Now longer term, code builder and DevOps center will be integrated, and they will work more harmoniously together. But really, what we’re doing right now is trying our darndest to give everybody the ability to use a version control system.

13:36

Josh: Gotcha.

And I mean, code builders more focused on those roles that you were talking about earlier, like the people who you know, maybe they just need that one line of SOQL, or they’re going to update a trigger. They’re going to open up the box and kind of fiddle with things a little bit. But yeah, but both of them it seems like at least, you know, the best practice solution. We’re giving that to you as an opportunity. And go please use the source repo.

14:00

Claire: Please, please, please do. It’s It’s a wonderful thing that will forever make you less stressed about making changes to your org.

14:09

Josh: Yes, yes, absolutely. Okay, so we’ve we’ve mentioned it a couple of times offhandedly, and I just actually kinda want to throw this in here for prosperity because or posterity because there’s this anecdote that I have given on the road. So many times, it’s so many workshops. And it’s pointing to the URL for Developer Console, and the URL for Developer Console ends in Apex CSI. And not a lot of people know this, this that’s an in joke to the CSI the currency investigation TV show, because the whole goal of Developer Console when they first put it together was to figure out who had murdered her code. And so I think people don’t realize how much functionality has been layered into dev console like over the years to kind of try to make it seem more like an online IDE. And now we’ve kind of reset. And we’re actually using an online ID to be an online ID, which is, I think, a brilliant strategy. How do you see where, you know, with Developer Console kind of hit a certain point? And we’ve sort of moved on with it. But how do you see what’s in Developer Console? Now? What’s the future of console? And how does dev console potentially impact your roadmap down the road?

15:23

Claire: Absolutely, I think you’re, you’re asking the question that everybody has. So we want to build tools that have everything that you need. So right now, in order to get some for some people to get their jobs done, they have to use dev console, they have to use workbench, maybe there’s, they’re doing Lw C. So they also have to use our extensions to Visual Studio code. And they’re using a ton of tools, and it’s overwhelming, and there’s too many places to go, ultimately, long term. Our vision is unification of those developer tools. So you’ll have a web based tool and a desk based tool, both of those tools will do the exact same sets of things. So they’ll have the full feature set of everything. So right now VS code has a set of things that you can’t do. And then you say workbench has a soql Query Builder. Well, you can’t do that. In VS code. We don’t want this anymore. We want developers to be able to do what they want, where they want, which is a slogan that our marketing person came up with. But it’s true. That’s really what we’re, we’re, we’re trying to get to. And so developer console is probably one of the first of its kind really like, it’s actually like, four when it came out, or a pretty powerful thing for Salesforce to have launched. Or you could do these editing. And it’s more than just a text editor. Yeah, but it’s showing its age, a little bit or a lot. And there’s some power that you need now from an editor, and code builder, because of code spaces is backed by a virtual machine and There’s more that you can do there. And right now developer console is going to continue on while we work through making sure that there is complete parity between developer console and code builder. And the same goes for what we’re doing with workbench. One of the things we announced at TDX or we’ll announce because time travel is our new SOQL Query Builder that we’re currently working on. And that will do everything that the query builder in workbench does today. And more it will facilitate the building by, you know, the UI of your socko queries. It’ll also let you toggle between, you know, that query, it lets you do smart and can, you know, you can search for all of your different custom fields and so on and we’re, we’re really taking a step back and looking at what the query builder and workbench was and building something That is consistent. So dev console, In a similar vein, we want code builder to do, everything dev console can do and more. And in fact, in a lot of ways, it mostly does that. There are some things that will, you know, we have to dig into, and we’ll port over to the extensions. But what’s great is that soql Query Builder that we’re building, that’ll be available in the web and on desktop. So today, I talked to a lot of customers, and they’re like, Oh, yeah, I love VS code. But I always use workbench to write my socko queries, because I can start from the UI. And it’s like, well, why do you need to use this other tool? That’s crazy, right? So even like, so we want to have one unified set of tooling. And that’s available where you want it. So if you’re always in the web, great, if you’re pro Pro, Dev, and you want to use VS code, or you just love you VS code, and you want it on your desktop, awesome if you want to use VS code at work, but then you are at home and you want to log into your org and just quickly spin up a workspace You can do that too. And you can toggle in between, which is very cool. But I would say dev console is not currently going away. But the long term strategy is, we want to bring you all the goodness, the dev console has, along with all the goodness that’s already available and code builder, the stuff that’s in workbench, other things that maybe are missing, and make sure that that’s all unified. So that code builder and desktop VS code have everything you need to get your job done. And then maybe you never need to open dev console again.

19:33

Josh: Yes. And I always find it interesting that so many people who have worked with Salesforce over the years, like their first question is like, does this mean Visualforce is going to be obsolete? Does this mean you’re going to get rid of dev console or you’re going to remove the links? Are they still gonna have access and and I remember when we were doing the lightning launch is that and I really wish I could remember which pm told me this, but basically, they’re like, would I ever get rid of visual force? Sure. If I could run a report that prove that there were zero users of visual force that there was no existing code base that nobody was touching a Visualforce page, and even then I would probably wait three months before I did it.

20:12

Claire: Yeah, I mean, we, we strive to give you the tools you need to get your work done, not to take away the tools, you’re already doing your job, right. I think we we want to unify those, and I’m not full disclosure, Dev console, and you’ve probably already noticed, isn’t gonna get a facelift. We’re not working on it. We haven’t worked on it. We’re working on code builder. We’re working on our extensions to Visual Studio code. And we’re going to try to make them consistent. Yeah. So that one day you’re going to go, why would I use a dev console. Great builder gives me everything I need and more. And what’s even better about that is I’m able to collaborate with my team, which I cannot do from dev console.

20:56

Josh: Right well and to go back to the point you made earlier. You know, Dev console is effectively a lot of JavaScript, you know, layered on top of each other. And Code Builder is a virtualized machine. I mean, that’s, that’s distinctly different technology that is much different capabilities.

21:14

Claire: Exactly. And, and it’s powerful. And the thing about code builder that I want to stress is, you’re going to be given a ton of power using code builder. But we also want to make sure that it is built for anyone and everyone to use and that the first time you use it, it is as exciting as the next time and it’s not scary. It’s not daunting. It is another tool in your tool belt. And ultimately, hopefully, it’s one of the only tools in your tool belt. So you don’t have to go and use like a million different things. Like we talked, I did user interviews a couple months ago, leading up to actually the soql Query Builder and how we were going to design that. And I was astonished at the tool like people are you the amount of Chrome extensions People use just for org management. Yes, yeah, is baffling. And one of the things you know about our vs. Code extensions, and now in code builder, is you have org management sort of built in. And it’s easy to toggle and stuff. But I was fascinated by the amount of Chrome extensions just used for that specific thing. Yeah. And then they would have seven or eight other Chrome extensions that were they were doing to do different things. And they were using workbench and dev console. I’m like, this is like, I met a guy who has three monitors, and one of his monitors is always open to Salesforce documentation. And he has to toggle between all of those things. And I felt for this and he was so great as an interviewee, and he gave us so much wonderful stuff, but I want to make his life easier. Right,

22:49

Josh: right. Okay, so currently Code Builder is in pilot. What does that mean? And like who’s getting access to it right now?

22:58

Claire: Yeah, absolutely. So Code Builder is in a pretty small pilot actually. And we have opened it up your AE or you know your your support person can nominate you to be a member of the pilot, we’re going to monitor the pilot over time understand how it’s growing, how people are using it. And I actually do the review of all of those people. So the pilots open right now I’m trying not to just instantly let everybody in because I’m excited product manager I just I’m trying to wait to onboard slowly so that people who haven’t heard about code builder yet have an opportunity. And so we’re going to unboard people over the course of July into the pilot and monitor how they’re using it and get a lot of feedback. And what we really want to do is build a product that is really ready for the next group of people which would be beta. We’re really hoping that we have have the ability to do a big open beta at Dreamforce. This year is in November, as far as I know…

24:08

Josh: as of this recording, that is still what we think is true…

24:11

Claire: exactly. But we’re using the pilot as an opportunity to really get a ton of feedback about what that initial experience is. So that when you go and you tell, say you’re a pro Dev, and you tell the person on your team who really only writes a little bit of SOQL, and maybe edits a trigger here or there, hey, use this new tool. You don’t want the first time that they use this new tool to be like, what is this? Why did you tell me to us? This is terrifying, right? We want to give you something that’s really easy to use right out of the box. And so that’s where we want to go with and that has a lot to do with onboarding and getting you set up and getting you to get that quick win right away. And so that’s where we’re going with beta beta is, you know, forward looking statements is dreaming. For, and again, Safe Harbor, we’re hoping that that will be open to anyone and everyone

25:05

Josh: Well since we’ve invoked the Safe Harbor and the forward looking statement, are there any other features that you’re hoping to get into by Dreamforce?

25:12

Claire: One of the big things I really want to do is embed our documentation directly into code builder.

25:18

Josh: So going back to that one guy,

25:20

Claire: yeah, I well that one guy I want to be I want you to not have a million tabs open I want you to be able to you know, you’ve got the intelligence of being able to get in line help about your you know, Lw c tag and this stuff, but what if you don’t really know how to build an MVC component? What is that guidance was just right there and code builder. What if we embed some trails make it easier so I for me, that’s, that’s a big thing. I think you have to go to a lot of places to get your stuff done. Get What You Want to get done. Done. Yeah. And I think it would go a long way to have all of the documentation at your fingertips.

25:58

Josh: And that’s our show, but before We go, let’s talk a little bit about Claire’s non technical hobby, which, in these interesting times that we’re in, it’s a little complicated.

26:06

Claire: I do I partner dance style called New Style hustle.

26:11

Josh: Really?

26:12

Claire: Yeah. So that’s probably my favorite hobby. It’s hard right now, due to social distancing. I mean, my partner and I, we do it a little bit in our backyard will will dance. But they can’t go to dance classes right now. Right. We discovered this about two years ago, and it is absolutely amazing. I think anybody can pick it up. It is a wonderful way to learn to dance. We’ve been dancing for years but new style hustle, that’s my favorite. I can’t do that right now. So right now I would say it is slowly washing watching my tomatoes grow and keeping track of my sourdough starter, which Yes, I did start during shelter in place.

26:54

Josh: I want to thank Claire for the great conversation and information on code builder which we are looking forward to seeing a lot A lot more of on the road to dreamforce. Thank you for listening. And if you want to learn more about this show, head on over to developer.salesforce.com slash podcast where you can hear old episodes, see the show notes and 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.