And how does it look like to push something else to production? Something that's interesting that I haven't seen at my past jobs that we started doing recently for all of our unit tests and all of our interaction tests We run the full suite with all the flack.
off and then with all the flags on so the same tests are like running in both and like obviously like within the tests you can specify a different permutation like if you're writing a test that only covers something that requires that flag obviously you need that flag to be on before we were doing this this was a source of
regressions, right, where it's like, this flag caused this to break, and I didn't know this until, you know, someone went to delete the flag, and then, like, that caused tests to fail. So now that we're doing this... It's pretty awesome. Figma created a new product called Figma Slides in less than a year from idea to launching it in beta in April 2024. Since then, users have created more than 4.5 million slide decks and the product is quickly gaining momentum.
But how was it built? I sat down with two engineers who worked on this project from the start, Jonathan Kaufman and Noah Feiner. In today's conversation, we cover How FigmaSize is built using TypeScript React and a lot of C++ code. By building a seemingly simple UI, the single slide view is a lot more complicated than it seems.
Engineering approaches at Figma including the ng-crit process, using a feature flags, and running all unit tests twice, once with all the feature flags turned off, and then once with all turned on. And a lot more. If you're interested in a behind-the-scenes look of how the engineering team at Figma does things differently, sometimes by choice, sometimes by necessity, then this episode is for you. If you enjoy the show, please subscribe to the podcast on any podcast platform and on YouTube.
John and Noah, it's great to have you on the podcast. Yeah, happy to be here. Also excited to be here. So how did you start building? What kind of tech stack did you use back then? Did you just have a few scratches? It sounds like a really exciting part of the project, right? It actually can make or break a project. So everything about the slide grid and... And those things were built just sort of on a brand.
And we kind of Hack Week style where we wouldn't have merged this to our main branch yet. Would you mind just sharing how Fibosize looks and what the parts are that you're talking about? For example, the slide deck and the grid. So this is Figma slides. When you enter slides, you're presented with what we refer to as single slide view. And this is what people are very familiar with seeing in Google Slides and PowerPoint and Keynote that you have.
this carousel on the left, and you can go through the slides. But what we noticed is that when designers were building slides within Figma Design, they would always lay everything out. using our infinite canvas. So this is what we refer to as grid view. There were a bunch of annoyances.
building a deck like this in figma design and part of it is you know if you have all these top level frames on a canvas if you want to reorder them they don't just like reorder right yeah so one of the first things that we built was like exploring how how can we give better um reorder behaviors for people who want to build slides and like see slides in this way, right? So, you know, as you drag things around, they reorder, you can reorder a whole row.
And what was interesting is if you go back to single slide view, those rows correspond to the sections here. So each of these sections are the rows. in in in grid view and so it's this nice one-to-one relationship and so what this allows just a question like so what about the columns like is that
Yeah, yeah. So if, see how this is, this Brendan slide is the second slide. If I make that third and then go back to grid, you'll see that this is now in this position. Got it, got it. If I reorder this whole row. and then go back to single slide view, that whole row is now second, right? And so what this allows is... People who are more familiar and comfortable with the infinite canvas, they can live in grid mode where they're happy, but people who may be less familiar or don't want.
That view, they can stay in this view on the same file. This episode was brought to you by Graphite, the developer productivity platform that helps developers create, review, and merge smaller code changes, stay unblocked, and ship faster. Code review is a huge time sink for engineering teams. Most developers spend about a day per week or more reviewing code or blocked waiting for a review.
It doesn't have to be this way. Graphite brings stack pull requests, the workflow at the heart of the best-in-class internal code review tools at companies like Meta and Google, to every software company on GitHub. Graphite also leverages high-signal, codebase-aware AI to give developers immediate actionable feedback on their poll requests, allowing teams to cut down on review sites. Tens of thousands of developers at top companies like Asana, Ramp, Tectone and Vercel rely on Graphite every day.
Start stacking with Graphite today for free and reduce your time to merge from days to hours. Get started at gt.dev slash pragmatic. That is g for graphite, t for technology dot dev slash pragmatic. This episode is brought to you by Sonar, the creators of SonarCube Server, Cloud ID, and Community Build.
Sonar will now offer SonarCube Advanced Security, delivering the first fully integrated solution for developers to find and fix code quality and code security issues in the development phase of the software development lifecycle. SonarCube Advanced Security enhances Sonar's core security capabilities with software composition analysis and advanced static application security testing.
This enables developers to identify vulnerabilities in third-party dependencies, ensure license compliance, and generate software bill of materials. Sonar analyzes all code, first-party, AI-generated, and third-party open source, resulting in more secure, reliable, and maintainable software. joined over several million developers from organizations like Microsoft, DoD, Barclays, and T-Mobile who use Sonar.
prioritize code security and code quality issues at the beginning of the software development life cycle. Visit sonarsource.com slash pragmatic security to learn more about SonarCube. And then so when you started, you know, it was just a very small team. So one of the first things was coming up with this kind of two-way navigation that would make it unique, right? Because I haven't really seen this, you know, like going from an infinite grid view to...
The single-sided were familiar with, but was this one of the challenges to build a rough prototype up? This became a later challenge. But what's interesting is we actually didn't build single slide view until like six or seven months into the project. for the first while slides was exclusively in the grid view.
And what we built out was like, how are you going to manipulate slides here? What's the template system going to look like? Like when you add a slide, how can we pull from an existing deck? What's the theme system going to be? choosing colors within a theme and then editing the whole theme of a deck. And then lastly, what is the presentation going to be like? Those are the key areas of...
initial exploration, whereas a single slide view, we felt more confident that we could build. And because of that confidence, we didn't want to prototype it too early. We just wanted to focus on the riskier bit. Yeah, actually, I came on around the time that Single Slide View was being built. And I remember the first draft of Single Slide View was like something that John cranked out and like...
Like, I think just a couple days. It was just, like, boxes on the left side. And then if you, like, zoomed into a slide or something, it, like, teleported you into single slide view and just, like, showed the left side. And then if you zoomed out, it went away. And a lot of like when I first got on was like.
prototyping like oh how like how will single slide view work is it are we gonna try to make it like based on how zoomed in or zoomed out you are of the grid or like do we want to have like buttons and keyboard shortcuts and all this other stuff And there was like a lot still to figure out about what is single side view and how do we make it work? And what we kind of landed on is secretly like in this view in single slide view we have like zoomed into the canvas and
Yeah, we've zoomed into the grid. We've hid everything except for just, like, the slide itself. Oh, really? Show some UI on the left and the right. So, yeah, there was a lot of iteration back then to, like, figure out what are we even doing with this. Yeah, it's one of the interesting parts about building on figmas like Infinite Canvas, right, is because we wanted to preserve the grid view.
and allow people to still edit in grid view and have their cursors show up as they're editing if someone's in single slide view. What that means is that the slides are still represented in this two-dimensional space. And so all single slide view is as you toggle through the slides, we just snap the viewport for you. That is clever. And just taking a step back, just to understand how the project roughly went. So you had the early prototyping phase, you then had the...
those one or two months building a proof of concept? And then what were the phases and what parts did you build until we get to a final general availability? Yeah, I think, um, so when it was sort of John and just like one or two other engineers, um, before the team was fully staffed, there's a lot of focus on sort of like the grid view. Um,
And like, how are we going to lay out slides in the grid? Then after the team started getting staffed a little bit more, then there were more explorations around like, how do we lay out things on a slide? And we actually went through a lot of iterations there of like, do we want to do like constrained layouts where
Like users, everything is auto layout and users can like add something to the left, add something to the right and stuff like that. Or do you want to do something a little bit more freeform? We also did a lot of work on single slide view, nailing centering the slide in single slide view versus not. That took months of working with designers and sending over prototypes in order to... like figure out um we also had a big group working on like um
like presenting and presenter view. Speaker notes took a, that was like one of the first things we wanted to add. And also like themes and working. to like create a system of colors that both like come from the template you're using but also allow you to edit on top of it which is like a whole new concept in figma world so um those all sort of happened um coming like up to beta i think like we had like
like, the only way to do, like, an end-to-end flow of, like, using a template and presenting it. I think that took until, like, I don't know if you remember, John, but, like, maybe December, January or so. Yeah, that sounds right. Yeah, and then... Is it 2023? Yes, because we launched in 2024. Yeah, so 2024 January. Yeah, and then it was just a matter of like iterating and it was just like we were cranking through bugs for like two months going up to config and that was
That was wild. I remember we had like 300 or so P0s and so many that we added a new... stage of p0s of like a p0 do this now and then how big was the team in terms of like engineers designers roughly I think at its biggest, we had between 10 and 12 engineers. I want to say two designers. and a dedicated person from research and a dedicated someone from UX writing.
But you don't have any dedicated testers or QA folks, right? Like it's engineers doing the testing and like, you know, you test everything. So you have a dedicated research person though. Tell me about that. Yeah, it was pretty instrumental in finding the direction of slides. A lot of what we explored is very similar to FigJam, where it's like we're building for both a non-designer audience and a designer audience.
So a lot of what we did was like building out prototypes and then putting it in front of both designers and non-designers and seeing. what resonated, and then using that to better form our POV on direction. Yeah, I think one of the coolest tools that we have internally are these front-end commit previews, where if you push up a brand... If you push up or make a pull request, that's automatically deployed and you can send a link to other people internally.
to test that out so a really cool thing we were doing for these user research interviews was like making prototypes and then making prototypes internally with like non-production code And then like shooting those over to research. And then they were chatting with some folks internally and we had them use like the. prototypes. So basically they just create a pull request with whatever data and then whatever was on your machine the researchers could show, right? Yeah.
Nice. And what is the tech stack behind all of this, behind Figma Slides? Yeah, so Slides is the same stack as Figma Design and FigJam. So everything that's in the Canva... is rendered using what we refer to as fullscreen, which is RC++ codebase and renderer. And then what that does is it writes to a literal canvas element in the DOM. using either WebGL or WebGPU, depending on browser support. So that's like a lot of our main stack that we work in when building out the UI is in C++.
everything that's on top of uh the canvas so like this left panel, the properties panel, this tool belt, all the file menus. These are all in TypeScript and React. And then we have our own bindings layer that allows us to share state between what's in C++ and what's in Web. So, you know, like I think reactions is pretty straightforward, but do you also need to go into C++ to do some kind of UI changes or create new, like, more elements, those kind of things?
All of the teams that work on our editors are either 50-50 or going to be more C++. That's not a conventional UI technology. Did you pick up C++ on the go after you joined Figma or did you do it before? There are some people who come in as C++ experts, and then there's other people who come in as more web experts. I'm one of the people who did not know C++ before starting here.
I also did not know C++ before. Well, I worked with C++ a lot in college for operating systems or all these other things. how you'd use C++ for a college project or other things is very different from how we use it at Figma. I feel like Figma's almost designed like a game engine, almost. But the Figma codebase is just like...
It takes some time to learn how to navigate it and how to find things around it and how to develop for it. So I think there's a learning curve for everybody, but it's a very approachable learning curve. But a really cool thing Figma is doing is they're trying to rewrite parts of the full screen C++. codebase to actually be in TypeScript. So it's like TypeScript chatting with RC++ codebase. Yeah, with this bindings layer, which is really cool.
One example of those is all the little blue lines. If I'm hanging out in grid view, all of these plus buttons and these guys are rendered on the canvas. They're using, they're written in TypeScript. And then that TypeScript is, like, interacting with the canvas, which is, of course, being rendered by, like, TypeScript and React.
And then one interesting thing that you previously mentioned is that Figma has this pretty cool tool, C++ WebAssembly Editor, to help debug TypeScript as you're building it. What is this tool? And this sounds very, very unique to Figma. It's sweet. We have this, um, there's this Chrome extension called, like, dwarf losm debugging, um, that, like, we've installed, and, um, What's really crazy is you can debug C++ inside of Chrome itself, inside of the inspector panel.
And like sometimes if I have to like figure out a gnarly, like a gnarly bug between like.
our carousel, which is written in TypeScript, and how that's chatting with the editor, which is written inside of C++. I can debug both our WebAssembly bundle as well as... react at like the same time which is really cool like being able to set breakpoints between the two and this is like custom tooling obviously that that you built right because no no this is um it's open it's like a part of chromium Oh, so Chromium supports debugging like custom C++ WebAssembly libraries.
Yeah, yeah. The, like, mental model is very similar to, like, if you're using compiled or transpiled JavaScript and source maps. It's... the like analogous mental model you can make a special web assembly it's maybe underwhelming to show which is i think what makes it really cool um so here i just have like You'll notice I have like a TypeScript file next to a C++ file. Oh. Right.
Okay, and then obviously you need to have a debug build for this to work, right? Yeah, yeah. So there's a special type of build that you can build that generates dwarf symbols. And then... The Chrome extension can consume those symbols and map it to source files on your computer. That is so cool. Yeah, and things like breakpoints work. Not 100% of things work, but you can inspect different objects and read values of primitive things for sure.
I mean, I worked with, like, back a very long time ago when I worked on Skype for Xbox One, we added HTML and JavaScript for whatever reason and C++. There was a C++ bridge. And it was the only way we could debug the C++ code is send it over to JavaScript, dude, debug, log, send. What I would have not given to have this tooling. Yeah, it's super cool, yeah. I think before this was supported, it was before I joined Figma, so this has been around for a few years at least. People would build...
We have a... build that you can run within Xcode that launches Figma, and then you can use Xcode to debug the C++. But now I think most engineers here are using this. Yeah, I think it just comes to show that even when you have a more unique tech stack, it's pretty cool how some of these things are standards and they exist. You just need to find them. Because as you said, I kind of assumed that you must have built it yourself. But no, it's... It's a universal Chrome.
Yeah, one really cool example of how I use the debugger was there was one time where we had this variable that was getting set inside of our web code base. a configuration variable between like, are you in UI2 or are you in UI3? we were seeing this really weird bug where you were both in like the carousel and the grid at the same time. And we were like, well, what's going on? Why can't we repro this?
And after a good bit of investigation, and using this debugger very specifically to see when some initialization code that set you in the editor to be in grid view or single slide view. I put a breakpoint there, and then I put a breakpoint on this code that was like, are you in UI2 or are you in UI3, which is being set in web. I was able to see we were having like a crazy race condition going on.
Wow. And the only way I could have done that was with this WASN debugger. Yeah, because now you can debug the two code bases running parallel pretty much. That's awesome. And so what were some unique challenges of building Figma slides compared to things that you don't really come across on other projects? I'm assuming you built a bunch of web projects.
kind of usual suspects from like UI layouts to like build, like how are we going to build or what linting are we going to use? But this didn't seem like, it sounds like it's not your typical project. Yeah, I think one of the main challenges really was something that we've already touched upon, which was how we built single slide view to be literally just moving the viewport, right? If you were to build a slides product from scratch,
I don't think that's the way that you would approach it, right? Where you're like, okay, well, what if we had an infinite canvas and slides had XY coordinates on the canvas? And then we can like zoom in, you know? So that was like a unique set of challenges. But what's really cool, not only that, it works, but that it allows all of our existing
tooling around like multiplayer cursors and things like that to kind of just work, right? And what is multiplayer cursor for those not familiar with, you know, Figma Lingo? So multiplayer cursors are when someone else is editing the same thing. You can see exactly what they are editing, right? So if Noah makes a selection, we can see that Noah has that node selected. And this works regardless of if I'm in single slide view or if I'm in grid view, right? And then behind the scenes, like...
How does multiplayer work? There must be some sort of TCP connection open and it must be talking to a server. Is it happening on a server or is it peer-to-peer? It is happening on a server here. This is how I can do my best to answer it. Our co-founder, Evan, wrote a great blog post on the Figma engineering blog about multiplayer. And definitely much more of a subject matter expert than I am. But at a top level, we have a Rust service running that like...
All edits propagate through, and it handles conflict resolution and sends things back down. Each client maintains a WebSocket connection with it. And basically it's in this library, right? So as long as you use a C++ library, It's built in. So I guess, was this one of the reasons you decided to like, all right, let's, you know, hack around it, like zoom in, keep using it? A lot of it's multiplayer, but I think more broadly, a lot of it's just building on the Figma platform.
You can copy anything from Figma design and paste it into slides and it'll just work. And same with going the other way. Right. And that is really important to us. as we're building these new products, right? Like copy paste works between fig jam and design. It works between design and slide. And so now there's this nice, it doesn't matter which editor you start in, you have access to the same things that you created in any of the other files.
And that's sort of like a second area of complication is like we call this interoperate. But what that means is that, you know, like FigJam has a bunch of node types that were made specific to FigJam, like stickies, for example. But because we want Interop to feel so seamless, what this means is that if you add a new node type to a specific editor, it has to work everywhere, right? Like it would be a little bit of a bummer if you went to copy a sticky. And it didn't, you know?
And so this ability to bring things between products is really cool for our users, right? But it definitely adds complexity to the code.
And as a dev, what does this mean for you to support Tiki? I'm assuming there must be some data type somewhere of all the things supported, and then you need to figure out how to visualize it or how to draw it or how to... like how it maps like how can we imagine because I feel this is like interop is something that most of us don't need to worry about until you do yeah there's something like
There's like an irony. I feel like as, as other companies become multi-product companies, you like kind of do your best to like separate the products more, you know? But what we really lean into is the opposite, right? So like with each new product, we like really want things to be seamless, you know? as far as what the code looks like. A lot of what's in the full screen code base, which is our C++ code base, is the same code running regardless of which editor that you're in.
A lot of the differences are in the website, right? So, like, we have a different React tree for each editor, and that's how things are very visually different. but the code running what powers that main canvas is the same WASM bundle for each of the editors. Then, of course, you know, there are differences. And so differences are sometimes expressed in a concept that we call mouse behaviors. And so mouse behaviors are...
You know, it's sometimes hard not to use the word in a definition. They're the behaviors that run for the mouse, right?
So, like, I'm dragging what happens, right? And so a lot of what happens in Big Jam, right, or we like to snap things to different... pixel grid so that things like lock in more worse design is more freeform right so for things like that we can check which editor that you're in and like uh respond accordingly Yeah, one example of like a different mouse behavior that we have, like inside of Figma design, if I were to like try to drag some like things inside of an auto layout container.
We have like this behavior over here where like they'll shuffle around in real time. But if I were to jump into a slides file, let me go share my slides tab. We have our own sort of unique behavior for handling this drag. We have our little previews over here. We have the ability to add new rows down here. All of this is done via our own slide-specific mouse behavior. So each editor type can register a unique set of mouse behaviors is how a lot of differences are expressed.
This is very interesting, and it sounds just very unique to Figma. But I guess, you know, like, if we're to peek in the internals of, like... any company that has like a big product that has evolved of obviously something. might see something similar, but this is just fascinating on how things become really kind of unique for a good reason and homegrown. This goes back to like Noah mentioned that, um,
A lot of the Figma code looks like a game engine. I think that this mouse behavior concept is taken from how a lot of game engines run. So there's a priority list of mass behaviors if one of them accepts the event. It doesn't go to the next one, you know? So it's like our own sort of like delegation pattern that often... the browser would handle for you, but because we're running in C++, it's all written from scratch.
You do have a bit more freedom. I just had a... I was just recently talking with my brother, the founder of Crap Docs, who decided to build their own UI not using the system UI and I mean it's a lot more work but then you get a bunch of freedom to do whatever you want to do in terms of animation and what the system might not be able to do or the system elements might limit you.
Yeah, yeah, yeah, for sure. It's one of those like with great power comes great responsibility thing. Because like something that we do, right, is like we render. text ourselves right so we have code that like looks at the font and it like computes the geometry of the glyphs and then based on that geometry renders out the pixels you know And this is great because it guarantees that regardless of what browser you're using, what OS you're using,
If you're looking at a Figma file, we can guarantee that it'll look the same, which is very important when you're making a design tool, right? But that means that there's a lot that we don't get for free, right? We built and launched... I think last year or the year before, spellcheck, right? Just like the red squiggly.
That tells you that, you know, something is misspelled. And that was like a huge undertaking, you know, or like we, we, we added support for bi-directional fonts and that was all like, like we had to add it, you know, cause we couldn't lean on the browser. Hey developers, we've all been there. It's 3am and your phone blares, jolting you away.
Another alert. You scramble to troubleshoot, but the complexity of your microservices environment makes it nearly impossible to pinpoint the problem quickly. That's why Chronosphere is on a mission to help you take back control with Differential Diagnosis, a newly distributed tracing feature that takes the guesswork out of troubleshooting.
With just one click, DDX automatically analyzes all spans and dimensions related to a service, pinpointing the most likely cause of the issue. Don't let troubleshooting drag you into the early hours of the morning. Just DDX it and resolve issues fa- See why Chronosphere was named the leader in the 2024 Quadrant Magic Quadrant for observability platforms at chronosphere.io slash pragmatic. That is chronosphere.io slash pragmatic.
It is interesting because now I remember, you know, like just one everyday thing that people might come across is just a PDF file. When you open it, it's for editing with anything, really. And then you need to have your fonts. And those phones need to be until that they always shuffle. And if they're not, you know, you're out of luck and it'll look something weirdly different. Trade-offs everywhere. Yeah, yeah, yeah. Yeah, for sure. And what other type of things were tricky about this project?
Yeah, I could chat a little bit about how Single Slide View had some really interesting challenges. Oh, I'd love that. Because this is something I don't think most people would assume. Yeah. How hard could it be? It's just And actually, you said earlier, right, that, oh, we knew this would be pretty simple. That's why we left it for later. Yeah, my simple, it's very relative. Yeah. But yeah, like single slide views in this really interesting spot where
like a collapsed state, like collapsing slides and expanding them. We don't want to save that to your file at all. We'd want to save stuff like the order of slides in the grid to the file, but we don't want to save stuff like, are these collapsed or not to the file? In order to render this carousel over here, we've got a bunch of state that lives inside of web.
and then a bunch of state that lives inside of the editor, inside of fullscreen. And we got to have a bunch of complicated code to sort of coalesce those in order to figure out what to render here. On top of that, there's a ton of crazy technical challenges to solve in terms of dragging slides around. and making sure that if I were to drag these three slides,
which right now they're their own row in the slide grid. If I want to drag this slide out and then move it into this row, We got to make sure, like, This row is still preserved up there. But if I were to drag this entire row and like make it sort of a child, we got to like delete that first row and then like combine this row together. So there's a lot of like really interesting algorithm stuff to like coalesce like sort of changes from the carousel.
inside of web, as well as other users dragging stuff around inside of full screen, maybe across multiple rows or something, and combine those two together in a way that feels safe for multiplayer. Yeah, yeah, yeah. This is a good thing to like, yeah. So this intersection of editing and multiplayer is a really interesting part of the Figma stack. Everything is multiplayer first.
For things to be local, you have to opt out of it being sent. But what's interesting about reordering stuff in single slide view... There's a bunch of operations that you can do that can move a lot of slides at once. but because we want it to be multiplayer friendly. There's a lot of work behind the scene, under the hood, that's happening to perform the minimum number of mutations possible. Because the more mutations that you do...
the less multiplayer-friendly something is, right? Yeah, the more likelihood is to load. Yeah, if you're picturing the slide grid, right? And if we move the bottom road to the top... In a naive way, when you do that mutation, you're changing every single slide's XY coordinate, right? Well, that's the most obvious thing to do, right? Yeah, and that's how slides worked for a while. But then...
How we ended up solving this is our ethos was to do the minimum number of mutations, right? Ideally, the number of mutations are the number of slides that you drag. And the way that we achieve this under the hood is actually using the auto layout nodes within Figma design. So what I mean by that is each row is in its own node. We call it the slide row node. And then each of those nodes is within a slide grid node. So each slide is now two levels deep.
We have an existing construct called parent index, which was made for reordering stuff within frames and reordering stuff within auto layout. What a parent index is, is it's a struct that has a reference to the parent's ID. as well as an index represented as a float from 0 to 1. And so by doing it this way, if you reorder just one thing for example, You only have one mutation, right? So I change something from the beginning to the end. Only that thing's parent index has to change.
and then each client is responsible for recomputing the layout. Just to move things around. Just so I understand that the goal is that you send the mutation to the server saying, here's what changed, and then that server sends it to all the clients, and then all the clients execute it as well.
Yeah. Okay. You know, there's like probably low risk that everyone's going to be mass reordering slides at the same time. Yeah. But there is a higher risk of like, you know, people lose internet connection. And so what we do is like if you're offline and you do a bunch of edits, then when you come back online, there's like a lot of resolution that needs to happen. So doing this minimum number of mutations is like...
is the goal. So everything's two levels deep. They're all using parent index. And then We wrote code that I imagine looks kind of similar to the React reconciler, where we're like, okay, we have the beginning state of the drag, and we have the end state of the drag. What's the minimum number? of mutations to get from A to B. And that's what we propagate. I remember before we had all these optimizations to figure out the minimum number of things to recompute.
It was pretty gnarly. I remember there was a big all-hands that was happening internally, and then we just got a report that, like, hey, a bunch of slides disappeared or something.
and then we were like oh my goodness chaos mode um so we had to do a lot of digging to sort of figure out theories as to how this might have happened because like it's really hard to reproduce like 10 people being in the same file at once and then one of them losing connection while they do like a big like side reorder so I mean this sounds like a proper you know like hardcore engineering problem where it's like distributed systems like state
reconciliation, playback, conflicts. While we were working on this, we often joked like, this would be a really mean interview question. Or a really good one if someone can bring something to the table. It's like, all right, you need to join. And how do you test all this? So, like, I'm specifically curious of, like, okay, you know, like, in traditional, like, CRUD apps,
You typically have, obviously, you manually test that as it works. You add your automated tests, unit tests later, you might add integration tests, and then they're there to guard against regressions. And now, you know, like it's, and then you feel pretty happy. Thumbs up, it'll kind of work, especially when it's like a backend heavy thing that doesn't have much UI. How does it work in your case? Yeah, we have all of those. For this case specifically, we do have...
I think it's our most unit tested part of slides, this like grid reconciliation. And we have every case that has ever caused. a bug report, um, that we then assert that mutations that have happened. So we like to reorder and then we verify on like every single slide after the reorder. Are you the same? Has your index changed?
I think another interesting part of slides is some of our test cases are like vibes in a way. To dig into this a little bit, especially when we were originally building the product and still like today, we do a lot of like... testing by like seeing how people feel about a subtle change. I remember one of the really interesting things I was iterating on was like, how does the viewport like feel inside of like single side view? And it's like, how far can you zoom out?
how far can you zoom in um as you zoom out when you can see that the slide gets centered but like when do you start re-centering the slide how far like the margins here and here And to do a lot of this testing, and you can see it also scales with the viewport, but to do a lot of this testing, this was a lot of like... Sending two options over to designers or putting one option in our internal staging environment. And then seeing how people felt about it as they naturally use slides.
during their day-to-day in Figma. so a lot of like um trying like things out trying like one or two different options and then like getting some feedback on those prototypes from designers or product people around the company, and then going for just like whichever one people either preferred or like whichever one. people did not like less than the other one. Yeah, that was different, right? Apart from your usual development.
Yeah, for sure. Something that, like, I really love about working at Figma is just, like, how much we use the products that we make, right? Like, we, like, really live in them. And that really translates to a lot of the deep power user flows that end up in the product are because people want them. And it also translates to an amount of... care, I think, right? Like, people notice tiny bugs.
And they fix them because like they're bothered by it or like people will notice like a string inconsistency and they'll like put up a change to resolve it. And so like all these like little minute things that may otherwise. go unreported by users are like always reported internally in a really nice way so i
We did a deep dive about Figma with actually Chris Rasmussen, the CTO about a year ago and the pragmatic engineer. And one thing that he told me there is, There's this concept of Figma of fixing They're having a zero-buck policy, especially for new development. So when something is launched for a certain amount of time, if it's a bug, you fix it.
as opposed to what a lot of companies do as well. You know, there's a report, you kind of put it in the backlog, eventually you might or might not fix it. Do you still do this? And if so, how are you doing this with Slice, which is a new product that's still not ready or, well, it's just ready? Yeah, I definitely resonate with that. Our on-call shifts work differently than in my past jobs, where when you're on-call, a lot of what you do is you triage that main feedback channel.
If something's like a quick fix that someone reported, you can just put the fix up right away. But if not, you go through the act of them prioritizing those things. So we do make sure that everything that's reported internally is either than like, fixed or planned to be fixed. Yeah, I will say being in beta did allow a load of leeway with bugs to make sure that we had a really solid set of an end-to-end flow ahead of the config launch.
One thing I really did respect about Figma is when it came to crunch time, we were really good about... prioritization instead of like adding more hours onto everyone's workflow. So I think we were, Figma was really good about like making sure that we had like We were able to figure out the true blockers that would make beta less successful versus stuff that we could happen in beta that we would want to fix ahead of our bigger... And how does it look like to...
push something out to production, like you fix a bug or you add a new feature? Do you literally just push it out and it goes out to every single customer? Do you have feature? Well, obviously, I'm assuming you'll have code review, CI. You're just nodding, but not every place has it.
But I'm going to assume, correct me if I'm wrong, and then when it goes out, do you have a concept of feature flags? I assume you must have it, but for the most part, does it just go out to everyone and then boom, it's there? Is there a little bit more kind of careful release process? I think the answer depends on like what the bug is and then like the risk of the bug or even just the area, right? I think...
So anything that's going to be touching the core experience of the core editor, if that's a risky bug fix, always gets a flag. And we tend to roll those out slowly and watch for... reports or like any any like bug fixes in our renderer too right just like these like really core areas always always get a flag and part of that is like you know we're making this thing that people
live in for eight hours a day, you know, like people do their full time jobs in Figma. And so we tend to, you know, prioritize not being. Yeah. In terms of feature flags, yep, we have feature flags. Yeah, last I checked, we have over 2,000, I think. Okay, okay. Then you must have an internal panel for devs to be able to trigger on your local thing, right? Yeah.
But yeah, but in terms of feature flags, since we have our staging environment where we have people like dog feeding stuff all the time, we have a lot of feature flags of the bigger features we're working on. such as some of the ones we're launching for GA, such as slide numbers or components or object animations. We have those on internally in our staging environment. And we get a lot of really good feedback on bugs and just general usability.
by just having those on within staging. And I think that really helps make us feel a lot more confident of when we eventually flip that in prod, just making sure that it feels good. Is staging internal or is it also for a subset of customers who might opt in to get feedback or be on the bleeding edge? Staging Eternals. Yeah, staging is only internal. I think for slides, at least, we had a point where slides was staging only.
internal only. And then I think it was like March 2024 or so where we had our first like alpha launch where we like had a select few customers that we like decided to open the feature flags up to inside of prod who we like worked really heavily with user research um to like figure out so we had uh we had Something that's interesting that I haven't seen at my past jobs that we started doing recently is for all of our unit tests and all of our interaction tests.
We run the full suite with all the flags off and then with all the flags on. So the same tests are like running... And obviously within the test, you can specify a different permutation. If you're writing a test that only covers something that requires that flag, obviously you need that flag to be on. Um, but this has been like a huge, cause I, you know, before we were doing this, this was a source of regressions right where it's like hey you know like this flag caused this
to break. And I didn't know this until, you know, someone went to delete the flag and then like that caused test to fail. Right. So now that we're doing this, it's really, I don't know, it's pretty awesome. I feel like everyone should do this is my takeaway. One really good example is I was debugging a really deep copy-paste bug, and then I wrote some tests for it, and I was like, okay.
Let's make sure slide one is the first slide and then slide two is the second slide. At the same time, John is working on slide numbers and I don't have the slide numbers feature flag on internally. like on my local environment but it's on like in our staging environment so one thing I didn't catch is that like the slide numbers change like renames slides internally from the word slide space one to just like one or two.
And that, like, and, like, yeah, if I just merge that test, it would break under John's feature flag. But because we have this... this system where all flags are off and all flags are on i was able to catch that test before i like merged it in i haven't heard this but i'm gonna make a note because it just like sounds like just like a good practice at a lot of places, because so many places do have feature flags, but this is Smart.
I was going to say getting from where we were to like having this, having this set up did take a bit. Right. So like, Each of our flags have their own configuration to be like, am I enabled always? Am I enabled just for, we call them rollout tests. So it's like... off in the non-rollout test and then on in the rollout test. And so just getting to the point where we could even get a green build in the rollout test was like a huge effort.
And then one last area that I was curious about is this concept called Enchcrest. Now, this is something I've not heard before. I think the practice is somewhat familiar, but can you tell me about it? What is eng crit? And what is even a crit inside of Figma? Yeah, Edgecrits are pretty sweet. We actually run them internally using FigJam, which is yet another one of our products. But yeah, instead of someone sending over a long doc and then people leaving comments in those.
We sometimes do these like... 30-minute eng crits where someone makes a fig jam file and then for 20 minutes like a ton of other engineers around the company like jump in and leave sticky notes and then leave sticky note threads and have all these async conversations. And then at the end, we have sometimes 10 minutes or so to talk about some of the spiciest sticky threads.
I think we have a good engineering blog post about this concept. But for instance, when I was trying to add components into slides, I had a really good eng crit with our design systems team. I made a fig jam. I like showed him a prototype that I made. I like showed some of the code changes that we'd have to do. And then 20 minutes just.
tons of uh tons of sticky notes and like spicy feedback and like sticky note threads and then afterwards we had like 10 minutes of just chatting about like some of the biggest decisions or not so yeah So it's basically like a design review, but very Figma kind of flavored, right? Yeah, I like it because it does lower the stakes a little bit. Sending out a doc can be a little bit scary. Yeah, I remember you want it to be good, well-formatted, nice wording, that kind of stuff.
Actually, one thing that might be cool to talk about is we have this really cool bisect system internally. We call it web bisect and using sort of our front end commit previews where like... any commit or any pull request that's merged into our master branch, we have an image of that deployed. So we have this sweet tool that someone actually made during a maker week where if you see like a bug or something and you don't know where it came from, you can actually use this tool to bisect where.
which commit actually introduced that bug. So you could be like, okay, I saw this bug for the first time last week. And then this internal tool lets you pick, chooses some commit preview right in the middle of that. and then you can like test that preview and you'd be like oh the bug is here or it's not here and then depending on that it like bisects a little bit more And then it could be like...
You can test that again, and it's like, okay, the bug's here, the bug's not here. And then if you do that 10 times, you can nail down which commit. in the last week or so out of thousands of commits, like, caused this regression. And that's, like, extremely useful. So we'll close up with some rapid questions, if that's all right with you guys. And I'll just ask and you just like shoot whatever comes. So what is your favorite language or framework that you really like using?
I gotta go with the classic TypeScript. It's becoming too popular. It is a very good language. I've become a big Next.js fan as far as frameworks go. Oh, nice. What made you... convert. Um, I built my personal site using it just to like test it out and i just thought it was really fun and so since then like uh all my side projects that i do I've been using Next.js. Who knows if we're going to introduce it to work as well now.
Are stacks too complicated? What's a design resource or tool that you use and like? Honestly, the first thing that came to mind is I'm an avid hacker news reader. I don't know if that's like 100% what you meant by like resource, but I love going through like... They're like top voted blog posts there.
Yeah, I think for me, just like flexing my design muscle a little bit, refactoring UI was really cool just to get like rapid fire, quick tips of like, how can I make some like engineering mock or like... weird website that I make them and just look like slightly better. making sure that my pixels are in factors of 4 or 8 pixels, or adding a little bit more white space, or keeping a limited set of fonts. So refactoring UI, is this the book?
Or is this a tool? Yeah, there's a book. It's like a PDF book that's pretty useful. And there's also, like, there's, like, a Twitter thread that I think the author... And this is from the creators of Tailwind Riot. I think so. I think so. Yeah, I just found it. It's from Adam Weth and Steve Schroger. Awesome. And what is a book? What is one or two books, fiction or nonfiction, that you read and would recommend?
I recently read Piranesi, which is, it's like, it's pretty short. It's a really captivating. story and it's one of those books where after you read it you really do think about it for every day you know
Yeah, this one isn't software-related, but I'm reading Kurzgesagt's immune book, which is this really cool, like, book about the immune system being written by, like, a very good science communicator. I think it's just cool to sort of, like... visualize like my immune system and my body in like a whole different way of like this whole collaboration of cells working together. Nice.
Well, John and Noah, thanks a lot for being here and for giving us a behind-the-scenes view of how Slides is built and how some of the simple user interfaces have a lot of complexity behind them. This was really eye-opening for me.
Yeah, thanks for having us. Yeah, thanks so much for having us. Isn't it interesting how a seemingly simple product or UI can be so complex behind the scenes, like the single-side view and Figma slides? Thanks a lot to John and Noah for all these details that they shared with us. You can find both of them on social media as linked in the show notes below.
For a more detailed deep dive about the engineering culture at Figma, check out a longer article in the Pragmatic Engineer titled Inside Figma's Engineering Culture, also linked in the show notes. If you enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. This helps more people discover the podcast. A special thanks if you leave a rating. Thanks, and see you in the next.