6 ms·

As a former figma engineer, let me be the first to say that Evan Wallace is, in fact, a legend. A true 100x-er. There's still parts of the codebase basically no

As a former figma engineer, let me be the first to say that Evan Wallace is, in fact, a legend. A true 100x-er. There's still parts of the codebase basically no one at Figma really understands that Evan wrote back in the day. One example of that is something like he adapted a shader we use internally to render font glyphs, which no one has touched ever since. The engineer who told me this had spent a few days trying to understand it and said (after having worked in this area for years) was stumped by it.

andrewmcwatters 1y ago
That's... not a screaming testimony, dude.
- timcobb 1y ago
  > A true 100x-er
op00to 1y ago
I don’t mean this to throw shade, but isn’t the whole point of writing code that someone else can understand it? I worked with some crazy smart people when I was in academia, and when one of them left it was not worth trying to maintain what they left behind because it was so often inscrutable.
- sowbug 1y ago
  Even well-written code can be hard to understand -- practically impossible, even -- if what it's doing is sufficiently complex. Cryptography and certain areas of graphics have humbled me, for instance. I followed the flow, and I appreciated the comments, but I did not understand.
  - handfuloflight 1y ago
    Any specific lines you can point to as examples in an open source repo?
- com2kid 1y ago
  Font rendering code is a nightmare because the problem is really damn hard. Font files are complex, and actual real world usage is even worse. Any code that involves parsing old school binary file formats is going to look ugly to modern day developers who are used to JSON everything, even if the code is actually very well structured.
- switz 1y ago
  The reason to write code is to solve a problem. If the problem domain is complex, then the code to solve said problem will be inherently complex. He solved a problem.
nicce 1y ago
I don’t know anything about shaders and this is not personal against Evan, but if someone wrotes code that nobody understands, isn’t it bad thing and not good thing? I thought similarly (admired) many years ago, that those people are wizards and that is cool, but the older I get, less I think so. You often can write the same thing so that it is also easier for others to understand. In most cases, when we talk about compiled languages, compiler optimises it anyway, if you use some extra variables and so on.
- Vanclief 1y ago
  Exactly, I had the same issue when I was younger. I thought if I read code I could not understand was because the other dev was a legend. Now its the opposite, I am amazed by code that does its job well, its understandable and has low complexity.
- danielvaughn 1y ago
  It’s a bad thing if you make a simple thing more complicated than it needs to be. But there are plenty of Hard Problems out there, for which no sufficient code could be called “simple.” Plenty of aspects of font rendering fall within this bucket. It’s notoriously difficult.
- wbl 1y ago
  Computer typography is a dark art. It requires understanding a whole domain with its own terminology and traditions as well as aesthetic sense, then combine that with the programming knowledge.
- sokoloff 1y ago
  The first startup I worked at was in typography. Writing a full typographic rendering engine in webGL shaders is going to result in code that is difficult for others not experienced in webGL and typography. It’s inherently (and likely irreducibly) difficult, not accidentally/gratuitously difficult.
- Cthulhu_ 1y ago
  That's what I was thinking, but then, it is very specialized and high performance code well outside of my domains (font rendering, shaders, C++, high performance / frequently called code is very much not my bread and butter). I frequently glaze over whenever trying to read a post about some optimization problem. Fast inverse square root [0] is succinct and cleanly written even though it uses math symbols instead of variable names, but I have no idea how it works and don't have the math basics to even know when / where / why to use it. [0] https://en.wikipedia.org/wiki/Fast_inverse_square_root https://en.wikipedia.org/wiki/Fast_inverse_square_root
preommr 1y ago
> which no one has touched ever since. The engineer who told me this had spent a few days trying to understand it and said (after having worked in this area for years) was stumped by it. yikes
isaacremuant 1y ago
I understand where you're coming from and the admiration for someone for whom no problem is seemingly impossible. I wouldn't glorify "brilliant code" that much though because code should be made to be changed. If it isn't, it's a fragility trait, not a positive trait. Code that no one knows how to change is opportunity lost. I do understand that it may be hard to create stuff for others when you're alone and going very fast but I don't think praising it is the right idea.
- safetytrick 1y ago
  I don't think changeable code is the number one priority. The goal is to solve a problem and code that solves a problem without needing to change is sufficient. Code that doesn't need to change is a really good sign that you've got something good.
  - isaacremuant 1y ago
    The real world moves. If your code didn't change it must be generating value against something that is very standard but I'd be very surprised that you're not modifying, adding, etc based on usage to derive even more value somehow. > Code that doesn't need to change is a really good sign that you've got something good. Not really, but you're thinking in terms of "my code nailed it because I'm not touching it" and that has NOTHING to do with it being easy to change.
