#issue1
3 posts

The five stages to unit-testing enlightenment

All developers go through five phases on the unit-testing journey before achieving nirvana - ignorance, hesitance, enthusiasm, fanaticism, and pragmatism.
Read more

The five stages to unit-testing enlightenment

Full original post here

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.

You start with being a unit testing ignorant. You have real code to attend to and you are proud that you are not wasting your time on this irrelevant stuff. In the next phase, enters a villain who forces you to write unit tests. And you write them just for the sake of getting them out of your way. This is you going through unit testing hesitant phase. Then something unimaginable happens.

“You realize that it’s not all that bad. You get a warm and fuzzy feeling, deep down in the gut of your programmer-soul, when you see that green bar slowly crawl up to 100%.” You turn into an enthusiast, you even start convincing others to write tests. But all good feelings don’t last too long. The dark phase arrives and you find yourself researching testing frameworks & best practices. You are a fanatic who tells your manager why some of these should be adopted. You are writing more test code that production code. Finally you realize and you admit that you have a problem, “your testing journey has come full circle, returning to where you started; at the notion that delivering features and production code is your main objective.”

5 mins read

Things I Learnt from a Senior Software Engineer

“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.
Read more

Things I Learnt from a Senior Software Engineer

Full original post here

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

Releasing the World’s Largest Python Site Every 7 minutes

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.
Read more

Releasing the World’s Largest Python Site Every 7 minutes

Original video here.

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.