I think there are three types of knowledge you need to be successful in a corporate job: technical knowledge, process knowledge, and corporate knowledge. Technical knowledge is the “what”; process knowledge is the “how”; and corporate knowledge is the “why”.

Here is an example to illustrate this: let’s say you are responsible for writing a program that communicates with an external API, and there is a firewall at your company that blocks external connections. Having technical knowledge would mean being able to write the program; having process knowledge would mean realizing that you need to request that the firewall be opened to enable the connection and knowing how to go about getting the request initiated and approved; and having corporate knowledge would mean things like understanding why the firewall was set up to block the connection in the first place, understanding where the approval process came from and the thought process behind it, knowing who to go to to expedite approvals, understanding the bigger picture of how the program you wrote would benefit the business and fit into its overall goals, and so on.

Exactly a year ago, on the occasion of my blog’s first anniversary, I posted an article with some advice for starting a blog. As part of that article, I posted a list of blogs I enjoyed and had been reading. Since today is the second year anniversary of this blog, I thought I’d continue the tradition and make it an annual exercise.

I did not write a lot on this blog this year – I have been incredibly busy. However, I am very happy to report that the blog has not died! I still managed to post some stuff here and there despite all of the craziness, and I’ve very happy with the quality of all of the blog posts I did manage to publish. I’m not as proud of all of the draft blog posts I started that I’ve yet to finish, but oh, well. You win some, you lose some. I still managed to write some spur-of-the moment angry rants but post them shortly thereafter, which I think is really what the spirit of this space existing is all about.

While the terms “distributed systems” and “distributed computing” are often used interchangeably, for my purposes, I’ve found it useful to draw a distinction. Distributed systems research is often focused on how to get multiple components of a system to act together in a reliable way, whereas distributed computing research is focused on how to use multi-component systems to solve a problem by breaking it down into different parts. While distributed systems is more of an engineering discipline focused on systems architecture, distributed computing is more of a mathematical discipline focused on the design of algorithms.

These are the notes I took while watching How to Speak, which was MIT professor Patrick Henry Winston’s yearly lecture on how to give talks. (It’s an iconic lecture, and you should definitely watch it). These notes are the key points, and they’re mainly for me, but I thought I’d share them here in case someone else might benefit.