#Book club Notes What I learnt from the book

Part 3: Building Long-Term Value

8. Balance Quality with Pragmatism

Every code change, it's required engineers to formally pass a readability review + Code sample + unit test coverage + style conventions (Google)
You must move quickly to build quality software(If you don't, you can't react properly when things - or your understanding of things - change ...) (early Facebook engineer)

In this chapter,

Strategies for building a high-quality codebase and consider the tradeoffs involved: the pros and cons
The pragmatic approaches for implementing them ^
The benefits and the cost of code reviews
Some ways that teams can review code without unduly compromising iteration speed
How building the right abstraction can manage complexity and amplify engineering output
How generalizing code too soon can slow us down
How extensive and automated testing makes fast iteration speed possible
Why some tests have higher leverage than others
When it makes sense to accumulate technical debt and when we should repay it

Benefits of code reviews to Google engineers

In the early days of Instagram

Engineers often did over-the-shoulder code reviews where one person would walk through another's code on a shared monitor Square and Twitter
often use pair programming in place of code reviews Ooyala
Comment + email only for trickier code
Review code post-commit

Today, people use github, Phabricator, Lint checkers

Pick the right ones, and programming will flow naturally from design; modules will have somall and simple interfaces; and new functionality will more likely fit in without extensive reorganization.
Pick the wrong ones, and programming will be a series of nasty surprises: interfaces will become baroques and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make. - MIT professor Daniel Jackson

It reduces the complexity of the original problem into easier-to-understand primitives
It reduces future application maintenance and makes it easier to apply future improvements
It solves the hard problems once and enables he solutions to be used multiple times
Good abstraction should be
- easy to learn
- easy to use even without documentation
- hard to misuse
- sufficiently powerful to satisfy requirements
- easy to extend
- appropriate to the audience
Some ideas to get started with designing good abstractions
- Find popular abstractions from repositories on GitHub. Read and try to extend
- Look through the open source objects from Google/Facebook/LinkedIn/Twitter and learn Protocol Buffers, Thrift, Hive and MapReduce
- Study the interfaces of popular APIs developed by Stripe, Dropbox, Facebook, AWS

Unit test coverage provides a scalable way of managing a growing codebase with a large team without constantly breaking the the build

reduce bugs
decreasing repetitive work
allow to make changes (Especially large refactoring)
delegate maintaining to others who don't know all the edge cases
offer executable documentation of what cases the original author considered and how to invoke the code And my ideas..
let developers make testable code
don't try to aim 100% of coverage

Debt-ridden code is hard to understand and even harder to modify
Whenever we write code, debt will be accumulated
The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments. - Martin Fowler

Example of Asana: Schedules a Polish and Grease Week at the end of every quarter to pay off any UI and internal tools debt

Example of Quora: A cleanup day after every week-long hackathon

Example of Google: Fixit day

Example of LinkedIn: Paused feature development for two months after they went public