Books I have read

Apparently people like collecting a bunch of sentences that sound similar into a collection which they attempt to sell. This is what’s known as a “book”.

I’m still trying to wrap my zoomer brain around the concept.

• Atomic Habits

  By James Clear

  One of my favourite self help books. Many self help books focus too much on perspective and frame of mind or have a heavy focus on inspirational stories and role models from bygone years. In comparison, Atomic Habits highlights the power unconscious habits have (what a surprise) and how we can build new ones for ourselves.

  A highly recommended read to anyone across all fields.

• Clean Architecture

  By Robert C. Martin

  I read this directly after The Pragmatic Programmer and it was provided a way of organising code that made a lot of sense.

  The author describes software “architects” closer to gardeners than actual architects. Constant maintenance and redesign is happening unlike in brick-and-mortar architect.

  The book reasons that modules that do not change often, like high-level business logic, should not depend on modules that change frequently, like database interactors.

  If the high-level logic depends on the type of database then when we change the database provider we have to modify the high-level module as well.

  On the other hand, if the high-level logic requires usage of persistence it should be through an interface which the low level module implements, this ensures the high-level logic does not depend on the type of database used.

  Since reading this book I’ve been thinking about how I can ensure my high-level logic is independent of lower level details.

• Cracking the Coding Interview 4th ed.

  By Gayle Laakmann McDowell

  A decent introduction to algorithms, no university degree necessary. Someone who has has understood early programming concepts could use this as a roadmap to landing a job at a tech giant.

  After reading, I didn’t feel I could ace a Google interview but now I know what the next step is.

  Explanations appeal to intuition and have a focus on doing your best to solve them in an interview rather than teaching the optimal or correct solution. For example, a particular solution’s Big O notation wasn’t derived or even shown, the author explaining that it is unreasonable for an interviewer to ask an interviewee to perform such a derivation. I do not say this as a criticism of the book but to highlight the books intention.

• Designing Data-Intensive Applications

  By Martin Kleppmann

  Don’t let the name turn you away. Data-intensive applications are most applications. If you store data then this book is pertinent. The book provided me a new perspective on the services I build and operate. You can think of them as really specific databases built on top of general purpose databases.

  In my current role I occasionally get a way in how are systems are structured. Much of the initial back and forth with team mates would skipped if I had read this book before. A key takeaway is considering how the application reacts at every possible place a fault occurs. Understanding the underlying technologies we use also helps understand their performance characteristics.

  For those who are studying would recommend this book to understand how a microservice architecture behaves. Some of it may go over your head but I still believe you’ll be getting much out of it.

• Fahrenheit 451

  By Ray Bradbury

  In my opinion the writing style alone warrants its award-winning reputation. It was short and compelling read, if you have a free day you could do worse than spend it on this novel.

  I highly recommend the audiobook version narrated by Christopher Hurt. I’ve always been a big fan of audiobooks and an audiobook sceptic I know became a true believer after listening to it.

• Git Magic

  By Ben Lynn

  A short booklet on neat tricks in Git. Nowhere near a introductory guide. Was written during a time of competing version control systems, now that Git has become the standard it becomes more historical artifact than practical handbook.

  I’m reminded of this article by Julia Evans regarding another book on Git suffering from the same problem.

  It’s short enough that anyone already familiar with Git can learn something new but don’t attempt to learn Git via this book.

• The Pragmatic Programmer

  By David Thomas, Andrew Hunt

  Short and got their point across. There were a few times the book made me look at my work in a different light.

  • Text based protocols may take up more memory but allow developers to read and debug far easily. That’s why JSON and other readable formats have taken over compared to faster, binary formats.
  • Test driven development isn’t actually about producing tests. It’s about producing code that could easily be tested. Code that is easy to test will likely be modular as a bonus.

  Other concepts like the value of quick text manipulation and the Unix pipe operator I already knew about but were explained well.

• The War of Art

  By Steven Pressfield

  The first book on self help I ever read. Provides a healthy dose of realism to the process of making art and creation in general. A good book but there are others which give the same advice and do it better.

  Creativity and inspiration should not be viewed as chance moments throughout one’s life but instead something we can foster within and trigger with some predictability.

  Exercising the creative muscle, treating your art as a serious endeavour instead of a nice hobby are some of the topics this book touches on.

• You Don’t Know JS

  By Kyle Simpson

  A deep dive into the idiosyncrasies and features of JavaScript. From closures to types and grammar there are very few topics the book series shies away from.

  Despite the challenging concepts the book doesn’t require 5+ years working with JS nor a degree in compilers and interpreters. I personally had very little knowledge of JavaScript before reading and was able to take in most of the topics.

  This is clearly not a “learn how to code” tutorial but I would still recommend the introductory book, Get Started, for really new beginners as a timeline of JavaScript’s evolution.

  The author has an stance on JavaScript best practices which are sometimes at odds with the larger JS dev community (mixing usage of var and let). But it is usually clear when recommendation and opinion is being expressed and justification is always provided.