👨‍💻

People seem to agree that a great developer is better than many mediocre developers and I think that is true with good reason. Developers are craftsmen, in my opinion, like stonemasons, woodworkers, or carpenters. We make things that are useful to people outside the field, and, if well made, can be even artistic to those who understand the field. Similarly, like craftsmen, you can't replace someone with a skilled hand with many people with unskilled hands. They tried using automation and large factories to churn out things like mass-produced furniture, but at the end of the day, the IKEA fast furniture just really isn't up to the quality of a similar piece made by a real artisan. However, developers these days seem to earn a lot more than other craftsmen, and I think that is largely because for many people buying things like furniture or pottery (especially the young folks like me), cost is a lot more important than quality and most people would rather pay, say, 10% of the cost...

I think about a cache like a faster database that you check before checking the main database, but at the end of the day, if you do have a cache, you have to check 2 databases. If the cache is sitting in some remote machine, like Memcached, you run into various things that may slow it down by hundreds of microseconds such as intrinsic latency or network latency, and if you choose to query between datacenters you may even get dozens of milliseconds of latency. I wonder how important it would be to shave off these microseconds, or to even just find a way that we could avoid cache queries when they are misses. I'll keep thinking on this and read more about how hyperscalers use caches.

Recently I discovered this old talk from Google I/O 2009  and in the first 14 minutes they explain the Recyclerview, the Adapter, and the Viewholder incredibly well. Here's a few important takeaways from this video, although I'd recommend watching it in its entirety: 1. The Adapter takes in data and generates Views via a function Adapter.getView() that takes in a position, a View, a parent ViewGroup, and returns a View. 2. The naive solution to implement Adapter.getView() would be to use the position to get the right data and then just inflate a new View that belongs to the parent ViewGroup. 3. The first optimization is that we can avoid inflating new views by just recycling old views when they leave the visible area. We would use the position, the View (recycled when it is not visible) and just bind new data into that existing View. 4. The second optimization is that we can avoid doing new findViewById() calls by storing all the referenced Views in a class called a ViewHold...