I wouldn't consider this "a few buttons", it's enough to turn off the less savvy users

    unsigned add_v5(unsigned x, unsigned y) {
      if (x == y) return 2 * x;
      return x + y;
    }

    add_v5(unsigned int, unsigned int):
      lsl w8, w0, #1
      add w9, w1, w0
      cmp w0, w1
      csel w0, w8, w9, eq
      ret

If compiler folks can chime in, I'm curious why incrementing in a loop can be unrolled and inspected to optimize to an addition, but doubling the number when both operands are equal can't?

2) C++, my employer's choice. Their rationale: easier to hire people with experience, internal codebase is mostly C++ so tooling/people more versed.

3) Rust. For me it's just easier overall to work with. It takes me an hour or so to get my head back into Rust's standard library and idioms/quirks, but afterwards it feels much better to work with: dev. workflow, testing, expressiveness. Plus it catches programming errors for me every once in a while.

4) I wish Rust had wider adoption by the industry. It's always compared to C/C++/Java/Go and the usual argument boil down to "not enough people use it".

5) I wish C++ had better compiler error messages. I have to rely on instinct when it's not scrolling through nested template/SFINAE errors to understand what's happening. Rust tells me "here's what's wrong" 99% of the time.

We visited an old school basement, which was used as a bunker for members of the Resistance. The school itself was razed and rebuilt over at some point, but the Catacombs still hold traces of this period. Being there felt very...intimate. Nothing like you'd see in a museum or a documentary, we were in the same place as those back then.

A couple things I wanted to point out when reading this:

- RTO does not imply sharing a 3D space with those you collaborate with (e.g. distributed teams).

- There is no data that proves that in-person work is more "creative" or "collaborative", simply because it's not measurable.

- You assume Google's intentions to always driven by data rather than appealing to stakeholders.

Also consider who would be more likely to respond in this thread: people heavily invested in or against remote work (since there is no actual data). Always-relevant XKCD: https://xkcd.com/386/

[0]: https://en.wikipedia.org/wiki/HashiCorp

My opinion is that indexes should be either logical (ex: used for exclusion constraints) or purely for performance (tradeoff space for better QPS). Query patterns change, specs change, so monitoring your DB's performance is the way to go.

Also anecdotal, but I've met my share of early bird programmers. I often wonder how much of these habits are driven by ~~stereotypes~~ culture, since theoretically your energy level depends mostly on your lifestyle.

Now, you could also have a well organized test suite that goes from most obvious to most detailed, split into sections for each use-case, but this sounds a lot more tedious than "write a one-line comment describing the unit test".

I bought a Fitbit Charge 4, originally to track my heart rate/steps since I've never owned one and always relied on my phone for time.

With my phone generally on silent and by not checking it so often, I've found my use of social media/apps has reduced drastically this year. To the point that I recently forgot my phone at home, something that I didn't imagine possible.

Nowadays it's still used as a French expression to describe a "seemingly impassable defense that's useless in the end".

The downside of this approach is that for subtrees of shared behavior you can go the multi-level inheritance route (risky if you're not sure the leaves will hold their parent's contract) accept the extra boilerplate for similar behavior.

It's interesting to me how this happens quite often and polymorphism is still our go-to solution.

The more interesting bit is that subtle orbital adjustments require much less dV in higher orbits than in lower ones.

I like to think of it like pushing a barrel uphill: it takes more effort if the slope is steep, but then once it's up there, it's a lot easier to get the barrel moving downhill.

Anyways, the "de-orbit" cost follows the same rule of higher being more costly in dV, the big difference with an ascension being that the atmosphere slowing you down is what you want (aerobraking is the word, I think?). So the difference in dV between a high orbit and a low orbit descent isn't proportionate to that of the ascent, if that makes any sense.

Glad to hear there were breakthroughs in the field, thanks for the heap of links for me to delve into. :)

[1]: https://github.com/dcoeurjo/ThicknessDiag