I’m now at a point where I don’t remember how many posts of this kind I have written so far, and that’s a good thing. It means I am sticking to my habit and I intend to keep doing that. This week was slower than the last week but I felt I was going into depth of a few things and focus rather than dealing with a breadth of issues. There is still a lot for me to take away from this week. So, let’s get to it.
Effective Mental Models for Code and Systems is a nice insight into thinking about code in terms of a model. It is one of those things that everyone does but don’t think about it in a formal way. But there is a benefit to think about it formally. For example, for me, thinking of code in my head is very similar to running it as a computer would run it at a lower level (usually the microprocessor level but not always).
But how I think about code and systems is not the point here. The point is that everyone has a system or a model of how they think about things. It is often subliminal but bringing it to the surface helps us see perspectives we haven’t considered before. It also helps in standardising concepts we otherwise can’t explain thereby allowing us to communicate clearly about the system.
Another concept this article talks about is about “error kernels”. This is a part of each layer of the system which MUST be correct. If this fails, then “all bets are off” and the system can behave in completely unpredictable ways.
Another thing I took away from the article is about shared understanding. This especially caught me as I have been thinking of a better way to document the applications we build at work. Needless to say, documentation is important. How important? I’ll quote the article to answer that.
What’s “shared understanding” to some is “hidden knowledge” to others, and can turn into an “unknown-unknown” for new readers of the code.
I didn’t manage to complete Black Mirror’s interactive episode “Bandersnatch”, but I did manage to complete a podcast about it. There is apparently a monster called Bandersnatch but the podcast just mentions that and spends much of the time on the Black Mirror episode. The podcast talks about the research of making media like TV shows interactive and how it has been done before. They discuss how they felt that they had to pick a safer, less outrageous option even though what we want to see is what happens at extremes. If you were to watch a movie where the protagonists always make “safe” choices, you wouldn’t remain interested for long. The podcast talks a lot more about making the episode and other attempts like it before.
This is a short podcast episode from the Coaching For Leaders show host. In this episode, he talks about how it is often hard to say what you want to say by saying less. There are other examples I have come across for this such as preparing for a 5 min presentations may take weeks whereas an hour-long presentation is immediately possible. Here, he brings up the example of Mark Twain saying something similar when he received a letter from his publisher asking for a 2-page short story in 2 days.
Mental Models, Part Deux
Another post about mental models, this time not about code. This post is somewhat high-handed and I was mildly annoyed while reading it. But once you get past those sentences, the thought structure is quite useful. Similar to what I said about mental models for code, these are also to formalise the way you think about things. To quote from the article:
Mental models do two things: they help you assess how systems work and they help you make better decisions.
The article goes into examples to explain how you might think of various things in terms of systems and its rules; and thereby building a mental model for that system. Once you think about everything like this, you begin to see a world as a network of connections and understand how one thing affects the other. More importantly, you understand how you are connected to these systems. After discussing this, the article talks about a framework for making decisions to optimise for your current self.
Yet another podcast in the new year about setting goals. I am not complaining because each of them brings a different perspective. This one is from Brain Science, a podcast to which I have linked before and it is as insightful as the ones before it. In this episode, they talk about three types of goal settings: outcome-based, performance-based, and process-based. Thinking about goals in terms of outcomes is binary–it either happens or not, and often is not in your control. On the other hand, your performance and process is something that you can control and planning goals based on that are more likely to get you the results that you want.
I am not going to write a lot about this podcast episode but just mention differentiated privacy. In this episode on algorithmic fairness, the topic of privacy comes up and they mention research where it was found that it was somewhat possible to narrow down and identify someone from an anonymized data set. They introduced differentiated privacy where there is plausible deniability which makes it harder to identify someone. The idea is that you introduce data that may probably be false. Once the data is collected, the probability uniformly applies across the data set and you still get the trends you want to study, but even if you could identify someone from this data, they have plausible deniability and can claim it was false. Of course, the tradeoff here is that you lose outliers in the data here but this is a good method if you are only interested in trends.
AlpineJs and Template tag
While listening to the podcast, I also came across the template tag and I had not come across that before. I don’t imagine it will be useful to me for regular tasks but it is good to know about it.
I am looking into options of running some of my sites as Docker containers in production and think Kubernetes is an overkill. I know there are light-weight implementations of Kubernetes such as k3s and similar but even that seems overkill to me at this point. For now, I am exploring the idea of running the containers behind Traefik to proxy the requests. I am still in process of trying this out and hoping to have a trial system set up over the weekend. That may be difficult as I am also learning a bit of Go.
My plan is to write more about my learning journey with Go over the weekend in a separate post. For today, this post is as long as it gets.