Hacker News Reader

I did wonder how much to soften this message, because yes, of course, there really ARE times when a breaking change is necessary. But I think those account for maybe 1% of the major releases we see these days. The rest are down to laziness, carelessness, or just not having thought about it at all.

View on HN

This is an extremely uncharitable way to characterize how our understanding of a problem, our requirements, etc evolve over time and with feedback from users.

Making a good API is really hard. I think there's plenty of room for discussion about how we should break things, but "just do it right the first time" is not realistic.

And yet, it's what a lot of old-timey software engineers consistently did. Yes, we work in a more complex ecosystem than they did, but I can't shake my sense that 90% of the reason is that they held themselves to a higher standard. Heck, they still do in the Go community, where major versions are still a big deal.

Reply on news.ycombinator.com