3 ms·
I can see where the author is coming from with Point 3 (Don't build a framework or library). In fact, I personally suffered from the problem of spending time on
by BrandonM 18y ago
I can see where the author is coming from with Point 3 (Don't build a framework or library). In fact, I personally suffered from the problem of spending time on a framework when I really should have just been building the application, but that was partly because it wasn't my application and the framework was more interesting. But that's a different story....
So I do agree that rolling your own framework right from the start is probably a bad idea, but I wouldn't say the same for a library. A library is much-smaller-scale than a framework. In general, a well-built module in your program can likely be converted to a more general-purpose library with just one small iteration (in my experience at least). This should be especially true if you only generalize the functionality that you're currently using and avoid adding every function/method that you will ever possibly need.
The benefit of building a library is that once you do, you can consider that part finished for a long time. You can build a little test that checks the library's edge cases while also serving as a good example of how to use your library (it's always good to have simple code to refer to in 6 months). And if the library isn't too proprietary, you can throw it up on a public-facing server, where you can both help others and have a decent chance of receiving good feedback (if not patches) for better algorithms, bugfixes, or additional helpful functionality that others have implemented.
Specifically if you're working in a language that you will use for the majority of your projects, having a collection of personal libraries is invaluable. You will have this wonderful repository of functionality that you're already intimately familiar with, and instead of having that nagging feeling that you're re-coding something that you've done in the past, you will be able to go back and use a solid piece of tested code with very little effort expended on (re-)learning an API.