3 ms·
> 4 hours figuring out an undocumented bug deep in the source code For me at least, this is the real issue. Gluing together random libraries isn't fun, but it'
by Bartweiss 9y ago
> 4 hours figuring out an undocumented bug deep in the source code
For me at least, this is the real issue. Gluing together random libraries isn't fun, but it's fast and productive and lets me spend my energy and attention building something bigger than I could have solo.
Gluing together broken libraries, though... Well, I thought encapsulation and black boxing were genius from the day I learned about them until the day I actually tried to build something nontrivial. Now I just think of Douglas Adams: "The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair."
Finding myself 5 pages deep in Google trying to fix a fundamentally broken Android API is way less pleasant, and ultimately slower, than working around the API altogether. It's also why all the people I know maintaining long-standing Rails projects have heartburn - using someone else's tools only saves time when those tools are trustworthy.
- brianwawok 9y agoEverything is broken at some level. Your own code will have bugs just like the lib you import will. Usually what is nice is your own code has a lot less lines of code, so you SHOULD be able to find the bug sooner.
- Bartweiss 9y agoYep, I certainly don't mean to imply my code is right. But it's usually shorter, and it's mine. So when I find the bug, I can make the sane fix on the schedule I need. For particularly good OSS libraries, I guess providing a PR would only be a little slower than fixing internal code. But for anything poorly maintained, or with closed development, discovering those bugs often means writing an enormous workaround or switching libraries entirely - they just won't be fixed any time soon.