3 ms·

This is really reminding me of a cargo cult. I observe that there is a prevailing mindset among software engineers that their peers are always better than them,

This is really reminding me of a cargo cult. I observe that there is a prevailing mindset among software engineers that their peers are always better than them, and if there is a "standard" solution, it will always be better, more performant, easier to use, bugfree, etc. compared to a quick home-rolled version. This is a good thing if you want to contribute to software bloat, but most use-cases can be solved by rolling your own, then adding features as needed. I have a specific example - I wanted to do logging in a program I made. I experimented with adding different loggers to the project but all of them were more complex and harder to set up than what was needed. Ultimately, I've written a logger which does exactly what I need and in the exact same way in a few hours. (the standard loggers needed some finicking to produce output in the format I wanted)

mooreds 3y ago
> it will always be better, more performant, easier to use, bugfree, etc. compared to a quick home-rolled version. You're leaving out crucial time factors: * which is quicker to market * which has the lower maintenance burden Buying, in my experience, wins on those axes. It does, though, depend on the size of the problem, which is a good callout. You rolled your own logger for a known format. You didn't roll your own RDBMS. Also, you experimented with other solutions to determine if they were feasible. That's exactly the kind of experimentation we should all do--survey the problem space before jumping into building something. I daresay you prove the tweet's point. For your problem, your solution was way better than the other options.
- Pannoniae 3y ago
  You are right in the fact that for complex systems, it will always be quicker to use an off-the-shelf solution than making your own. However, for maintainability, the most important metric is the raw amount of code, followed by the engineers' abilities and the code's level of documentedness. So, if you can replicate what you need with a third of the code, you are already in a much better position (and can fix your own code quicker than a third party's!) than if you had to wait for the vendor/a poor guy reviewing your pull request.
eternityforest 3y ago
A standard version, when used the same way as everyone else, has already been tested. You might run into bugs, but I don't see as many as with new things. Performance often doesn't matter that much, because your program often only spends a trivial amount of CPU doing something. I don't really care about a few microseconds to determine a file type given a name, when there's 10x longer to decompress the file and 100x longer to even load the dialog to find it. For the things that the program actually does spend a lot of time on, there's usually a way to optimize it with hardware instructions, GPU stuff, special case algorithmic shortcuts, etc, which are hard and tedious to do for multiple platforms. The ultracomplex solution might be just as fast. Plus, DIY stuff is rarely general enough to be reusable. The standard solution might be hard to set up, but it will probably be less work that writing something from scratch. And it will almost certainly be less work for a maintainer to understand. They probably won't have to learn anything at all, they've seen all the patterns before on every project. DIY is great if you value simplicity just for it's own sake, otherwise I'm not sure I see the appeal. A lot of programmers seem to get into programming specifically because they value simplicity, they like to understand and work with new ideas and complexity gets in the way of understanding, so I see why they might like to about reuse.
- Pannoniae 3y ago
  "Performance often doesn't matter that much, because your program often only spends a trivial amount of CPU doing something. I don't really care about a few microseconds to determine a file type given a name, when there's 10x longer to decompress the file and 100x longer to even load the dialog to find it." I agree with the rest but this is how we are at a point where we have to wait for windows to open. Unlike on Windows NT. It's not a problem of one thing being slow - if everything is being slightly slow, it's a death by thousand cuts.
  - eternityforest 3y ago
    I think most of the problem with waiting for windows to open is a matter of lack of caching, or waiting on some process that could have been parallel, or something like that. Rarely do I ever see a library that takes more than milliseconds to import, or something slowed down on a function only called on a click or every few minutes or otherwise not in an inner loop. I see lots of slow file open dialogs, which I'm told is often because of checking for network drives and things like that. I've seen exactly one library that was causing me so much performance trouble I had to ditch it, and that was an rrules engine. Finding the next occurrence of something like "Every five minutes on Thursday" was taking an insane amount of time, but that's because I was calling it constantly to schedule lots of different things that happened very frequently. I've also seen lots of things be slow because they wait for the network too. But basic stuff that libraries are normally used for generally seem to be fine. I don't think there's any way I could write a faster gaussian blur than Pillow or a faster text search than the default regex libs.

mooreds 3y ago

> it will always be better, more performant, easier to use, bugfree, etc. compared to a quick home-rolled version. You're leaving out crucial time factors: * which is quicker to market * which has the lower maintenance burden Buying, in my experience, wins on those axes. It does, though, depend on the size of the problem, which is a good callout. You rolled your own logger for a known format. You didn't roll your own RDBMS. Also, you experimented with other solutions to determine if they were feasible. That's exactly the kind of experimentation we should all do--survey the problem space before jumping into building something. I daresay you prove the tweet's point. For your problem, your solution was way better than the other options.

Pannoniae 3y ago
You are right in the fact that for complex systems, it will always be quicker to use an off-the-shelf solution than making your own. However, for maintainability, the most important metric is the raw amount of code, followed by the engineers' abilities and the code's level of documentedness. So, if you can replicate what you need with a third of the code, you are already in a much better position (and can fix your own code quicker than a third party's!) than if you had to wait for the vendor/a poor guy reviewing your pull request.

eternityforest 3y ago

A standard version, when used the same way as everyone else, has already been tested. You might run into bugs, but I don't see as many as with new things. Performance often doesn't matter that much, because your program often only spends a trivial amount of CPU doing something. I don't really care about a few microseconds to determine a file type given a name, when there's 10x longer to decompress the file and 100x longer to even load the dialog to find it. For the things that the program actually does spend a lot of time on, there's usually a way to optimize it with hardware instructions, GPU stuff, special case algorithmic shortcuts, etc, which are hard and tedious to do for multiple platforms. The ultracomplex solution might be just as fast. Plus, DIY stuff is rarely general enough to be reusable. The standard solution might be hard to set up, but it will probably be less work that writing something from scratch. And it will almost certainly be less work for a maintainer to understand. They probably won't have to learn anything at all, they've seen all the patterns before on every project. DIY is great if you value simplicity just for it's own sake, otherwise I'm not sure I see the appeal. A lot of programmers seem to get into programming specifically because they value simplicity, they like to understand and work with new ideas and complexity gets in the way of understanding, so I see why they might like to about reuse.

Pannoniae 3y ago
"Performance often doesn't matter that much, because your program often only spends a trivial amount of CPU doing something. I don't really care about a few microseconds to determine a file type given a name, when there's 10x longer to decompress the file and 100x longer to even load the dialog to find it." I agree with the rest but this is how we are at a point where we have to wait for windows to open. Unlike on Windows NT. It's not a problem of one thing being slow - if everything is being slightly slow, it's a death by thousand cuts.
- eternityforest 3y ago
  I think most of the problem with waiting for windows to open is a matter of lack of caching, or waiting on some process that could have been parallel, or something like that. Rarely do I ever see a library that takes more than milliseconds to import, or something slowed down on a function only called on a click or every few minutes or otherwise not in an inner loop. I see lots of slow file open dialogs, which I'm told is often because of checking for network drives and things like that. I've seen exactly one library that was causing me so much performance trouble I had to ditch it, and that was an rrules engine. Finding the next occurrence of something like "Every five minutes on Thursday" was taking an insane amount of time, but that's because I was calling it constantly to schedule lots of different things that happened very frequently. I've also seen lots of things be slow because they wait for the network too. But basic stuff that libraries are normally used for generally seem to be fine. I don't think there's any way I could write a faster gaussian blur than Pillow or a faster text search than the default regex libs.