Fabio Manganiello on Nostr: Literally 90% of my development and sysadmin time lately is spent handling breaking ...
Literally 90% of my development and sysadmin time lately is spent handling breaking changes - no exaggeration.
If you're a developer, always, ALWAYS think not once, not twice, but at least 10 times before introducing a breaking change.
Supporting two or more sets of arguments, return types or type names in your API may be a bit painful or not that elegant.
But trust me, it's way more painful for hundreds, thousands or even millions of users down the line to have to adapt their code, scripts or configuration files to your breaking changes.
Especially when the whole world doesn't revolve around your software, and your project may just be one in hundreds of projects that a user downstream has to manage on their machines - all of them feeling entitled to introduce breaking changes whenever they like, all of them expecting users to regularly read their changelogs.
Breaking changes are literally the biggest act of selfishness and self-entitlement that a developer could dump on users.
If you're a developer, always, ALWAYS think not once, not twice, but at least 10 times before introducing a breaking change.
Supporting two or more sets of arguments, return types or type names in your API may be a bit painful or not that elegant.
But trust me, it's way more painful for hundreds, thousands or even millions of users down the line to have to adapt their code, scripts or configuration files to your breaking changes.
Especially when the whole world doesn't revolve around your software, and your project may just be one in hundreds of projects that a user downstream has to manage on their machines - all of them feeling entitled to introduce breaking changes whenever they like, all of them expecting users to regularly read their changelogs.
Breaking changes are literally the biggest act of selfishness and self-entitlement that a developer could dump on users.