My favourite chapter of the book was on A Pragmatic Approach which covers the importance of good design and what what it means. We should adapt to the context and the people that we are working with, instead of blindly following concepts or principles. Simply by following the Easier to Change principle as a value, we can make better decisions when designing a system. The section on Tracer Bullets shows how we can write code to validate and verify assumptions or concerns as to how code should behave. It helps new features or projects progress faster and provides the ability to demonstrate progress to stakeholders.

The authors also cover how we should have a healthy amount of Pragmatic Paranoia because we can never write perfect software. We have all made mistakes in the past in our code, causing incidents that inconveniences others. We should take defensive measures to prevent these mistakes from happening, we should not trust anyone, including ourselves.

The book is also littered with tips, such as Finish What You Start, to always deallocate resources when you allocate them. Your code shown always clean up after itself whenever possible. Important principles such as Principle of Least Privileged are discussed to make good design decisions.

The book ends with the responsibility of a programmer to ask whether we are doing the right thing - to protect the user and would you use this yourself. We should always be learning and improving ourselves, to be a better programmer.

The book is driven by examples to illustrate the process of refactoring. It covers the common code smells and how to identify them - duplicated code, long function, long parameter list, global or mutable data or loops. The author suggests that we should write test suites before refactoring, to drive effectiveness and avoiding mistakes.

The common refacotrings include changing function declarations, encapsulation, extracting code, removing dead code, renaming fields or variables, replacing inline code with function calls, nested conditionals with guard clauses.

I would recommend this book to programmers who want to write understandable and maintainable code to help them be more effective when working in a team.

The book covers the design principles and how to apply them to components of a system. They include the Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle, and the Dependency Rule. The author also covered the SOLID principles and how they can be applied to design a system.

The author also spends a section of the book covering software components and how they can be used to structure a system. They are used to ensure component cohesion in the system - Reuse/Release Equivalence Principle, Common Closure Principle, and the Common Reuse Principle. The author also covered the Acyclic Dependencies Principle and the Stable Dependencies Principle which are used to ensure component coupling in the system.

My favourite was The Missing Chapter by Simon Brown which compares the decisions and tradeoffs made. It was interesting to see how the different architectures can be applied to the same problem.

It covers the common and basic algorithms such as binary search, selection sort, BFS, DFS, Dijkstra's algorithm, greedy algorithms, dynamic programming and K-nearest neighbours. The book also covers data structures such as arrays, linked lists, hash tables, trees, heaps and graphs.

I especially liked the chapter on dynamic programming as it is a topic that I have always struggled with. The author provided a good explanation of how to approach dynamic programming problems and how to break them down into smaller sub-problems. The author also provided a good explanation of how to use memoization to improve the performance of dynamic programming algorithms.

I would recommend this book to visual learners who want to understand how algorithms work, along with the examples and exercises. The examples are available in Python here: https://github.com/egonSchiele/grokking_algorithms.

The book goes through the steps of a system design interview and provides a good overview of the different types of interviews. The first step is to understand the problem and establish design scope. A common pitfall is when you misunderstand the problem and do not clarify the scope before attempting to design the system. It is often more important to show how you think and ask questions before starting on anything.

The second step is propose high level design and get buy in. The idea is to collaborate with the interviewer when coming up with the approach. This helps to obtain feedback and change any flawed ideas or perceptions early on.

The third step is to do a design deep dive. This is when you go into the details of what to use and how to use them. It is also good to talk about the algorithms or functions required for an optimal solution.

The last step is to wrap up the interview. This is done by discussing potential pain points and limitations of the system. There might also be some error cases that the system needs to handle or how to further scale the system.

The author also went through basics such as CDN and caching which are important to understand when designing a system. It is important to understand how the various technologies work in order to design an optimal system. Which is why it is important to read up and keep up to date. A good resource is diff.blog which helps to aggregate blog posts from the community.

All in all, it was an interesting read and the author provided many interesting examples and references to industry practices that you can read up in your own time. I would recommend this book to anyone who is interested in learning the considerations when it comes to designing a system or preparing for interviews.

Uncle Bob covered several concepts relating to OOP, design patterns, and code standards for naming, commenting, and testing. Concepts like DRY and SRP were often repeated throughout the book and used Java code to demonstrate them. Certain concepts were Java specific and I briefly browsed through them since I am not working on Java projects but they were still interesting.

The book is a good read to start off this journey with, and it reminded me of the mistakes I made when I was learning to code. I honestly would cringe if I still have access to the files that I wrote for my first year at NUS.

As best practices and approaches towards maintaining code bases come and go, we should strive to Try and leave this world a little better than you found it. The code that we write should be clean and easy to read, for others and especially our future selves to understand and maintain. It is not just about writing code that works, but also well designed and easy to understand.

It will take me time to develop better code sense and intuition as I learn to become a better developer. The points brought up in "Smells and Heuristics" outlined many points that I often find myself not doing. Let's see if I can learn and work on it. We now have many tools to help us with this, such as linters like RuboCop and ESLint.

Overall it was a good read. I would recommend it to anyone who is interested in learning to improve their coding style. The most of the concepts discussed are language agnostic and I foresee it being applicable even years from now.