One of the rarely-made-explicit skills of a developer is choosing a software library for some task. Just now, I realised I’ve built up some habits of how I do this, without ever making it explicit. Here’s what I’m generally doing:
– find one package that does the job. perhaps by straight-up googling for it, perhaps by checking stackoverflow
– search Hacker News discussions about it, using duckduckgo’s ‘!hn’ bang command. Here I’m trying to get a general idea of how people see this library, how alive it is, and especially what people are using instead. I’m looking through
– top-ranked posts: generally the launch and major releases, sometimes somebody complaining about it
– top-ranked posts from the last year: gives me a sense of the direction. Quite often you’ll find a low-comment post asking ‘what’s up with X?’, and somebody in the comments saying ‘we’re all using Y instead’
– comments: will generally turn up some where the library is one of a list of options (try X or Y or Z), or where somebody is arguing when/when not to use it
– Through this I build up a list of maybe 2-4 libraries in the same area, and an idea of how they are seen. Then for each of them, check:
– the homepage, especially the quickstart tutorial
– github, or wherever the code is. number of stars/forks, maybe glance at the open issues
– Try the most-promising looking one. If I hit a roadblock, go back and look at number 2
In most areas, this is sufficient to quickly find a ‘good enough’ solution. Then I can forget about it, and focus on the 10% of cases where I need to have higher standards