kangax

In my experience, it depends on the company. At Facebook, 90% of my peers were younger than me (I was 30). At LinkedIn, right now, many of my peers are around the same age or older than me (I'm 35). I imagine in places like Microsoft or Oracle there are plenty of 40/50+ engineers who aren't worried about being kicked out.

I agree with this and was wondering the same thing. Would love to see randomized studies comparing a) control, b) sauna c) exercise d) sauna + exercise.

On the other hand, anecdotally, lots of Russian weighlifters swear by sauna benefits and have been doing it for decades as a recovery from grueling daily heavy sessions.

Wondering the same thing.

I learned about DeFi recently and am now curious to learn more about smart contracts, the underlying code and everything surrounding it.

Go to the gym!

With a bit of commute it could fill up to 2 hours of your day and have a plethora of benefits. Once you get into the whole "getting better than yesterday" thing, it's exciting to go train every day and improve your "stats".

That's crazy, I'm so sorry you haven't regained your senses the way they were.

My friend is experiencing exactly the same results many months after having Covid. Doctor prescribed steroids for him which made it better for a brief period of time but then it regressed.

I, on the other hand, lost my smell for about 4 weeks after which it mostly came back to normal.

I just don't understand why no one is talking about this, as it seems like quite a lot of people have had permanent changes to their smell and this is just absolutely terrifying.

We tried doing this at Facebook few years ago but decided not to bother due to an insignificant effect on user metrics like TTI (time to interaction), FCP (first content paint), etc.

14KB is nothing when you're shipping 1MB+ of JS and all the other assets.

We should probably amalgamate this with the one we have at https://kangax.github.io/compat-table/

ReasonML is a good transition from JS to something like OCaml

Yep. Both are stage-1 proposals:

https://github.com/tc39/proposal-optional-chaining

https://github.com/tc39/proposal-nullish-coalescing

Recently started using optional chaining in our codebase (via Babel 7) and it's great so far. Also gives us proper static typing safety unlike Lodash `get(...)`

This is much needed. The extension has been broken for our team for a couple months now. No clear resolution. The Flow suggestions in an editor are basically unusable right now.

I think that was the motivation of https://js.foundation

I was on an infra so the "product" was improving both developer experience and user experience. Thing is — as a senior engineer, you're encouraged to do work that spans across multiple teams. The self-review would include all the impactful things you've done by helping person X or team Y or product Z, etc.

I was E6 at Facebook for 1.5 years.

Left due to a combination of not finding the right team/project and constant pressure to work on something impactful rather than fixing existing issues I cared about. This seems to be a common issue at FB with senior engineers joining and having to ramp up quickly (2 of the senior teammates left while I was there for the same reasons).

Currently at WeWork where you don't have to write multi-page assessment of all the impactful things you've done during the last half.

It's not perfect but the work-life balance at senior level is better than at FAANG.

I agree that TS increases barrier to entry for contributors. However, it's very different from Coffeescript. It offers better program correctness via types whereas CS was mostly sugar. Libraries that (properly) use Flow/TS are less likely to have bugs and are safer to contribute to (you're less likely to introduce a bug) and that's a good thing.

This is such an underrated comment.

I love this style of code reviews and it's the one I've experienced best discussions with. It goes in line with assuming that you, as a reviewer, don't know what the intentions/rationale are rather than blindly dictating your solution. A lot of times the reviewer that says "this is wrong" is then explained to why it was done a certain way and is the one proven wrong. Questioning yourself as a reviewer is always a good idea. Asking questions gives feedback without coming off aggressive/judgemental/patronizing.

I'm wondering why homelessness is not as large in NYC? The prices here are as high as in SF. Is it due to the slower rate of a price increase? Colder weather?

As mixmastamyk said, it's exactly the same as the gym (I work out ~5 days a week too and I started from being the least athletic person in school/college).

I hear people say — I'm already 30 and starting to exercise is too late, or that they're intimidated by other people at the gym, or that they don't know where to start. Having gone through a similar experience as yours, I gotta say you just have to start. Don't overthink it. You'll fail. Try again, keep at it, and eventually there'll be a breaking point.

Good luck.

Nice breakdown.

I would add that money comes with responsibility and it's the money/responsibilities ratio that really matters.

