Reading Complex Engineering Articles - Biweekly Engineering - Special Episode 4

Welcome to the holiday season issue of Biweekly Engineering! Hope you are having a great time with family and friends. 🤗

This issue of the newsletter will be a different one. We will discuss in detail the effective methods to read engineering blogs. And then we have a blog post from The Pragmatic Engineer.

Vamos!

How to effectively read complex engineering articles

This newsletter was created with the intent to share quality posts from many engineering blogs out there. But as a reader, how can you effectively read them? It might not be super obvious to you if you are trying to build the habit for the first time.

Before diving into the techniques that help to effectively read engineering blogs, there are some considerations that are natural to pop up -

1) The tech field is huge. You simply cannot know and understand everything.

2) As an engineer, your domain of work is bounded by the job responsibilities you have. This makes you knowledgeable in one specific field, but you won't have the same expertise in other domains. As an obvious example, I have been working as a backend engineer, and as you would expect, my frontend engineering knowledge tends to zero.

3) You don't work for the team or the company that is writing the article. They have the experience and the knowledge on the topic discussed, which you do not have. You have only the writing in your disposal to understand the context and dig up some useful learning from it. Truth be told, this is not an easy feat.

So the point of the above discussion is that you should not bother much if you find it difficult to read and understand all these complex blog posts. You need practice, time, and experience to get to a point where you feel comfortable to do so. And of course, you need to put the effort.

Let's now quickly discuss a few conditions I check to effectively read an engineering blog post.

Are the keywords used in the article familiar to me?

The first step is to quickly notice the keywords in the article. Do I know the keywords? Are there any specific keywords that are core to the discussion but I don't know what they mean?

For example, take the following article.

The article discusses a scalable and reliable shuffling system for Apache Spark. Shuffling is a fundamental design principle of Apache Spark where data is distributed among multiple worker nodes.

If we have a look at the article, we can see two specific keywords that are core to the discussion - Apache Spark, shuffle.

As a reader, if I don't know Apache Spark and its shuffling mechanism, it makes little sense to me to read this article at this point. In my view, I need to at least be familiar with the core keywords of the discussion. This is technically the bare minimum we need to have before starting to read an article.

Does the topic feel relevant to my work, or interesting to me?

The next thing to understand is whether the topic discussed is relevant to my work or feels interesting.

I use this filter to prioritize or deprioritize an article. If the topic is relevant or interesting, then it's a no-brainer. I will read it immediately, or copy-paste the link somewhere so that I can get back to it and pick it up later.

There is another consideration. If the topic is not relevant to my work, but this is something I want to know more of, then I would also prioritize the article.

As an example, I have worked on big-data systems built on top of Apache Spark. So when I encountered the Uber article mentioned in the previous section, I was naturally curious.

Is the article too complicated?

Next, I would consider the difficulty of the content.

Every company builds systems that target their specific set of problems. They have their bounded contexts that require deep knowledge of the systems. I don't work for that particular company or the team. It's fair to expect that I will probably find the articles difficult to understand.

If the article in hand passes the first two checks, but I find it too difficult to understand, then it's time to reconsider spending time on it. But if it's reasonably difficult but understandable, then it's a good chance to learn something brand new from the writeup.

But how can we actually decide? Where do we draw the line when to retreat or when to move forward with the blog post?

The answer is, it depends on you, the reader. You need to build an intuition for this. A seemingly complex piece of writing can become crystal clear after a bit of attentive effort. At the same time, to keep trying to read an unfathomable article means you are wasting your time.

Also, keep in mind that when you go out of your comfort zone, that's when you are exposed to something new that could potentially enhance your knowledge and understanding.

In my experience, one can build the intuition over time with more experience. Keep reading and keep exploring. At some point, you will know what you need to know.

Reading engineering blogs is the most underrated but immensely effective way to learn as an engineer. In the tech world, people are working on so many cool problems. These blog posts help us to get a glimpse of what is happening out there, and learn along the way.

Gergely Orosz's distributed systems learnings after working on a payments system

Gergely Orosz's personal blog The Pragmatic Engineer is a gem. His newsletter is one of the most popular newsletter in the tech world right now, if not the most popular one.

During his time at Uber, he worked on a large scale payments system. This article very briefly discusses the concepts he learnt while building the system.

Staring from SLA and vertical vs horizontal scaling, Gergely mentioned actor model and reactive architecture. I won't go discuss about these concepts here. You can surely find out details online.

I wholeheartedly like two things about the article -

1) It discusses concepts that were required in a real-life system. We readers get an idea of how distributed systems concepts are relevant in day-to-day work of backend engineers.

2) The article doesn't try to go for the extra mile to explain all the concepts in detail. It wouldn't be realistic. Rather, it gives readers a starting point. If you feel curious, go ahead and google. You will find enough resources online to wrap your head around the ideas shared. :)

This marks the end of today's issue. Holidays are here, and wishing everyone happy holidays! See you all next time. 👋