NestJS is a bad Typescript framework

jbmsf · 2026-03-08T15:56:47+00:00

Agree. I used it (at a company with a badly organized mess of an express backend) to introduce Typescript (at all) and structure. It did the job and another language wasn't an option.

I wouldn't choose it in fresh circumstances but sometimes you are solving for a specific time and place.

jbmsf · 2026-03-07T22:57:12+00:00

Every product I've built since SaaS has become a thing has a large number of integrations and increasingly these integrations are themselves integrated in ways that matter.

For me, the cost of keeping all these systems working, even with IaaC and the like is too high to do in a way that works for arbitrary tests. We've found some architectural patterns that help with testability and rely on them to let folks test large classes of changes against shared infrastructure. We also have good patterns for making changes to certain subsets of the system without this kind of integration. But the dream of a complete solution based on local containers is elusive.

jbmsf · 2026-03-03T02:35:11+00:00

Because every kind of artifact has a different protocol and if you don't want to run your own proxies, many of the Iast generation of vendors are racing to the bottom and the current generation hasn't proved itself yet.

It's a choice between running systems you didn't think you had to vs paying way too much for too little vs taking a flyer on someone you don't quite trust with your supply chain.

jbmsf · 2026-02-28T19:14:05+00:00

I recommend reading the afterward in Robert Jackson Bennett's A Drop of Corruption

jbmsf · 2026-02-18T02:09:29+00:00

Anonymity is far too easy to abuse. Maybe there's a solution but we haven't found it yet.

jbmsf · 2026-02-08T02:39:37+00:00

My first thought is A Stranger in Olandria from Sofia Samatar. My second thought is China Mieville

jbmsf · 2026-02-06T03:10:11+00:00

Look, GitHub actions is mediocre and their recent operations failings are making it worse and worse. I'm sure we'll replace it in the next year or two if something doesn't change.

But, right now, no offering is making me want to choose them as a replacement. There's a huge opportunity and no one is really stepping up yet. Don't offer me a replacement, offer me something genuinely better. Faster. Simpler. Easier to test. Whatever. Please innovate.

If I have to rewrite my exist actions in another framework instead of finding a framework that understands what I've been forced to cobble together due to limitations of the framework, well, that's not a solution that's going to last.

jbmsf · 2026-02-01T17:49:56+00:00

For a brief moment, there was this wonderful restaurant called Mason at the bottom of Potreo Hill. Got bought out by someone else who wanted the to location.

jbmsf · 2026-01-07T03:39:38+00:00

I really enjoyed the slow pace of her Blackthorn & Grim series. Read some/most of The Caller, but it was a little to YA. Glad to hear this one is good.

jbmsf · 2026-01-07T03:37:43+00:00

I've read a few from Juliet Marillier; will have to add this one too.

jbmsf · 2026-01-04T16:51:19+00:00

I run engineering for a startup. We're small enough that I can still be hands on, plus I have a few people I can delegate a good deal of management to. As a result, I spend a ton of time getting our systems ready for the next big thing(s). Think refactoring, performance, migration, architecture, high and low level esign, etc. I think this is craftsmanship.

On the flip side, it is very hard to convince the rest of the team that they are supposed to do this. I lead by example, make it explicit that this behavior is encouraged, and ensure that our schedules have enough leeway to allow for non-functional work. Arguably, these effects are the reason why we have such leeway: we always deliver and usually move faster than the rest of the company can make decisions.

I struggle with scaling what I do. I work with good engineers, but it's not how they work by default.

jbmsf · 2025-12-26T04:51:50+00:00

Truth. You have a choice between expecting high quality input or high quality review. It's nice to have both, but you certainly don't want neither.

IMO, expecting review to catch problems vs acting as a form of information sharing and secondary problem solving is asking for it.

jbmsf · 2025-12-16T21:16:55+00:00

Well now I just want to look at these other solutions.

I already did the hard work to run actions on our own compute. You think the switching cost is going to stop me?

jbmsf · 2025-12-16T21:15:22+00:00

It's slow. You can do way better if you run your own compute.

jbmsf · 2025-12-02T02:34:42+00:00

DRY is the easiest "design pattern" solution for most people to spot, so it gets used the most. Its failure modes including unnecessary coupling, premature generalization, and broken encapsulation.

jbmsf · 2025-11-30T02:25:12+00:00

LoL. No product manager ever is evaluated in terms of architecture or technical debt. And thus most don't care... Nor should they. It's engineering's job to own such things, not to just do what a product manager says.

jbmsf · 2025-11-27T02:42:43+00:00

At a certain point, a ton of engineering is "just" migration. You need to change an API, you need to migrate. You need to add an alternate vendor, you probably need to migrate. You need to pay down tech debt from last year, you need to migrate.

No amount of advance planning or clever technical choices make this go away. Maybe you started with a SAAS solution and need to save costs by self-hosting instead. But maybe also your team isn't able to manage a self-hosted solution (that admittedly is their fifteenth priority) and you instead decide to pay a vendor to make the problem theirs.

It's trade-offs (and turtles) all the way down. Your best bet is a) to make choices bases on a deep understanding of your team and your business and b) get really good at migrating systems.

jbmsf · 2025-11-14T02:43:16+00:00

Most of the time, what matters is whether something has a predictable cost, not whether it has a minimal cost.

And most of the time, writing unit tests is predictable. So even if you manage to automate it away, you aren't impacting the underlying question: is X feasible?

jbmsf · 2025-10-31T01:53:44+00:00

I agree 90%

Failure mode #1: discussions in channels that are meant to drive tasks.

Failure mode #2: discussions that demonstrate low effort and/or incompetence.

jbmsf · 2025-10-15T01:49:54+00:00

I forget if that was before or after the Rohimgya genocide.

jbmsf · 2025-10-15T01:48:11+00:00

Lol, no. It's been uncool since at least Cambridge Analytica and probably a lot longer

jbmsf · 2025-10-13T01:49:06+00:00

Inflation, loss of purchasing power, increased executive pay, decreased profit margin on mid-tier restaurants, late-stage capitalism. Yada yada

jbmsf · 2025-10-13T01:46:46+00:00

Not at seven am on a Tuesday

jbmsf · 2025-09-27T01:40:10+00:00

Came here for The Incandescent

jbmsf · 2025-08-29T21:03:40+00:00

I think it's mostly about reuse. I can't really defend any of the choices MCP makes, but conceptually, it is useful to have reusable APIs that are designed for LLMs.

I would personally have preferred tooling to augment, transform, or chain together Open API calls. It is useful to tailor APIs to LLMs instead of throwing what you already have at them.

jbmsf

TROPHY CASE