ericlippert

You have accurately re-stated the situation, yes. I know for a fact that there are teams like that! And what are they going to do now that the scientists who could have helped them make those decisions in a principled way are scattered to different teams or companies? This is the very definition of penny-wise and pound-foolish.

Thank you, that's kind of you to say!

I appreciate the sentiment behind your post, but in the future could we all please not conflate "neurodivergent people's difficulties in expressing empathy" with "being a jerk on the internet"?

I've had many gentle, kind, thoughtful and loving friends, classmates and coworkers who have lived with autism, and it's unfair and unkind to compare them to internet trolls. Thanks!

I was regretted attrition. And very, very far from the most vital person on my team.

People are leaving. In droves. There has been a huge exodus of senior talent in the last year. Zuck mentioned that in an earnings call and rather than assigning himself any responsibility said that those people were unregretted attrition and lazy parasites who were just collecting a paycheck during the pandemic. (I am paraphrasing somewhat; you can look it up if you want his exact words.)

Regarding change from within -- that's what a team dedicated to improving decision making is for.

We were a team of mathematicians focused on cost savings and improving decisions. We know how to subtract costs from benefits.

I was not the lead.

A team focused on helping the company make better decisions is all the more necessary when attempting a pivot.

I do have data to back this up for employees. You'd win that bet. Shareholders, I have no data on that.

Nor did anything compel you to read it, or post whiny comments here!

I did choose to work for Facebook. The pitch I was given seven years ago was that (1) the mission of the company is to lower costs of building community and connecting people; running an ad-funded social media platform is the means to that end. That's not a mission that is super important to me, but I can respect it. And (2) FB is the company that is investing heavily in advancing modern developer tools outside of the Microsoft ecosystem. That is a mission that is important to me.

Your statement that I wish I could continue to work for and enrich Zuck is false. I was regretted attrition.

Your lack of empathy is clear.

I am very thankful for that opportunity. I learned so much from my colleagues! And they were genuinely great people to work with.

I was well compensated, it's true. It's also true that for every $1000 I was paid, I lowered FB's costs by about $4000. The argument that I should be eternally grateful to Zuck for allowing me to keep a quarter -- before taxes! -- of the profit that accrued to him for writing zero lines of compiler code while he keeps the other three quarters is maybe not the strong argument you think it is.

Not the first time I've made that joke, but it's none the worse for having been used before.

I'm 100% sincere in that praise of my colleagues.

Many people, myself included, had a lot of concerns about the products the company was building and their effects on the world. When you work on a team whose mission is to help other teams make better decisions at lower cost, the aim is to look at the whole system and improve the whole thing.

Let me give you an example. Most "this content doesn't belong on FB" decisions are made by ML, but a great many go to human review. Imagine what that job is like. It's emotionally exhausting, it's poorly compensated, burnout is high.

My team had a model in production where we would use Bayesian reasoning to automatically detect when a particular human was likely to have made the correct decision about content classification, and therefore, if two humans disagreed, how to resolve that impasse without getting a third involved. (And in addition we get a lot more information out of the model including bounds on true prevalence of bad content, and so on.)

Does that save the company money? Sure. Millions of dollars a month. (And for the amateur bean counters elsewhere on this page: the data scientist who developed this model is NOT PAID MILLIONS OF DOLLARS A MONTH.) But it also (1) helps keep bad content off of the platform, so users aren't exposed to it, (2) lowers the number of human reviewers who come into contact with it, which is improves their jobs, and (3) frees up budget for whatever improvements need to be made to this whole workflow.

That's just one example; everything that we did was with an eye towards not merely saving the company money, but improving the ability to make good decisions about the products.

"Signal loss" is the overarching term for all the factors that lead to the company being less able to make good inferences about users. Not just the obvious consideration of "how do we serve an ad that is relevant to the user?" but for any data-driven decision that affects a user's experience.

The biggest recent cause of signal loss was Apple changing the rules for apps on their phone, but there are plenty of other causes.

The idea of a signal loss model is to identify ways to work around signal loss and still do a good job of making a decision with the data you have, when some of the data you were relying upon disappears suddenly.

That's all very kind of you to say, thank you.

I have several times been offered the chance to teach a masters level course on compiler design but never had the time to develop it. After a bit of a break, maybe I'll give that more thought.

And thanks to all the repliers below for their kind words. My goal was always to share knowledge and enthusiasm and it is genuinely touching to know that I succeeded.

I see your point and don't mean to be argumentative, but a couple small corrections.

First, the pivot to "meta" was just over a year ago, so it hasn't been quite years.

