← Back to context

Comment by jameshart

4 years ago

I'm not sure "It doesn't take a PhD, just years of experience" is quite the rejoinder the author thinks it is.

Aren't they both just ways of saying "It takes someone with a rare subset of highly specific knowledge to solve this problem"?

The MS person was saying "Sure, there's probably a way to make this faster but I don't have anyone on my team who knows how to do that. If I had the budget to go out and hire someone with a PhD maybe I could do it."

That then Casey Muratori could show up and do it in his spare time doesn't really refute that argument, does it? This is someeone who has spent years actually doing hardocre R&D work, and literally published techniques that advance the state of human knowledge in the field of GUI rendering[0]. His resume is kind of a living example of 'PhD, or equivalent professional experience'.

So sure, it might be nice if MS's career structure led to them having more Muratoris on staff, but I don't think the expectation that every product team should have one or two developers of that caliber on it is a reasonable one.

It IS a good argument for why MS should accept open source contributions, though.

[0] https://caseymuratori.com/blog_0001

It's not really what the MS devs said though: "I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation"

This seems to mean, nobody has ever done that, it is a research project (a doctorate thesis must be about something that has never been researched before, at least where I live).

This particular problem cannot be a PhD subject, because it has already been researched, solved and done multiple times, by different persons and on different projects.

Someone can use the knowledge already widely available on the internet to grasp what the issue is, and implement a solution in their own project.

Years of experience aren't a PhD. Years of experience can help you understand a thesis, but only if the research doesn't exist yet, can it be considered a doctoral research project.

  • So the comment that the 'PhD' reference was responding to was Muratori laying out how he figured a simple terminal renderer could be implemented, using two texture lookups in a single drawcall [0].

    In the course of that, Muratori allowed, almost in passing, that of course you would need, in order to do that:

    > a glyph atlas encoding the cell-glyph coverage in whatever way makes it easiest to compute your ClearType blending values

    Now, it does not strike me as beyond the realm of possibility that that step might be suitable for academic research. It calls for an efficient encoding of cleartype-ready glyph data with comprehensive coverage of unicode glyph space (not codepoint space). That's not trivial, and - as the DHowett reply suggests - it would take a literature review to determine if someone has already accomplished this (and he also suggested that so far as he was aware this was not how any other terminal was implemented, implying this is not simply some well known solved problem).

    I mean, sure, he could be wrong about that - it might be exactly how another terminal implements it; there might already be published research on the topic; or it might just be much simpler than it appears. But it's not crazy to, on glancing at that problem, consider that it seems like it might actually require genuine original high level research.

    [0]: https://github.com/microsoft/terminal/issues/10362#issuecomm...

    • I disagree. All this means is just putting the glyph cache on the GPU. DirectWrite (or any other font rendering API you care to use) already implements a glyph cache, and it already deals with filling in that cache gradually whenever you use glyphs not already present in the cache. And it already knows about Cleartype, or whatever form of antialiasing you prefer. There’s no research here.

      1 reply →

I think the other piece the comment and the rejoinder miss is is: A PhD generally means you've done four years of work post bachelors, and some of that work was novel.

A PhD alone does not make someone an expert in most modern senses in software. The folks the author describes as "experienced" often have more than a decade of working software knowledge from after their education.

Casey Muratori has 30 years of programming experience. That's not a PhD, that's a PhD and then an additional 20+ years of experience.

And to be clear, Microsoft probably has plenty of people capable of writing this kind of code. They just aren’t working on console.

In fact, consider the hypothetical of: what if Microsoft had hired Casey Muratori.

Do you imagine they’d have put him on the console team?

I mean the Windows console, not the X Box console, or the Minecraft console.

  • Microsoft has _Micheal Abrash_.

    He wrote The Book on rendering performance. Michael's super optimized x86 assembly routines for lighting and texturing is the reason we can run Quake on toasters.

    Anyway, I don't think they should hire Casey. Specially after that demonstration of not understanding the big-picture and not being a team player...

    • Maybe they shouldn't, but...

      The 'big picture' he hasn't understood isn't just about text rendering in this instance, though. It's also a picture internal to Microsoft that motivates their commitment to certain libraries. I think the disconnect is to be expected, given that he's not currently at Microsoft. It may also be that some of those commitments are not as well motivated as MS thinks (i.e., maybe the additional maintenance burden of some specialized text rendering libraries for the simplified case of terminals is not so terrible and justified by the performance gains). I don't think this shows that at Microsoft he'd be unable to have a good sense of 'the big picture'.

      It's also not clear that any of this shows he isn't a team player. The Windows Terminal developers are colleagues of his in the distant sense of 'fellow developers', but they're not 'his team'. He doesn't have pre-existing relationships with them. And his frustration was in being told 'this cannot be done' in a way that was insufficiently clear and convincing to him and came across as condescending. I think it's reasonable to be frustrated under those circumstances, feeling ignored and maybe also like someone is bullshitting you. I could see the interaction being different if Casey had a different relationship to the other developers and they were more invested in trying to loop him in on their whole suite of platform commitments that ground (or trap) them in the current design, especially if he felt like advocacy for alternative commitments (e.g., to maintaining a separate, simplified stack for rendering text on the terminal) might be reasonably considered.

      I'm also sympathetic to some of the MS devs here, because some of Casey's tone could have been taken as suggesting that they weren't really making an effort with respect to performance and that could be insulting. I don't think it was necessarily wrong for them to bring that up. But I don't think Casey was abusive, either, and it doesn't seem like anything that went down in that thread is beyond repair to the point that the people involved in the discussion couldn't work together.

      If Casey were interested in working at Microsoft I think it'd be silly to rule him out as a candidate based on what we can see in that thread.

    • Do you have some examples of what big-picture stuff Casey doesn't understand? Not talking about being a team-player.