# Building Figma Slides with Noah Finer and Jonathan Kaufman

An episode of [The Pragmatic Engineer](https://invisiblenetwork.ai/podcast/1769051199), 26 Mar 2025, 58 min.

Audio: https://api.substack.com/feed/podcast/159718226/7d8bef111214ba8153cd3005757b2de5.mp3

Supported by Our Partners • Graphite — The AI developer productivity platform. • Sonar — Code quality and code security for ALL code. • Chronosphere — The observability platform built for control. — How do you take a new product idea, and turn it into a successful product? Figma Slides started as a hackathon project a year and a half ago – and today it’s a full-on product, with more than 4.5M slide decks created by users. I’m joined by two founding engineers on this project: Jonathan Kaufman and Noah Finer. In our chat, Jonathan and Noah pull back the curtain on what it took to build Figma Slides. They share engineering challenges faced, interesting engineering practices utilized, and what it's like working on a product used by millions of designers worldwide. We talk about: • An overview of Figma Slides • The tech stack behind Figma Slides • Why the engineering team built grid view before single slide view • How Figma ensures that all Figma files look the same across browsers • Figma’s "vibe testing" approach • How beta testing helped experiment more • The “all flags on”, “all flags off” testing approach • Engineering crits at Figma • And much more! — Timestamps (00:00) Intro (01:45) An overview of Figma Slides and the first steps in building it (06:41) Why Figma built grid view before single slide view (10:00) The next steps of building UI after grid view (12:10) The team structure and size of the Figma Slides team (14:14) The tech stack behind Figma Slides (15:31) How Figma uses C++ with bindings (17:43) The Chrome debugging extension used for C++ and WebAssembly (21:02) An example of how Noah used the debugging tool (22:18) Challenges in building Figma Slides (23:15) An explanation of multiplayer cursors (26:15) Figma’s philosophy of building interconnected products—and the code behind them (28:22) An example of a different mouse behavior in Figma (33:00) Technical challenges in developing single slide view (35:10) Challenges faced in single-slide view while maintaining multiplayer compatibility (40:00) The types of testing used on Figma Slides (43:42) Figma’s zero bug policy (45:30) The release process, and how engineering uses feature flags (48:40) How Figma tests Slides with feature flags enabled and then disabled (51:35) An explanation of eng crits at Figma (54:53) Rapid fire round — The Pragmatic Engineer deepdives relevant for this episode: • Inside Figma’s engineering culture • Quality Assurance across the tech industry • Shipping to production • Design-first software engineering — See the transcript and other references from the episode at https://newsletter.pragmaticengineer.com/podcast — Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@pragmaticengineer.com. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

## Transcript

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

Shows are listed from Apple Podcasts' charts and directory, and Podcast Index where it is used. Every show and episode belongs to its publisher and plays from the publisher's own feed; this site hosts none of them.