4 ms·

I feel like you can cheat really hard with modern frameworks. Take something like .NET7 for example. You can get very far into some product before you need a pi

I feel like you can cheat really hard with modern frameworks. Take something like .NET7 for example. You can get very far into some product before you need a piece of functionality that is simply not available in the first-party tool set. If we wanted to NIH all the things, we'd have to start doing crazy shit like implementing our own JSON serializers or hand-rolling artisanal CSPRNG/SHA algorithms. We'd almost have to want to make our lives harder on purpose. There's no way we could make it look like it was in pursuit of a grander product outcome when the obvious answer is already being pushed on us by intellisense. We could try to lie to ourselves about all of this or paint various vendors in pale hues of evil, but none of this is fun or feels like much progress. Starting with something that includes nearly 100% of the batteries takes a lot of the temptation out of the way. You won't even begin the dangerous "should I write it or vendor it" adventure because you will be so distracted with all of the features you are shipping.

thefaux 4y ago
> If we wanted to NIH all the things, we'd have to start doing crazy shit like implementing our own JSON serializers or hand-rolling artisanal CSPRNG/SHA algorithms. These two are not analogous. Writing your own JSON deserializer/serializer can absolutely make sense depending on what you are doing. You'd better have a very good reason for writing your own sha algorithm. Any sufficiently gifted programmer will reach a point where they realize that there is no third party tool that is quite right for the specific problem they are solving. The art is in identifying where exactly the line is. Personally, I tend to fall in the batteries not included camp but this only works in a high skill/trust environment, which frankly is not companies. You're probably right that in most cases preferring batteries included is a better default disposition. But almost definitionally these types of places will tend not to be technologically innovative.
- bob1029 4y ago
  > These two are not analogous. Writing your own JSON deserializer/serializer can absolutely make sense depending on what you are doing. You'd better have a very good reason for writing your own sha algorithm. I mostly agree with you, but to me this is presented as a logically-inconsistent argument. Why is writing my own JSON serializer relatively better than writing my own SHA implementation? Don't we first need to look at the actual problem? Why does it have to be a very good reason, as opposed to simply the same quality of reasoning used for the JSON decision?

thefaux 4y ago

> If we wanted to NIH all the things, we'd have to start doing crazy shit like implementing our own JSON serializers or hand-rolling artisanal CSPRNG/SHA algorithms. These two are not analogous. Writing your own JSON deserializer/serializer can absolutely make sense depending on what you are doing. You'd better have a very good reason for writing your own sha algorithm. Any sufficiently gifted programmer will reach a point where they realize that there is no third party tool that is quite right for the specific problem they are solving. The art is in identifying where exactly the line is. Personally, I tend to fall in the batteries not included camp but this only works in a high skill/trust environment, which frankly is not companies. You're probably right that in most cases preferring batteries included is a better default disposition. But almost definitionally these types of places will tend not to be technologically innovative.

bob1029 4y ago
> These two are not analogous. Writing your own JSON deserializer/serializer can absolutely make sense depending on what you are doing. You'd better have a very good reason for writing your own sha algorithm. I mostly agree with you, but to me this is presented as a logically-inconsistent argument. Why is writing my own JSON serializer relatively better than writing my own SHA implementation? Don't we first need to look at the actual problem? Why does it have to be a very good reason, as opposed to simply the same quality of reasoning used for the JSON decision?