Deciding between code libraries

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...

To read the rest of the article on the Cuemacro website, please click here!