This is also partially why I do not log in to work accounts on personal devices or personal accounts on work devices.

> But if it's like "Increased revenue by $18.7M by reducing time-to-first-interaction latency from 2.3s to 117ms, increasing conversion by 47% and LTV by 28%," with the same fidelity on each bullet, I'm very skeptical.

Do you mind explaining why? The former doesn't indicate caring about business impact whatsoever (is this service in the critical path of any online process? Who knows!) while the latter does.

1. code

2. syntax check / build / format / lint (details language dependent)

3. test

and they can hop between 1 and 2 however many times they want.

That's an incredibly uncharitable reading of the parent comment. At no point in history prior to maybe this year could you argue that working in software was gatekeeping, toll extracting, or rent seeking. Being a highly skilled craftsperson creating software for those who can't or don't want to is a very psychologically positive self identification. Lamenting that the industry is moving away from highly skilled craftspeople is also perfectly valid, even if you believe that it is somehow good for society, which is yet to become clear.

https://typescript-eslint.io/rules/no-misused-promises/

> For byte-stream based protocols, the protocol implementation can use a single input buffer and a single output buffer. For input (that is, receiving data from the network), the calling code is responsible for delivering code to the implementation via a single input (often via a method called receive_bytes, or something similar). The implementation will then append these bytes to its internal byte buffer. At this point, it can choose to either eagerly process those bytes, or do so lazily at the behest of the calling code.

> When it comes to generating output, a byte-stream based protocol has two options. It can either write its bytes to an internal buffer and provide an API for extracting bytes from that buffer, as done by hyper-h2, or it can return bytes directly when the calling code triggers events (more on this later), as done by h11. The distinction between these two choices is not enormously important, as one can easily be transformed into the other, but using an internal byte buffer is recommended if it is possible that the act of receiving input bytes can cause output bytes to be produced: that is, if the protocol implementation sometimes automatically responds to the peer without user input.

> The idea behind static_assert is great. You run a check that has no impact on the performance of the software, and may even help it. It is cheap and it can catch nasty bugs. It is not new to C, but adopting the C++ syntax is a good idea.

If you remove that sentence, nothing indicates that you can see you picked the door with the car behind it. You could maybe infer that a rational contestant would do so, but that's not a given ...