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.
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.
+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.
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.
The linked post was about Evan's side project, but within Figma, all of that is indeed possible. The glyphs are transformed into vector networks[0], which has a fill pipeline that supports transparency, gradients, images, blending, masking, etc.
It is incredible how easy this stuff spirals out of control and why I'm not too worried about AI yet.
Every now and then I'm writing a PoC or greenfield project that you put down for 6 months. And sometimes when I pick it up to extend it, it will just so rapidly feel like it's getting out of control (I'm actually listening to the chemical brothers song of the same name at the moment!). I can at least usually fix that with some refactoring, but why didn't I get it right at the time? I don't know.
And it's often hard to figure out why, what architectural decision did you make to cause this. Pointing at the particular interface or pattern or method call chain that is the cause of a ton of complexity that could be fixed is much, much, much harder than most jobs in programming. And beyond the ability of 90% of developers.
The -2000 story popped up here again recently (https://news.ycombinator.com/item?id=44381252), and it's of the same vein, why had no-one else done that? Because it takes extreme skill to simplify existing code. It's beyond most developers.
I think it's why we as an industry often obsess about things like space/tabs/semi-colons or not/etc. They're obvious improvements to an architecture, and everyone can join in. But really, they're a small improvement to a codebase, not a massive one.
And then you get the Evans of the world who just do it, almost effortlessly. I've worked with an Evan, and sometimes you'd look at his code and think "why?", but any attempt to change or improve it invariably made it worse. He'd picked that pattern or structure or method call chain and it was always the right choice. And after a day of poking at it, exploring the edges, trying to change it, you'd realize why.
And yes, sometimes the code was so complex other developers couldn't get it. And then they'd call me over to help because I could get it. And I'd look at it and realize it was complicated because it had to be like that. He'd actually done it in the simplest way possible.
And years later I still make the wrong choice sometimes, and I always think of Simon and wish I had his magic touch.
Even if he used to name functions Thing() and DoStuff() and forget to update them.
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.
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.
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.
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.
Usually it is dangerous to let such people write application level code, but according to the reports in the comments, the guy might be one of the few exceptions, who gets the low level right, but also created flexible extensible structure of code in other places, without it becoming obscure on the application level.
Usually when I see some mathematical code that's not explained at all and has obvious flaws in terms of simple improvements that could be made to improve readability or even something as simple as some comments, I just keep thinking: "Please don't let this person touch application level code!"
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.
As others have pointed out: if the complexity is in the domain then that's perfectly acceptable. I always remember reading some lines of code in Linux that had a comment above them: "This code is meant to be read by a CPU, not by a human."
The hard part is knowing when the code is complex because the domain/performance requirements demand it be that way vs when the code is complex because the engineer was just trying to appear smarter than they are.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.