I read a lot—technical books, product essays, and thought pieces on engineering culture. This section turns those into short, practical summaries: what I learned, what I applied, and what stuck with me.
Key lessons: write code that conveys its intent clearly, choose meaningful names, keep functions small and single‑purpose, test thoroughly and refactor iteratively, and always leave the codebase cleaner than you found it.
Key lessons: fix broken windows early, communicate to avoid ‘boiled frog’ problems, know when to stop and ship, apply DRY and orthogonality to reduce duplication and coupling, and use tracer bullet design and crash‑early practices to uncover issues sooner.
Key lessons: treat patterns as reusable solutions above classes, program to interfaces and favor composition over inheritance, recognise patterns to design more flexible systems, and balance the power of indirection with the risk of added complexity.
Key lessons: refactoring changes the internal structure without altering behaviour, tests and small steps make it safe, separate refactoring from feature work, refactor when it makes changes easier (not for its own sake), and learn to recognise code smells and apply appropriate moves.
Key lessons: software development is joyful but demanding, adding people to a late project makes it later (Brooks’ Law), design systems with the user in mind and document them well, invest early in clear requirements and data structures, and recognise that conceptual mistakes are cheapest to fix early.
Key lessons: use four key metrics (deployment frequency, lead time, MTTR and change failure rate) to measure delivery, adopt capabilities like version control, trunk‑based development, test automation and continuous delivery, work in small batches with empowered teams, recognise that high performers deliver more frequently and recover faster, and understand that speed and quality improve together.
Key lessons: treat teams as part of a sociotechnical system with limited cognitive load, align team boundaries with the software architecture (and apply the inverse Conway manoeuvre), restrict teams to four fundamental types (stream‑aligned, enabling, complicated‑subsystem, platform), choose boundaries and fracture planes that support autonomy, and define clear interaction modes to manage communication.