jmcomets

Obvious caveat: pushing this a bit further it can quickly fallback to the default case. The optimizer is a superpower but you still need to try to write efficient code.

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

Results in:

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

(armv8-a clang 21.1.0 with O3)

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?

Still is. It's a French/Lebanese corp based in Paris/Beirut. I worked there for a few years early in my career.

1) C++: 7+ years; Rust: 3+ years.

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.

Another fact not mentioned in this article is the WWII historical locations found in the unofficial Catacombs. Back when I lived in Paris, I was lucky enough to know someone who had access to one of the Cataphiles' maps (yearly-updated with notes on entrances and potential police patrols, with closest exits and dangerous passages).

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.

My pet theory is that programmers are exposed to many business areas during their career, either directly or hearing it from other programmers. This desacralizes these jobs, and since we spend most of our days working though complexity (requirements, bugs, ...), you end up with "what's so hard about X?" statements.

> Work relationships matter, sharing 3D space allows people to be more creative and collaborative, and companies are recognizing that. Google seems like the last company that would make people come back to the office without doing their homework, there’s clearly data showing that fully remote employees are falling behind.

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.

FWIW, most DBMS have built-in index usage stats, and it's not too difficult to query. In my previous job we had a Postgres health dashboard that notably showed `log10(index size) / index hits`, making it pretty clear when some recently added index was useless.

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.

In my experience these type of abstractions end up bloated with too many concerns which adds maintenance overhead. It's a lot simpler to simply add a `HashMap<Book.title, Book>` and cover with tests, than use an abstraction.

I want languages to do less magic, not more, since I read code more than I write it.

> Why does writing in the morning (anecdotally so far) seem to be so effective for writers, even ones who are not morning persons? While programmers, which seems like a similar occupation, are invariably owls?

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.

To add some praise on this topic, I like (in no particular order): - having dedicated no-meeting days to work on stuff I'm paid to build - being able to talk vision with my PMs (and be listened) - having a budget for software maintenance and developer QoL - not having to do all the software testing on my own - run live experiments with users to test out new ideas

Disregarding the "code is doc" position, it's still common to have an overview or index for documentation, which points readers in the right direction instead of dumping pages of detailed docs on them.

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".