4 ms·

I don't buy the overall structure of this argument: system X is very very complex, so you should never try to do it yourself, instead use an off-the-shelf solut

I don't buy the overall structure of this argument: system X is very very complex, so you should never try to do it yourself, instead use an off-the-shelf solution for X. Perhaps the general case of X is enormously tricky and complex, but in my use case I only need to handle a specific subset of the complexity. Therefore I can build my own solution that only handles the complexity I need, and it will be much simpler than off-the-shelf tools. I absolutely adopt this stance for X=datetime. My approach to datetime requires two function calls to be provided by the library: convert an epoch time to an ISO formatted time string in a particular TZ, and the inverse. I never touch any other library code; I do all other time manipulation in my own code, in terms of those two functions.

makeitdouble 3y ago
> in my use case I only need to handle a specific subset of the complexity Thing is billing money leaves very little room for error and is regulated. From the start you'll need to understand all the dos and don't of personal info handling, the cycles and lifetime of the different billing options, cashback thresholds, support idempotency, sane DB transaction management with models that are adapted to the task, invoicing and exposing that to your client etc. It's not everything at once, but at least half of it just for your first workable implementation.