rgossiaux

Neovim nightly already has some tools available as plugins. I'm using tree-sitter for syntax highlighting, text objects, and folding right now. Pretty satisfied so far.

I had never thought about the connotations of blacklist and whitelist before it was pointed out to me. In retrospect, blacklist and whitelist are unnatural meanings of the words black and white, and blocklist and allowlist make much more sense.

This is everyone's story with these words. This movement was not driven by POC taking issue with the word "blacklist". It started with some white dude's shower thought that because "blacklist" was a negative thing, and because "black" also can refer to skin color, that the term was thus racist [1]. Then a bunch of other white dudes ([2]) were like "oh yeah for sure that makes so much sense" and here we are--everyone goes along with it because they (rather patronizingly) think that someone else will be offended.

The word "blacklist" is many hundreds of years old. It does not have a racial origin. It's just a word. Nobody actually makes the association between "blacklist" and "black people" unless you tell them to! Our brains aren't nearly so stupid!

[1] https://twitter.com/andrestaltz/status/1030200563802230786 [2] https://twitter.com/dhh/status/1032050325513940992

Look at it done correctly: tomc1985 objects that "[he is] one of these people, and [he] most definitely exists!"

You also need brackets around "exists" since the original quote had "exist". I think you're proving the point. I completely agree with the author that sentences like this are absolutely miserable to read. You can quote him as saying "I am one of these people, and I most definitely exist!" and, because we all have basic reading skills, we all understand that the "I" refers to the person speaking. Mangling quotes with unnecessary brackets is bad writing.

The option seller needs to buy the stock to deliver the shares when the option expires, so if the price continues rising their losses are unbounded (by contrast, their gains are bounded by how much they originally sold the option for).

objectively clearer terminology