rudi-c 1y ago
Font rendering is indeed complex, but the anecdote seems to be misleading readers into thinking Evan wrote obscure code. I worked extensively in the parts of the Figma where Evan wrote a lot of foundational code, and have also worked directly with him on building the plugin API. One of Evan's strong points as a CTO is that he was very pragmatic and that was reflected in his code. Things that could be simple were simple, things that needed complexity did not shy away from it. While all codebases have early decisions that later get changed, I'd say that largely speaking, Figma's editor codebase was built upon foundations that stood the test of time. This includes choices such as the APIs used to build product code, interact with multiplayer, the balance between using OOP v.s. more functional or JS-like patterns, the balance between writing code in C++/WASM v.s. JS, etc. Many of these choices can be credited to Evan directly or his influence. Subsequent engineers that joined were able to build upon the product without causing a spiraling mess of complexity thanks to those good decisions made early on. In my opinion, this is why Figma was able to ship complex new features without being bogged down by exploding tech debt, and a major contributing factor to the business's success as a whole.
- poiru 1y ago
  +1 from another Figma engineer who happened to work on the text engine back in the day. I think that Evan generally wrote code that was as simple as possible — there was no unnecessary complexity. In this case there indeed is some inherent, unavoidable complexity due to the math involved and the performance requirements, but otherwise I found our text rendering pipeline very understandable. Evan actually wrote about it if you're curious to learn more: https://medium.com/@evanwallace/easy-scalable-text-rendering-on-the-gpu-c3f4d782c5ac https://medium.com/@evanwallace/easy-scalable-text-rendering...
  - marhee 1y ago
    It’s a clever trick. But can it render a textured text? Transparent text, gradient fills? Maybe it can, I dont know. But why not just triangulate the glyph shapes, and represent each glyph as a set of triangles. This triangulation can be done offline, making rendering very lightweight.
Mtinie 1y ago
That it works is testimony to the intelligence put towards the code. That no one else can grep it tells me it was solved in a manner which was suboptimal. I cannot believe Figma hired engineers who could not follow along already-tread footsteps. That’s a nonsensical assertion. Novel code may be inscrutable but the problem-solving and techniques should have been clear and repeatable by those who follow, even if they require adaptation.
sizzle 1y ago
Do you think AI could take a crack at understanding it for you?
- Cthulhu_ 1y ago
  Wouldn't know until we try it; I have a suspicion AI would struggle with "rare" code snippets though, given there's not much online like it.
latexr 1y ago
The way you’re telling it, that feels like a really weird thing to praise. “There are majorly important parts of the code base with a bus factor of one” isn’t something to celebrate or be proud of.
scary-size 1y ago
IIRC a few folks from Mapbox joined Figma years ago. They probably know their way around font rendering in WebGL (unsigned distance fields et al.).
11101010001100 1y ago
Wait, so no one asked Evan to explain the code? Something smells fishy.
deleted 1y ago
[deleted]

andrewmcwatters 1y ago

That's... not a screaming testimony, dude.

timcobb 1y ago
> A true 100x-er

op00to 1y ago

I don’t mean this to throw shade, but isn’t the whole point of writing code that someone else can understand it? I worked with some crazy smart people when I was in academia, and when one of them left it was not worth trying to maintain what they left behind because it was so often inscrutable.

sowbug 1y ago
Even well-written code can be hard to understand -- practically impossible, even -- if what it's doing is sufficiently complex. Cryptography and certain areas of graphics have humbled me, for instance. I followed the flow, and I appreciated the comments, but I did not understand.
- handfuloflight 1y ago
  Any specific lines you can point to as examples in an open source repo?
com2kid 1y ago
Font rendering code is a nightmare because the problem is really damn hard. Font files are complex, and actual real world usage is even worse. Any code that involves parsing old school binary file formats is going to look ugly to modern day developers who are used to JSON everything, even if the code is actually very well structured.
switz 1y ago
The reason to write code is to solve a problem. If the problem domain is complex, then the code to solve said problem will be inherently complex. He solved a problem.

nicce 1y ago

I don’t know anything about shaders and this is not personal against Evan, but if someone wrotes code that nobody understands, isn’t it bad thing and not good thing? I thought similarly (admired) many years ago, that those people are wizards and that is cool, but the older I get, less I think so. You often can write the same thing so that it is also easier for others to understand. In most cases, when we talk about compiled languages, compiler optimises it anyway, if you use some extra variables and so on.

