Best Tech Things I read this week (6 Part Series)
I share TL;DR versions of articles on software engineering that I read every weekday through my newsletter - in.snippets(). Sign up here to receive these in your inbox.
Instagram releases server code 70-100 times every day. At peak, it is done every 7 minutes. It has a monolith codebase of several million lines and a few thousand Django endpoints, all loaded up and served together. In this talk, Shuhong Wong, Production Engineering Manager at Instagram, shares how Instagram’s deployment process evolved over the years to achieve this feat. Key insights I drew from this talk:
Give your team a set of safe defaults (parameters to check & right answers to common questions people ask before deploying) to follow through the process. Let these safe defaults be the deciding factors for deployment, not human judgment.
Always deploy in small phases. It is safer for production because low firing errors only become obvious at scale. And continuous deployment is impossible without knowing whether the change you are about to make can break production. So, you will need to build a culture of testing to make it happen.
You don’t need a grand plan to start building a robust deployment process. You can always do the simplest things that are enough to scale the process for the current team size and evolve with time.
29 mins watch time
A year ago Neil Kakkar started working at Bloomberg. Sitting next to a senior software engineer, he could closely observe what they were doing, and how it was different from what he would do. He shares everything he learned in the last 1 year in this post. The post has some good reminders on software engineering best practices that all devs would find useful.
My favorite two are:
“Whatever deployment process you choose, treat your machines like cattle, not like pets. They aren’t precious. You know exactly what’s running on every machine and how to recreate them in case of death. You’re not upset when one machine dies, you just spin up a new one. You herd them, not raise them.”
“Just writing tests don’t improve my code quality, writing the code does. But the insights I gain from reading the tests help me write better code.”
20 mins read
Jonathan Sampson is a curious soul. He wants to know what happens when you fire up a web browser for the first time. In the case of Google Chrome, 32 requests are made, and 7.26 MB of data gets downloaded. Check out this Twitter thread to know what these 32 call requests were for.
This is a pretty slick tool that lets you bring all the things you keep checking during your workday to your terminal. You can see your Google Calendar, Git and GitHub repositories, Jira tickets, OpsGenie schedules, New Relic deployments etc all at one place in your terminal.
All human beings go through five phases psychologically before accepting any kind of loss - denial, anger, bargaining, depression and acceptance. Similarly, all developers go through five phases on the unit-testing journey before achieving nirvana - ignorance, hesitance, enthusiasm, fanaticism, and pragmatism. This hilarious post by Said Aspen, will make you “reflect on your relationship with software unit testing.” Read it to tickle your funny bone.
5 mins read
P.S - This is a list of the best of tech articles that our team at Appsmith read through the last week. I shared the first list here & plan to share this recommended reading list every week. Would love to hear feedback on this. What did you find useful and what didn't you like?
What did you read the last week that you absolutely loved?