Sorry but I find this claim (which I've heard from others too) ridiculous. "Blacklist" is an actual common English word in the dictionary. "Denylist" is an incredibly awkward-sounding neologism without any context or history behind it. There is no way that "denylist" is the "objectively clearer" one here.

So we will probably need to recapture CO2 as well – or rather we will need to develop the necessary tech first.

Maybe this is a stupid question, but isn't the necessary tech "planting trees"?

You could expand this category to an AI for a number of similar games (like checkers and reversi) as well. I've written a double dummy solver for bridge--a program that computes the optimal result of the play of a bridge hand--as a side project and I think it's also a very good choice. A lot of the same tools as chess engine development apply: alpha-beta and the myriad variant search algorithms like MTD(f), transposition tables, heuristics like the killer move heuristic or the countermove heuristic. But you also need to apply some domain specific heuristics and tools, and since the whole thing is performance critical you need to worry about low level optimizations and good multithreading. In the bridge case it's not at all trivial to get something that can even finish at all in a reasonable timespan.

Chess is a very rich and pretty well-balanced game--that's what makes it so rewarding to study and to play. Even amongst modern computers that are miles ahead of the best humans, there's nowhere close to a single dominating opening or set of openings. On the human level, there is already far more computer opening theory than most players (including very serious, titled players) are capable of memorizing, so things haven't gotten stale yet.

I remember back in the day when we used to just ask people if they could do FizzBuzz now we're looking at if they used an interface to wrap their ORM usage. That's something that can get picked up at code review and taught. Not everyone is going to code by default at the style of a company but they can learn to do the things the company wants.

Then there is the obivous, lets test people for things they aren't going to do. Google and co made this the in thing and the fact we now have books upon books just designed so people who are good at tech can pass a tech interview is a sign in itself that there is something rotten.

So which is it? Should interviews be related to the work at the job or not? The Google type interviews evolved precisely from the philosophy in your first paragraph I quoted: that a lot of domain knowledge can be learned easily and that it was most important to test for more fundamental knowledge and abilities as well as general problem solving skills.

Ultimately I think it's a lot easier to criticize the interview process than to come up with a good alternative, as well as establishing some basic criteria about what should be selected for and against. Not that I think Google style interviews are perfect or anything, mind.

This comment thread is discussing Uber's profitability and how much they'd need to raise prices to break even independent of Prop 22.

If that was only in the US or other wealthy economies, maybe. But they're an international company. Some of those rides are in places where a $2 increase doubles the price of the ride. I think it would be more revealing to compare with their total receipts and see the % change that would be required.

There's also the weird thing of younger people like myself avoiding proper punctuation/capitalization for the aesthetic. Mainly because a lack of proper writing can make certain messages feel more "relaxed" and casual, if that makes sense.

I don't think it's weird at all, and I don't think it's simply aesthetic. All these things (punctuation, capitalization, emoji/emoticons, representations of non-verbal communication like "lol" and "hmm", message boundaries, message send times) are ways of conveying tone, nuance, and a personal voice in an otherwise sterile, flat medium.

These nuances have been around as long as we've had instant messaging, but the specifics have changed over time. Representations of laughter are a good example: over the years we've had (in no order) "lol", "Lol", "LOL", "rofl", "ROFL", "lmao", "lmfao", "LMAO", "LMFAO", "hah", "haha", "hahaha", "HAHAHAHA", "roflmao", "roflcopter", and others. Over time the nuances of these options have changed, with some no longer au courant (the rofl family is currently outmoded), just as spoken slang and language rapidly evolve. Punctuation choices and so on follow similar patterns.

I do roll my eyes a little bit at some of the wild prescriptivism that can be found in this thread, which I think completely misses the point. The footnote from the original post I find especially infuriating:

sloppy with their written communication, which is to say "careless and unsystematic; excessively casual".

Casual speech is not sloppy! Choices of punctuation, capitalization, and so on are deliberate.

As soon as I saw the title I remembered this Julia Evans post about the same issue: https://jvns.ca/blog/2015/11/21/why-you-should-understand-a-...

The cheapest tool you can find is surely the sort in your programming language's standard library. Writing your own sort seems crazy to me.

I don't know why everyone is convinced this is satire. Satire of what? To me it reads as a straight piece on a very opinionated way to hire people.

I think it's best to use native speakers as oracles: you can give them a piece of language and they can tell you if it's correct/natural or how they'd phrase it. You can't expect people to go beyond that, and trying to explicitly systematize the grammar isn't necessarily important or that valuable anyway; you need to internalize the grammar (as one has done with a native language) and that's not a conscious process.

Fires have health and economic impacts on people who aren't in immediate danger of being burned to death and the only way to minimize these impacts to reduce the number of fires.

Reducing the number of fires isn't really a viable strategy; the flammable material just accumulates more and more. California has always had wildfires, they're just a part of the ecosystem. A lot has been written lately about how the strategy of trying to suppress every fire the last century is a big part of why we have so many giant, out-of-control wildfires now.

A min heap is different from a min-max heap. A min-max heap supports the operations of both a min heap and a max heap (essentially by interleaving the two). A normal min heap is a standard data structure, a min-max heap less so.

Yes indeed. Say you're creating a new component, and this new component will contain (among other things) some existing component, but the existing component needs to be styled slightly differently in this particular context. How do you deal with this with inline styling? Threading around this information between the components in JS to make the old component aware of the new one seems clearly wrong. A good old-fashioned style sheet handles it easily and relatively cleanly.

I've seen that inline CSS seems to be the latest trend, but I haven't really read up on why myself. Is this post really the current thinking? I find it completely uncompelling.

Originally one point was that you signed the back of your card and the merchant would compare the signature on your receipt to the signature on the card to verify your identity. Another point was so the merchant has proof you intended to pay them.

When I was living in the UK (which wisely uses a more sensible PIN system instead of signatures) I was shocked the first time someone asked to see the back of my card. I don't think it's ever happened to me in the US. Culturally we've collectively decided to ignore the whole "signature verification" thing, but when using your card abroad you sometimes are reminded that it's supposed to happen in theory.

You're confusing two different things. Ye as a plural pronoun is a bone fide archaic English word, ultimately sharing an etymology with the still-extant "you". "Ye" as an article ("Ye olde...") has the history you reference, where the y comes from a stand-in for a thorn (th), and so was not supposed to be pronounced as "yee". But ye as a pronoun (by far the most common usage, I think, and the usage in the poem) is just a normal word and doesn't share that history.

Fun idea!

I will say that the interface feels a bit mobile-first to a fault: the swiping interaction isn't very desktop friendly. It'd be nice to have some buttons to click on for those of us using mice or trackpads.

No, because it's not scientific. There's no agreed upon definition of what counts as a unique word. Do you count every inflected form, like "dog" and "dogs"? Derivations from other words? Homonyms? Compound words? How do you deal with archaic or obsolete words? And so on...

That's what open and curve mean in topology. For example, the set of x with 0 <= x <= 1 is open, whereas 0 < x < 1 would be closed. It's infamously confusing terminology, since sets can be both closed and open, or neither...

You have it backwards; [0, 1] is closed and (0, 1) is open. This gives the terminology "open interval" and "closed interval".

The confusion about "why does a closed curve have no boundary" likely comes more from the word "boundary". The point is that for an n-dimensional object, the boundary is (n-1)-dimensional. For a curve, which is 1-dimensional, the boundary is 0-dimensional, ie points-- so we're looking for endpoints, and a closed curve doesn't have any.

Indeed, the idea of 200 points in 16 days is more or less absurd, at least beyond beginner levels. In fact, looking at the author's Lichess profile I see no evidence of any improvement at all, to be blunt.

Improvement takes really a lot of work, far more than I think the author appreciates. Going from 1800 to 2000 in a year would be an excellent outcome and would require hundreds of hours of work on chess.

The author dismisses the one method that is arguably most recommended by strong players: studying GM games. Chess is about playing good moves, and studying the games of the world champions helps you learn what good moves look like. Studying GM games is hard work with little tangible reward (no dopamine rush from finishing a puzzle or playing a quick game) but it seems highly effective.

Another thing that stuck out to me: the author dismissed tactics puzzles based on what looks like 30 puzzles done on Lichess. That's nothing. I've done 7500 tactics on Chesstempo standard mode alone and it did a lot for my chess. It was basically the only thing I did to go from 1300 to 1600 or 1700 or so (over the board). Tactics aren't a panacea for chess improvement, but neither is anything else.

I have some smaller comments (for example: re: "If I want to get difficult puzzles correct, I don’t rely on any pattern recognition. I just spend a lot of time and mental energy explicitly calculating out every combination of moves. I’m really not learning much, most people can get the same puzzle correct if they just thought as hard as I." -- pattern recognition is the basis for calculation skill so it doesn't make sense to say you don't rely on it when calculating) but the main point is that chess is hard and improving takes a lot of hard work, far more than the author makes it seem.

Both of these are good points. 90 day exercise windows are both unnecessary and terrible for employees and we should move to eliminate them as quickly as possible. I think the trend is slowly in that direction, but it really should just be a deal breaker for engineers.

The limited information is also a good point. Some level of saviness and understanding of your company and market can help with some parts of this but certainly not all.

If anything this may be a good argument for working at late stage private or smaller more volatile public companies. Then if you get lucky and get, say, Square from two years ago, whose stock has gone up 7x, you capture this upside (and if they do poorly, roll the dice again after a year, perhaps). This is quite mercenary and might not be the route that makes one happiest, though.

I don't see why this follows. I said "in expectation". So some % of the time it's going to be 0 or thereabouts and some % of the time will be much higher. The best case scenario needs to be multiples in order to make the average work out, but I don't see any reason the average case needs to be.

For the purposes of this thought experiment we're assuming that there's no price movement after year 1. In the real world this probability of failure in the future should be priced in to the year 2 price and doesn't affect the expected value anyway.

I'm not really interested in arguing about these numbers, it's not really relevant to my point. I was basing this off of https://www.teamblind.com/article/google-engineer---total-co... where 250-350 includes the majority of L4 and L5 engineers. Based on this your numbers look off by one level or so, at least for Google. But again, I don't think this is very important for my point.

Yes, I mostly agree.

There's one nuance that I've been thinking about lately that I haven't seen anyone ever point out before, which is that high volatility will make options worth more than they are on paper.

Here's a thought experiment: imagine that there are two employers on the market. One will always pay 200k/yr guaranteed and you can choose to work for them at any time for this wage. The other pays 100k/yr plus one Coconut per year, and Coconuts are currently worth 100k each. So far these are equivalent monetarily. But now let's add the stipulation that after one year, the price of coconuts has a 50% chance of going to 0 and a 50% chance of going to 200k each. Which would you choose?

The expected value of each of these job offers is still equivalent (after 4 years of working at each, you'll have 800k in expectation). But you should definitely take the second one. Why? Because after one year, if coconuts drop to 0, you can just quit and join the first company. Then you have a 50% chance of 100 + 200 + 200 + 200 (coconuts to 0) and a 50% chance of 300 + 300 + 300 + 300 (coconuts to 200) which comes out to 950k, which is better than sticking with either company alone.

This thought experiment fascinates me because it clearly shows the extra value that up-front stock grants have. The point is that you have some protection from downsides in the form of switching jobs, but no similar cap on the upsides, and the higher the volatility of the stock the more value this provides.

I'm not sure what the numbers look like when you view them through this lens, but it does mean that an equity grant of 2% of a 6M company should trade off for more than 30k/yr.