Latest / The Pragmatic Engineer / Building Figma Slides with Noah Finer and Jonathan Kaufman

Transcript

Building Figma Slides with Noah Finer and Jonathan Kaufman · The Pragmatic Engineer

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:44
launching an in beta in April,
0:41
2024.
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:17
we had a point where slides was staging only internal only,
48:20
and then I think it was March,
48:15
2024 or so where we had our first alpha launch where we had a select few
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.