mulholio

It’s certainly been my experience that page sizes should be bigger than you initially expect. Paginated endpoints are typically iterated all the way through meaning you’re going to return that data anyway. May as well save the additional overhead from multiple requests.

Not implementing pagination at the outset can be problematic, however. If you later want to paginate data (e.g. if the size of your data grows) then it’s going to be a breaking change to implement that later. Big page sizes but with pagination can be a reasonable balance.

I had a beloved F91W that I used for years. One day, when surfing in Morocco, it gave out and the screen became foggy before showing me an error code and never recovering. I guess I should have gone deeper.

Although I'm only on job three and have not had that much involvement with open source, I think my current employer (Attio) has one of the best codebases I've seen.

Qualitatively, I experience this in a few ways: * Codebase quality improves over time, even as codebase and team size rapidly increase * Everything is easy to find. Sub-packages are well-organised. Files are easy to search for * Scaling is now essentially solved and engineers can put 90% of their time into feature-focused work instead of load concerns

I think there are a few reasons for this:

* We have standard patterns for our common use cases * Our hiring bar is high and everyone is expected to improve code quality over time * Critical engineering decisions have been consistently well-made. For example, we are very happy to have chosen our current DB architecture, avoided GraphQL and used Rust for some performance-critical areas * A TypeScript monorepo means code quality spreads across web/mobile/backend * Doing good migrations has become a core competency. Old systems get migrated out and replaced by better, newer ones * GCP makes infra easy * All the standard best practices: code review, appropriate unit testing, feature flagging, ...

Of course, there are still some holes. We have one or two dark forest features that will eventually need refactoring/rebuilding; testing needs a little more work. But overall, I'm confident these things will get fixed and the trajectory is very good.

As a non-systems engineer, I’ve found Julia’s blog immensely helpful. She does a great job of explaining a wide range of topics and also tackles soft skills very well

Going to test this out on Hinge voice prompts and see what happens

Damn, this looks great. I'm very happy with my ErgoDoxes but the domed keys on this would make me seriously consider it if I were buying today. IMO, the split keyboard is super important for not messing up your shoulders with hunched over typing.

Just wait until you hear about git blame

Next.js really isn't that bad. If you need SSR, it is definitely the best way to go.

Good to hear! If that's the case then I'm excited.

Next.js has been very good for not introducing breaking changes in my experience (especially for the JavaScript ecosystem). The changes are more along the lines of lots of new and useful things (e.g. image optimisation) as opposed to problematic maintenance issues.

I agree cookies can be a bit awkward with Next but I've always found a way around.

I get the sense the React team don't really care about SSR as it's not a massive use case for FB.