Vanclief 1y ago
Exactly, I had the same issue when I was younger. I thought if I read code I could not understand was because the other dev was a legend. Now its the opposite, I am amazed by code that does its job well, its understandable and has low complexity.
danielvaughn 1y ago
It’s a bad thing if you make a simple thing more complicated than it needs to be. But there are plenty of Hard Problems out there, for which no sufficient code could be called “simple.” Plenty of aspects of font rendering fall within this bucket. It’s notoriously difficult.
wbl 1y ago
Computer typography is a dark art. It requires understanding a whole domain with its own terminology and traditions as well as aesthetic sense, then combine that with the programming knowledge.
sokoloff 1y ago
The first startup I worked at was in typography. Writing a full typographic rendering engine in webGL shaders is going to result in code that is difficult for others not experienced in webGL and typography. It’s inherently (and likely irreducibly) difficult, not accidentally/gratuitously difficult.
Cthulhu_ 1y ago
That's what I was thinking, but then, it is very specialized and high performance code well outside of my domains (font rendering, shaders, C++, high performance / frequently called code is very much not my bread and butter). I frequently glaze over whenever trying to read a post about some optimization problem. Fast inverse square root [0] is succinct and cleanly written even though it uses math symbols instead of variable names, but I have no idea how it works and don't have the math basics to even know when / where / why to use it. [0] https://en.wikipedia.org/wiki/Fast_inverse_square_root https://en.wikipedia.org/wiki/Fast_inverse_square_root

preommr 1y ago

> which no one has touched ever since. The engineer who told me this had spent a few days trying to understand it and said (after having worked in this area for years) was stumped by it. yikes

isaacremuant 1y ago

I understand where you're coming from and the admiration for someone for whom no problem is seemingly impossible. I wouldn't glorify "brilliant code" that much though because code should be made to be changed. If it isn't, it's a fragility trait, not a positive trait. Code that no one knows how to change is opportunity lost. I do understand that it may be hard to create stuff for others when you're alone and going very fast but I don't think praising it is the right idea.

safetytrick 1y ago
I don't think changeable code is the number one priority. The goal is to solve a problem and code that solves a problem without needing to change is sufficient. Code that doesn't need to change is a really good sign that you've got something good.
- isaacremuant 1y ago
  The real world moves. If your code didn't change it must be generating value against something that is very standard but I'd be very surprised that you're not modifying, adding, etc based on usage to derive even more value somehow. > Code that doesn't need to change is a really good sign that you've got something good. Not really, but you're thinking in terms of "my code nailed it because I'm not touching it" and that has NOTHING to do with it being easy to change.

rudi-c 1y ago

Font rendering is indeed complex, but the anecdote seems to be misleading readers into thinking Evan wrote obscure code. I worked extensively in the parts of the Figma where Evan wrote a lot of foundational code, and have also worked directly with him on building the plugin API. One of Evan's strong points as a CTO is that he was very pragmatic and that was reflected in his code. Things that could be simple were simple, things that needed complexity did not shy away from it. While all codebases have early decisions that later get changed, I'd say that largely speaking, Figma's editor codebase was built upon foundations that stood the test of time. This includes choices such as the APIs used to build product code, interact with multiplayer, the balance between using OOP v.s. more functional or JS-like patterns, the balance between writing code in C++/WASM v.s. JS, etc. Many of these choices can be credited to Evan directly or his influence. Subsequent engineers that joined were able to build upon the product without causing a spiraling mess of complexity thanks to those good decisions made early on. In my opinion, this is why Figma was able to ship complex new features without being bogged down by exploding tech debt, and a major contributing factor to the business's success as a whole.

poiru 1y ago
+1 from another Figma engineer who happened to work on the text engine back in the day. I think that Evan generally wrote code that was as simple as possible — there was no unnecessary complexity. In this case there indeed is some inherent, unavoidable complexity due to the math involved and the performance requirements, but otherwise I found our text rendering pipeline very understandable. Evan actually wrote about it if you're curious to learn more: https://medium.com/@evanwallace/easy-scalable-text-rendering-on-the-gpu-c3f4d782c5ac https://medium.com/@evanwallace/easy-scalable-text-rendering...
- marhee 1y ago
  It’s a clever trick. But can it render a textured text? Transparent text, gradient fills? Maybe it can, I dont know. But why not just triangulate the glyph shapes, and represent each glyph as a set of triangles. This triangulation can be done offline, making rendering very lightweight.

Mtinie 1y ago

That it works is testimony to the intelligence put towards the code. That no one else can grep it tells me it was solved in a manner which was suboptimal. I cannot believe Figma hired engineers who could not follow along already-tread footsteps. That’s a nonsensical assertion. Novel code may be inscrutable but the problem-solving and techniques should have been clear and repeatable by those who follow, even if they require adaptation.

sizzle 1y ago

Do you think AI could take a crack at understanding it for you?

Cthulhu_ 1y ago
Wouldn't know until we try it; I have a suspicion AI would struggle with "rare" code snippets though, given there's not much online like it.

latexr 1y ago

The way you’re telling it, that feels like a really weird thing to praise. “There are majorly important parts of the code base with a bus factor of one” isn’t something to celebrate or be proud of.

scary-size 1y ago

IIRC a few folks from Mapbox joined Figma years ago. They probably know their way around font rendering in WebGL (unsigned distance fields et al.).

11101010001100 1y ago

Wait, so no one asked Evan to explain the code? Something smells fishy.

deleted 1y ago

[deleted]