Lee Robinson

I've been a big fan of Lee Robinson's website, which is built with Next.js: https://leerob.io/ * Stylistic enough to have some heart, but simple enough to not have the design get in the way * Great content, his blog posts are a good mixture of technical and general thoughts * I like his timeline on the about me page which provides some flavor to his experience. As I was working on my personal site I was peeking into his github repo pretty consistently to see how he structured certain things.

"leerob" - Lee Robinson who works at vercel [0]. It would have been nice to disclose your affiliation, especially when spreading misinformation. https://leerob.com/

Hey! Thanks for the kind words and glad you're enjoying Next.js. It's (basically) impossible for us to recommend a _single_ state management solution for all users, because state management means different things to different folks. Depending the industry and scale of your application, it also changes your state management needs. I wrote an in-depth guide on this here: https://leerob.io/blog/react-state-management

I actually appreciate domain-specific programming languages. It's fine (for me) that JS is the native front-end language. It's fine that Rust targets systems and embedded. I love that Python is a middle ground, and really great backends are built on it. I'm great with C being a really low level language that forces me to think about the machine. Taking "I'm productive in it so it is great" to an extreme, we end up seeing precisely the kind of domain crossover TFA hints at. Somehow, since Rust is cool, it should be the future of web / in-browser[1]. Somehow, since JS is popular and easy to use, it should be on the james web space telescope[2]. Somehow, since browsers are well accepted, node.js is a reasonable benchmark for embedded systems performance [3] GTFO with that. That is how we get language bloat and the many overlapping frameworks that creep into the language and make it unrecognizable. I'm looking at you, Tokio and D3. 1. https://leerob.io/blog/rust 2. https://old.reddit.com/r/programming/comments/bglvey/the_9bn_james_web… 3. https://jaycarlson.net/embedded-linux/

Hmm What's 'awhile'? Months? Years? This one had something recently about teams making decisions: "Don't swoop and poop" 5 things I learned from 5 years at Vercel https://leerob.com/vercel

Sure thing! Bit of cloud computing history. Covered a bit here: https://leerob.io/blog/heroku

Rust is the future of tooling [0]. While [0] is about JS tooling specifically, we're seeing the same effects in other languages as well. Turns out, you probably don't want to write infrastructure tooling in slow, dynamically typed languages when faster, more safe languages exist. Python knows this already, with much of the scientific computing libraries being just wrappers over the core C++ codebases. JS is beginning to catch up as well, with swc (speedy web compiler), stc (speedy type checker), Turbopack (Webpack successor) and so on, with Vercel leading the charge mainly. [0] https://leerob.io/blog/rust#the-future-of-javascript-tooling

Very excited to see the Rust-ification of Python tooling, similar to what we’re seeing in the JavaScript[1] tooling ecosystem. [1] https://leerob.io/blog/rust

Rust (and other fast, compiled languages) is the future of Javascript infrastructure [0]. Whereas before one might have thought that a language's tooling should be written in said language, there might come a time when that's too slow, and we instead need to move to faster languages. That's what has happened to Python (numpy, pandas, scipy etc are all written in C and simply provide an interface in Python), and now it's happening to Javascript as well, with Deno, swc in Rust, Bun in Zig, esbuild in Go, and so on. I foresee a future where we won't have to deal with slow tooling and can have instantaneous updates once again. [0] https://leerob.io/blog/rust

Agreed on highlighting with a different background color. Unfortunately, it can be difficult to find a background color that is different-enough from the usual background while maintaining a high enough contrast with the text sitting on top of it. This is especially true if your syntax highlighting color palette covers all the hues you could use. So here's another protip: Make the highlight pop with a brighter left-border, so your background color doesn't have to pop so much on its own and you have more wiggle room to maintain contrast. Something like what mdx-prism has in their readme image [1], though I don't like the specific blue-on-blue colors. This blog article [2] has an example in the middle with nicer colors. [1]: https://github.com/j0lv3r4/mdx-prism [2]: https://leerob.io/blog/mdx

Thanks for asking! A couple of reasons. From my perspective: • I like writing in Notion. It feels like I'm getting more writing done than I do elsewhere. • It hits the sweet spot as it allows me to A) write & format code-focused content, B) link to other (sub)chapters, and C) create compelling guides thanks to the variety of "building blocks". • It's nicely designed and permits customization (blocks, callouts, colors, font families, etc) while sensibly constraining you so that you don't go "too far" with the design. • I can assign read-only permissions relatively easily (I wrote about how I automated it here: https://www.indiehackers.com/post/how-i-published-a-notion-ebook-and-a… • Last but not least, I studied Janel's journey on publishing a Notion resource (basically a dashboard) on Indiehackers: (https://www.indiehackers.com/product/newsletter-operating-system) and saw that it works! So I did my own thing. From my readers' perspective: • Ppl usually don't read Elasticsearch guides on a kindle on a beach in Southern France. They do it on the computer while integrating / debugging something. So they pull up the online Notion workspace, search thru it, and (hopefully) gain some insights. • Since it's online, it can be updated / extended / typo-corrected at any time. • The handbook includes images that won't work on kindle and videos that don't really work in PDFs. • Last but not least, ppl can't really…

You realize that this approach is flawed the moment there are blogposts / books ( e.g. Cracking the coding interview ) on how to crack it. The how to crack 'x' becomes a field altogether ( coaching / youtube videos / blogs / books etc ). Also, platforms like hackerrank are adding fuel to fire. I read the CEO write somewhere that he wished the below "were taught in schools : 1) Communicating complex ideas with clarity 2) Systems thinking 3) Grunt work tasks 4) Boundaryless thinking 5) Self-awareness / EQ" Please note almost all of these are not evaluated on their platform (they profit from coding tests) or during interviews and almost all are soft / intangible skills (skills which are not immediately obvious about the candidate during a typical programming interview). [ Side note : some could say that coding tests are the problem they have chosen to solve - in which case, why are they worried about these skills ? Are the companies seeing coders crack the tests on their platform, while not performing well on the above skills post hiring ? We could only speculate. ] All good work is done by teams, and to be effective in a team requires a lot of intangibles which aren't even assessed in a typical interview. A better approach could be from this article: https://leerob.io/blog/technical-recruiting-is-broken/ Or : A couple of weeks of work with a task being assigned and the mentor or interviewer looking at how the candidate is approaching the problem and whether he is able…

This is frankly a rather mediocre article, and exists more as a plug for a company's service than really useful advice. For one thing, with function components there is no `this`, so tip #2 is useless (and this is especially odd given that the other tips talk about using hooks, which _only_ work in function components). There's many other articles that are much more useful than this one. To point to a few off the top of my head: - https://alexkondov.com/tao-of-react/ : a useful list of patterns and practices when writing React code - https://leerob.io/blog/react-state-management : a recent summary of how React state management approaches have changed over time, with some current suggestions - https://daveceddia.com/react-ecosystem-overview/ : a summary of the React ecosystem as it currently stands and I personally have put up a lot of material over the last year that is _much_ more useful than this: - https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-com… a deep technical dive into how React rendering works (when, why, how, and nuances in behavior), including looks at how Context and React-Redux interact with rendering - https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ : a comparison of the capabilities and use cases for React's Context API, the `useReducer` hook, and Redux/React-Redux - https://blog.isquaredsoftware.com/2020/12/presentations-react-redux-ts… : an updated intro to…