Second, I haven't been shy about sharing my opinion internally, though I haven't been broadcasting it either. The first thing I said in our team group chat when we'd heard this announcement was (context, I am much older than most people on the team) "I'm old enough to have read Snow Crash the week it came out and IT WAS A DYSTOPIA, why are we building it?"

Third, this opinion is indeed extremely common internally.

Fourth, I genuinely have no idea how this decision was made; it was certainly not on the basis of net cost savings. We did the math.

The team was all mathematicians. We did the math. I helped one of our data scientists put a model into production that saved $15M a year from that model alone, and we had a dozen people like that. We were working on signal loss models that had potential to save billions. I genuinely do not understand the logic of cutting this team to save costs.

Thank you, that's kind of you to say.

The question -- if sincerely asked -- is not rude.

My goal for this blog, which I have written for 17 years, is to write about algorithms, programming techniques, language design, and other stuff I find interesting. If you find it interesting too, consider subscribing.

The goal of this particular series, which should top out at 36 episodes, is to make a survey of different techniques for computing the Conway's Life automaton. The specific point I want to make in doing so is: the standard advice for optimization is to make a relatively naive implementation, profile, and then attack the slowest part by micro-optimizing it. Though this can be done in a principled manner, there are some algorithms where we can take advantage of facts about the "business domain" to craft much more performant algorithms than we could by simply finding small efficiencies in the inner loop. Life is definitely such an algorithm; there are opportunities for compression of both time and space that can lead to surprising performance optimizations.

My advice would be to start the series from the first episode rather than trying to start in the middle.

And that you would read it that way says more about you than it does about Tim, believe me.

It's not clear to me why you think that this anecdote had any particular intention. My intention was not to promote any position at all, but rather to tell an amusing personal story that I was reminiscing about because of an email I got from a young friend.

Anecdotes are by definition anecdotal; I am not promoting an anti-science position by relating a personal anecdote and I resent the statement that I am doing so.

If you'd like to write a blog article that promotes scientific thinking, I strongly encourage you to do so.

Yeah, all the links are wrong now. I'll fix them!

As I noted in the text, the actual problem that we had to solve was complicated by a great many factors not the least of which was the fact that the library had to handle strings from different string encodings.

Noted.

In this case I think not. However I strongly agree with your position and have tried hard to ensure that my code is commented such that it explains why the code works as it does. See https://ericlippert.com/2014/09/08/comment-commentary/ for more thoughts on this subject.

It does a full lex and parse. Then if there is an edit, it determines based on the edit which tokens need to be re-lexed; maybe we went from "[10,20]" to "[10.20]" and so now the [ and ] tokens are fine but everything in the middle is changed.

So we go from a data structure representing "original text plus edit" to a data structure representing "original lex plus changes". Now we have the information we need to do the same to the parse tree, which has also been stored. Given the set of tokens in the program which changed, and knowledge of where the textual boundaries are of every parse node, we can restrict the re-parse to the affected syntax tree spine. In the example given, we know that we've still got, say, an array index list but the contents of the list need to be re-parsed, so we re-start the parser on the left bracket.

The algorithm that does this is called "the blender", and reading that code makes my brain feel like it is in a blender. The code was written by Neal Gafter and based on his PhD thesis in incremental parser theory.

The source code is available on github; do a search for "roslyn" and you'll find it.

Well then, feel free to write your own blog post on a topic you enjoy more!

One of the most important things you can do in perf analysis is to know when to stop looking for incremental improvement.

If this subject in particular interests you, we did a lot of work in the C# lexer/parser so that once the file is lexed, it only re-lexes the tokens which changed on every edit. It also does fun stuff like the syntax colourizer only runs on code that's actually on the screen. Getting every operation that depends on the lex/parse of code in the editor down to running in much less than 30ms so that it would not slow down keystrokes was a huge amount of work.

Well thanks for inspiring the post! It triggered a pleasant trip back to a simpler time for me.

A Visual Basic program is not allowed to have undefined behaviours like a C program; InStr has a specification and that specification has to be implemented; that spec includes defining the behaviour for all inputs.

There's also no null handling here, which was a deliberate omission for clarity. In practice, the convention used inside the VB source code is that null string pointers are semantically the same as empty strings, which introduces some complexities.

That's a great example; the most important part of your anecdote is the end which says what was the user impact? There is no prior reason to believe that a 50x speedup is actually a win; taking an algorithm from 100K nanoseconds to 2K nanoseconds when hitting the file system takes billions of nanoseconds is not a win for the user, and taking an algorithm that takes 5000 years down to 100 years is probably not either.

But a 50x win that, as you note, goes from "let's have lunch" to "let's change this one thing ten times and re-do the analysis to see which gets us the best results" is a huge game changer; it's not just that it saves time, it's that it makes possible new ways to work with data.