Issue #32: 10 Reads, A Handcrafted Weekly Newsletter For Software Developers


The time to read this newsletter is 150 minutes.

Writing may be the skill with the highest return of all – Seth Godin

  1. Undervalued Software Engineering Skills: Writing Well: 5 mins read. I echo with the author. Being a senior engineer in my organization this is one advice I usually end up giving to people. The key points from the post are:
    1. In a large engineering organization writing is the only medium that will help you propagate your message forward.
    2. You can learn to improve your writing skills. It is a learnable skill.
    3. Writing code is not the only activity in software development.
    4. When you write things down, you build better understanding of the topic. I personally find that writing helps me think clearly about a problem.
  2. Why Github used Haskell for Semantic? – 20 mins read. We need more such posts from the community. These type of posts can help developers understand how organizations take technical choices. The key lessons for me in this post are:
    1. The problem Github is trying to solve with Semantic is related to domain of programming language theory. This domain is an active research area and most of the researchers in this domain use Haskell for its brevity, power, and focus on correctness. Writing in Haskell allows us to build on top of the work of others rather than getting stuck in a cycle of reading, porting, and bug-fixing
    2. Haskell makes it nigh-impossible to build programs that contain such bugs
    3. Haskell used in industry at scale. Facebook open sourced a project called Haxi that is written in Haskell.
  3. Let’s build a SQL parser in Go!: 20 mins read. I enjoyed reading this post. It shows in a step by step manner how to write a SQL parser. The author implemented it in Go.
  4. How I decimated Postgres response times for my SaaS: 15 mins read. There are two key points in this post:
    1. You can only fix a problem if you can successfully reproduce in your local environment. I know this sound common sense but ask yourself honestly how many times you have tried solutions without reproducing the problem in a local environment only to discover that your proposed solution does not work. This happened to me this week.
    2. Composite index in PostgreSQL can help you avoid heap sort if you do order by in your query.
  5. 13 Tips for Writing a Technical Book: 15 mins read. A lot of useful advice. I wrote a similar post when I published my first book. The key points for me in this post were:
    1. Pad the timeline
    2. Schedule regular time to write: every morning, every weekend, etc
    3. Use lots of TODOs to keep track of what’s left
    4. Getting good technical editors is hard
    5. Writing is lonely
  6. Remote working – Bringing sanity to mind & lessons worth learning: 20 mins read. This post covers the other side of remote working — anxiety and depression. The article shared tips that can help.
    1. First thing you need to do is to get out of the denial mode. Mental issues can happen with anyone. Setup a weekly wellbeing check-up with yourself.
    2. Create a schedule and stick to it. Know when to stop and detach from work.
    3. Setup a separate remote working space.
    4. Limit your digital life. Talk to people
  7. Amdahl’s law: 10 mins read. Amdahl’s Law is a formula which gives the theoretical speedup in latency of the execution of a task at fixed workload that can be expected of a system whose resources are improved. In essence, it says you can’t speed up beyond the sequential part of your program irrespective of how many cores you add. Gene Amdahl’s said, If 50% of the execution time is sequential, the maximum speed up is 2, no matter how many cores you use. Good video that you can watch on Amdahl’w Law is by Professor Ben H. Juurlink.
  8. Blameless PostMortems and a Just Culture: 15 mins read. Having a “blameless” Post-Mortem process means that engineers whose actions have contributed to an accident can give a detailed account of:
    1. what actions they took at what time,
    2. what effects they observed,
    3. expectations they had,
    4. assumptions they had made,
    5. and their understanding of timeline of events as they occurred.
  9. Love DevOps? Wait until you meet SRE: 10 mins read. If you have not heard about SRE then this post will help you get started. SRE as defined by its mastermind Ben Treynor is “SRE is what happens when a software engineer is tasked with what used to be called operations”.
  10. 3 Mindfulness Rituals That Will Make You Happy – 20 mins read. You are not your thoughts.

Video of the week

Leave a comment