macobo

In practice product requirements can get in the way of technically ideal solutions. One example of this is that analytics products allow users to pass in and analyze arbitrary number of user properties to do analysis on - more than even a columnar database can handle. The current solution of storing JSON as a column indeed has a very significant performance trade-off, but it's also needed to power queries users need to run. This is also why we're really excited about the new Object data type that landed in 22.3 as it handles these cases gracefully by creating dynamic subcolumns.

On JOINs - again, requirements bite us in different ways. Product analytics tool data ingestion pipelines can get quite complicated due to needing to handle merging anonymous and signed in users and user properties changing over time. Handling that via JOINs is as a go-to-market helps avoid that upfront cost by centralising the logic in SQL, but indeed does come with a significant cost in scalability. Delaying in turn allows you to be building tools users need. That said every loan needs to be paid at some point and we're currently knee deep in re-architecting everything to avoid these joins.

Also note that JOINs don't work the way you described from our experience - rather the right hand side of the join gets loaded into memory. The bottleneck there is memory pressure rather than I/O with a good ORDER BY on the table.

All that said, what a great summary of all the different things to keep an eye on. Thanks for reading and sharing your thoughts!

> I'm convinced the only people who have good things to say about using linux (or BSD for that matter, been there done that, no thanks) on a laptop are the kind of people who keep their "laptops" on the same desk, plugged in to ethernet, and are effectively using a desktop with poor thermals

Good for you for making your own decisions, but don't be a condecending arschloch. Personally I prefer linux because it works fine and consider Apple is overpriced piece of spyware and many their users smug idiot hipsters.

Happy holidays!

Examples, suggestions?

Why take 60% of the rating space up by negative ratings? It seems like what you really care about is degrees of goodness.

An alternative approach:

1 - I disliked it. 2 - It's OK 3 - This is good 4 - This is great 5 - This is a must-read

This smells a lot like meteor. Would love to see an actual semi-large app built with this approach.

How so? The code still documents what is happening, the commits however lay out the whys.

The point is that these two are separate questions, and that trying to use comments as a crutch to join the two religiously is a headache. It's impossible to keep everything in sync and I don't want to read needless or worse misleading information.

What's worse, in comments we often omit the important details such as why was the change made, what other choices were considered, how was the thing benchmarked, etcetc.

That said, comments still have a place. Just not everywhere for everything and especially not for documenting history.

There's an infinite amount of detail that's impossible to capture in a comment and which invariably changes over time and doesn't hold in the future.

For my team, the solution has been writing longer commit messages detailing not only what has changed, but also the why and other considerations, potential pitfalls and so forth.

So in this case, a good commit message might read like:

``` Created square root approximation function

This is needed for rendering new polygons in renderer Foo in an efficient way as those don't need high degree of accuracy.

The algorithm used was Newton-Raphson approximation, accuracy was chosen by initial testing:

[[Test code here showing why a thing was chosen]]

Potential pitfalls here include foo and bar. X and Y were also considered, but left out due to unclear benefit over the simpler algorithm. ```

With an editor with good `git blame` support (or using github to dig through the layers) this gives me a lot of confidence about reading code as I can go back in time and read what the author was thinking about originally. This way I can evaluate properly if conditions have changed, rather than worry about the next Chthulu comment that does not apply.

Note that working remotely takes some getting used to just as with working at an office. Yes, you can dump someone into unfamiliar conditions and draw conclusions from that, but that's just confirming your prior assumptions without actually trying.

But you just said this:

> I've looked at large articles I contributed to a few years ago and they are now disasters.

Examples would be welcome.

Would you mind elaborating on what sort of remote positions yelp offers. Here's a few common ones:

- It's okay to work from home a few/most days of the week. - Anywhere, same working hours for everyone - Flexible working hours, limitations (i.e. must have N hours of overlap and be in US/CA) - Globally distributed organization