Whenever there’s a dessert buffet, I always make the same mistake. Rather than sticking to a single dessert, I invariably try a bit of everything. The problem is that each cake, each sweet and each fruit looks as inviting as the next. A piece of baklawa here, perhaps a chocolate mousse over there, with a dash knafa. For good measure, gelato never goes amiss too. Inevitability, a little bit of everything just ends up being a whole lot of something on aggregate, which is impossible to digest. I’ll never do that again, I promise (till the next time).
When it comes to understanding technologies, we can only digest so much as well! It’s impossible to know everything you’d like to know about the various technologies out there. Time is always the enemy. There are at least half a dozen computer languages I’d love to learn properly, ranging from Julia to Go to q. Will I ever learn them, perhaps one or two, but I doubt much more than that. What motivates me to learn a language or specific technology, is usually a specific problem I’d to solve.
I mostly end up coding in Python these days. However, even after years, there are countless Python libraries I’ve never used. Sometimes the difficulty is that there are simply too many libraries out there in Python to navigate through. In a sense, these days with so much of the lower level plumbing and numerous libraries (many of which are open source), that developers can also be seen as builders putting together pre-existing technologies and code libraries together. In the past, many of these libraries, were not available, so developers would need to create their own solutions.
So just as important, before coding up something, is to spend the time to understand the various technologies you could use and their pros and cons. I’m not saying you need to understand every single line of code of a library you might intend to use, which you don’t have time to do. It’s more about having a high level idea about them. This initial stage of investigation is likely to save you a lot of time long term. If you start to use the wrong libraries for your problem you’ll have endless headaches along the way. It’s worth doing your homework before you start coding (and potentially wasting time reinventing the wheel).
What are the general criteria which you can use when selecting a particular library to use in your software? If you’re deciding between several open source projects on GitHub, you already have a lot of additional information that can help you. Is the project active, and often maintained? Are there lots of folks who have starred the project or forked it? What’s the documentation like? Does the functionality cover all (or most of) your use cases? Is the API relatively easy to understand (and if it isn’t, is it worth the time investment?). Does the code look well written (or a total mess)? These are of course only guidelines, and for commercial libraries, it can be more difficult to answer some of these questions. If there really isn’t anything which fits, then perhaps you’ll have to code it yourself, but it’s worth seeing if there’s something out there already.
So next time I’m presented with the dessert buffet, I’ll make sure I do my homework, to cut down what I pick, and focus on the best cakes, rather than all of them!