Max Stoiber

I've been using Fig for months now and it's become a must-have on my machine. I particularly love the git branch, npm package and yarn command autocompletion — my previous zsh plugin didn't have those and I use them all day every day. Disclaimer: I invested in Fig recently because I'm such a fan.[0] [0]: https://mxstbr.com/investing

I've been enjoying reading Spectrum's codebase[0]. It's very simple, with little documentation you can understand pretty much what is going on and in the architecture level, is as simple as it needs. The first time I tried to open a PR, I was up and running my feature in a few minutes. Small summary of the features I liked: - Simple documentation - Intuitive structure - Lots of JS best practices, but still simple - Event-driven architecture - A simple API gateway that will just fire events to workers - Properly divided workers (kind of microservices but with lots of shared code) - Monorepo It recently been bought by GitHub(1) and was discussed here(2). The author has talked in his blog about some decisions he took wrong. Super interesting post(2). 0. https://github.com/withspectrum/spectrum 1.https://spectrum.chat/spectrum/general/spectrum-is-joining-github~1d3e… 2. https://news.ycombinator.com/item?id=18570598 3. https://mxstbr.com/thoughts/tech-choice-regrets-at-spectrum/

I wouldn't: https://mxstbr.com/thoughts/tech-choice-regrets-at-spectrum/ Just use Postgres.

Learning tailwind is 30 mins in their online playground. (It’s one traffic jam on your commute.) There are countless blog posts and threads listing the advantages, but it’s better to spend that time using it and you won’t have to take someone’s word for it! From the creator of styled components himself: https://mxstbr.com/thoughts/tailwind/

Thanks blorenz! When working with Max, I was surprised how little he cared which library we use to get the job done. In fact, he's also a big fan of it. [0] To be fair, we use the Tailwind system, but a lot of customizations on top. [0] https://mxstbr.com/thoughts/tailwind/

That does make a lot of sense. I suppose the barrier to entry is a lot lower with Discord. To answer your question it's just a web app so it works on any platform. [1] The author talked a while ago how he regretted not building it with react-native-web. [2] (I'm not affiliated with Spectrum) [1] https://github.com/withspectrum/spectrum [2] https://mxstbr.com/thoughts/tech-choice-regrets-at-spectrum

The spectrum chat team, which GitHub acquired, wrote that they wish they had started with next.js https://mxstbr.com/thoughts/tech-choice-regrets-at-spectrum/

Fyi, the article's title and sibling top-level comment by austincheney may give the wrong impression of what Russ Cox is talking about. His essay is not saying software dependencies itself is a problem. Instead, he's saying software dependencies _evaluation_ methodology is the problem. He could have titled it more explicitly as "Our Software Dependency Evaluation Problem". So, the premise of the essay is already past the point of the reader determining that he will use someone else's software to achieve a goal. At that point, don't pick software packages at random or just include the first thing you see. Instead, the article lists various strategies to carefully evaluate the soundness, longevity, bugginess, etc of the software dependency. I think it would be more productive to discuss those evaluation strategies. For example, I'm considering a software dependency on a eventually consistent db such as FoundationDB. I have no interest nor time nor competency to "roll my own" distributed db. Even if I read the academic whitepapers on concurrent dbs to write my own db engine, I'd still miss several edge cases and other tricky aspects that others have solved. The question that remains is if FoundationDB is a "good" or "bad" software dependency. My evaluation strategies: 1) I've been keeping any eye on the project's "issues" page on Github[0]. I'm trying to get a sense of the bugs and resolutions. Is it a quality and rigorous codebase like SQLite? Or is it a buggy…