The time to read this newsletter is 145 minutes.
There is only one way to happiness and that is to cease worrying about things which are beyond the power of our will – Epictetus
- Goodbye, Clean Code. 10 mins read. We sometimes get carried away with clean code.
- Clean code does not always produce simple code.
- As mentioned in the post, clean code is also a trade off. You really should weigh if clean code adds real value or satisfy your inner clean code ninja.
- Another important point mentioned in the post is that you should always take the person whose code you are refactoring in favour before refactoring their code. Explain your rationale and then work with them to improve it.
- A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together
- The No Code Delusion. 15 mins read. I agree with the author that we are still far away from pure no code systems. Most of the no code solutions fail when you want to do things slightly differently. They become limiting and you struggle to keep productivity. They are good for proof of concepts where you want to showcase value faster.
- Why we’re writing machine learning infrastructure in Go, not Python: 10 mins read.
How To Optimize AWS Lambda Performance. 20 mins read.
To Serverless or Not To Serverless. 10 mins read. There is nothing new in this blog if you already know about pros and cons on Serverless. But, it is a good written article that you can keep handy in case you need to make decision on Serverless.
A Scientific Approach to Capacity Planning: 20 mins read. This blogs talks about Universal Scalability Law (USL). The USL law takes into account the fact that computer systems don’t scale linearly due to queueing effects.
The Curious Case of the Table-Locking UPDATE Query: 10 mins read. This post by a Heroku engineer talks about how he debugged an issue related to Postgres locks. Good read.
Radical Candor: Software Edition: 30 mins read. This is a long read. It offers a lot of good advice on how to apply Radical Candor in software development. Radical candor is showing care and giving straight feedback. You have to build a relationship with people so that you can be true to them.
The Myth of Architect as Chess Master: 10 mins read. I could relate to the author as I often find myself in such situations. Software development is a cognitive activity and most systems are built over years. So, it is difficult to parachute yourself into a system and provide meaningful advice without spending a lot of time understanding the context and business drivers driving the project.
##Video of the week