I was at a top-tier tech company (the one that's getting all the heat lately) for 2 years in a senior eng role, breaking my neck and struggling to maintain healthy work/life balance. Leaving it felt devastating but in retrospect, it was the right decision. Now I'm at a non-tech company, making almost the same money, having twice fewer expectations. All while working on just as exciting tech and problems.

I can likely get a tech position in finance and make even more, but at what cost to my work hours and expectations? Not worth it.

I'm at FB office in NYC and I agree with your points. MPK always has that more chill vibe and is less dense/quieter. The NY office has gotten much better though. Many engineers are now on 15th floor which has no distractions like help desk and is generally surprisingly quiet. I notice myself working in almost complete silence among many people around and only once in a while put my headphones on. Sucks to hear about your experience.

Also https://github.com/h5bp/lazyweb-requests

Great idea! We need the same for ES6/7/etc. — http://kangax.github.io/compat-table/es6/

Yep, I've been down that road — http://fabricjs.com/test/misc/itext.html :)

Unfortunately not possible since the editor is part of a browser extension and is activated on any page with textarea/contenteditable. Text could change at any time by other scripts, and the only way to intercept those changes is via MutationObserver. MutationObserver gives you changed node and its text (without getting entire plain text, we can't really "transposition" this all onto a global text to figure out what changed).

> So if innerText was standardized to your use case what would it be good for other than your specific project?

I don't think this is a very specific task. As you've seen in the post, other people have similar requirements (text editor, selection retrieval, etc.) and similar desire for keeping `innerText`.

> Pulling large chunks of plain text as a string to process for any low latency tasks constrains the size of text you can reasonably work with. JS strings are immutable as well, that's a lot of copying.

Pulling large chunks of plain text — that's a plausible argument, but no different than pulling, say, `innerHTML` (large chunk) or `textContent` (large chunk) or really anything else in JS land (which if often full of strings — JSON, templates, whatever).

> Another issue is this whole handling of converting lists and tables to some kind of plain text markup. Is that a two translation? Are tabs going to turn into table elements if I have them in a string and set innerText? That seems pretty crazy, but not doing so would just make it very weirdly asymmetrical.

That's a very good point! But don't forget that we already have a standard way of setting element contents from plain text — `textContent`. Yes, innerText setting would have to be assymetrical; I doubt anyone would want to go down the rabbit hole of backwards conversion. Everyone usually agrees that when it comes to setting, `innerText` should simply act like `textContent` (to quote spec: "on setting, no parsing is performed either, the input string is taken as pure textual content.")

> How much horribly slower do you want the DOM to be? Well, as app devs, we still need to implement plain text retrieval. By not having it natively in Mozilla, the joke is really on the users — more strings (in JS land), more DOM iteration, more everything. How is that for a "slow DOM"? ;)

But browsers already take care of this. They collapse all the spaces in markup for non-pre-formatted blocks; they render block/inline elements accordingly; insert newlines where needed, etc. And then, once you select some text from the page — there's your "plain text" representation. We probably can't avoid differences among browsers (simply due to the vast nature of HTML — form controls, media content, generated content, new elements like <template>, non-standard extensions, etc.) but in context of a single browser, the logic already exists beneath. It's just not exposed conveniently.

(author here)

I'm working on text editor with real-time spelling correction where `innerText`-like retrieval has to happen quite frequently; it's what pushed me to research the state of affairs with `innerText` in the first place.

It pains me that we don't have a quick, native way of doing that; that I have to traverse the DOM manually instead — a horribly, horribly slow process — essentially writing what `innerText` was supposed to be.

I guess HTML/DOM were never really designed to be good at a task like this. The closest thing is Selection/Ranges API but it's still way behind in terms of performance.

The fact that there's `innerText` in some browser sarcastically starring in your face ("I'm here, but you can't really use me") just makes this so much crappier.

I guess a lot of this boils down to performance. It's certainly possible to emulate `innerText` but we can't possibly match native speed. And speed is crucial for any kind of real-time editing that needs to have a quick access to plain text version of an element.

Yep, it's in the plans! :)

2012, actually. In 2008 we had Firebug with not even a JS profiler, IIRC ;)

Pretty much the only feature, yes. We'll be adding it shortly, sorry for the confusion.

Definitely.

And that's why we give different weight to different features. Smallest ones (Math methods, octal & binary literals, etc.) have a weight of 0.25. Medium ones (Map, Set, rest parameters, etc.) have a weight of 0.5. Finally, landmark features (arrow functions, classes, generators) have a weight of 1.

The final % score is calculated according to all this.