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.

I've gotten a lot of use from a version of Zettelkasten in Roam recently.

The general idea is this.

1. Take "Literature Notes" in your own words as you consume content. These are little summaries of ideas in the text that are usually 1-3 lines. For paper books, I do this in a little Muji notebook. For digital resources, these go straight in Roam. 2. When you have finished the resource, copy your notes to one page and summarise them in "Permanent Notes". 3. Keep your Permanent Notes in one Permanent Note page and link everything together.

The best guide I found for getting this kind of system set up was https://www.nateliason.com/blog/smart-notes. The original "How to Take Smart Notes" book is also good, but much less concrete.

Really, I found step 1 to be the most valuable. I was previously processing highlights from articles and books and that weirdly took more time. Writing little notes as you go along saves only what is relevant and it's much more direct for your use cases.

As a word of warning though, I really haven't gotten this stuff to work very well for programming (or disciplines where you need to exercise knowledge rather than archive it in a system). I either find I need to memorise the stuff more directly with Anki, or having to practice skills in a real world context.

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.

I think create-react-app is much more beginner friendly. Fewer concepts to learn. Rolling your own or using script tags to begin with is also an option (see this course for an example: https://egghead.io/courses/the-beginner-s-guide-to-react)

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.

> That's what srcset & <source> were invented for.

Next.js is going to be using srcset under the hood, I'm sure. The whole point of Next.js is to make best practices like this defaults, not to do anything groundbreaking and new.

Do you have any good examples of how this has worked well for you in the past (ideally, off the job)?

Some of my favourite internet-specific books:

- The Dream Machine. Fantastic tech history coverage with a particular focus on the lead up to the internet https://press.stripe.com/#the-dream-machine.

- Tools for Thought - Lots of similar ground to the Dream Machine but with a less internet-centric focus. Still great though - https://www.amazon.co.uk/Tools-Thought-History-Mind-Expandin...

Perhaps not internet focused, but tangential/technology:

- The Idea Factory: Bell Labs and the Great Age of American Innovation

- One Giant Leap (Apollo Missions. Decent amount of computing foucs)

- Steve Jobs, Walter Isaacson

- Organizing Genius: The Secrets of Creative Collaboration. Lots of interesting snippets of tech and non-tech history

I'm paying $35/year but I think it's still worth it. Solid integration with my Mac and iPhone.

Came here to comment on how good this one was, thinking this was what the post was about. 10/10 work on this project, never ceases to amaze me and my coworkers.

Learning haskell, getting some writing done, trying out some hacking/info security.

What I'd hoped to see here was why use Svelte for a large web project. I get the advantages, but devising and maintaining good architecture is hard enough in the more established React paradigm. What do complex and older Svelte apps look like? This is the part that's missing for me, not pleasant DX and early-web nostalgia.

Memrise | Frontend Engineer | ONSITE | Full-time | London

Memrise are looking for a Frontend Engineer to join our small, autonomous Web Squad. Lots of work on an exciting language-learning product with a fresh stack (TypeScript, Next.js, styled-components).

Apply link here: https://apply.workable.com/memrise/j/5422043DFB/

Agreed that the split keyboard doesn't really make a difference for RSI. It helped my shoulders far more than my hands/wrists. That said, the extra angling that many split keyboards give you is pretty nice, even if it's not the split itself that helps.

I weirdly found the opposite: hovering was far better for me. I always found that resting the wrists encouraged bad typing habits and angles.