Your AI skills are worth less than you think (2019) - an interesting look at the value of data science/machine learning/AI skills. It’s no surprise, even to folks who’ve been tangentially aware to the whole AI developments of the past few years that the state of the art has evolved a lot. Both in models, but also in tooling. So something which might take a dedicated team one year to build in 2010, can be done by one intern in 2019 in their spare time. Therefore what it means to know and be good at AI is changing - much like it did for building software. It used to be you needed a PhD and specialized knowledge to write a computer program. This also affects how companies use AI. And to bring this back to what the article is about, if your company is just about AI, you’re probably in dangerous waters. The best setup is when you’re doing something which needs to be done, but you can use AI as a lever to make it faster/better/cheaper etc. Especially as it seems the AI tooling is concentrating in the hands of a few big companies, rather than being more evenly distributed like the software one.

Prototyping a smoother map (2018) - this article is nice mostly for the inner workings of Google Maps - a truly massive software project. The web client for maps I still consider to be magic. There’s also some discussion on using Canvas to have a smoother scrolling and zooming on the map. But this seems to be obsolete with the vector approach currently used in Maps.

Beyond web and worker - evolution of the modern web app on Heroku (2019) - an overview of the standard architecture for Internet applications. What’s interesting here is that the architecture has moved “down” the ladder of complexity. Even smaller projects might be built like this today, whereas the Google’s, Yahoo’s and Amazon’s of yesterday had something like this. I still think it’s not a good thing how we’re building these things, and perhaps some day I’ll write down some more thoughts on this.

Nuage - making data systems management scalable (2018) - data source management is something I’m actually dabbling with at work, so this was a good read on how LinkedIn is tackling the problem. Cataloging and organizing all of an organisation’s data, and how it gets generated, by whom, etc. is a hard problem. I’m not convinced the heavily UI based solution discussed here is right, but it’s at least an approach we can learn from - LinkedIn must have a lot of data.

Kolmogorov complexity and our search for meaning (2018) - a layman’s introduction to Kolmogorov or algorithmic complexity. While hard to work with, I’ve always found this thing the most resembling our human notion of “random” or “non-random”.