Book recommendations

Lately I have been able to consume a lot of books. At work we are provided with an opportunity to purchase one tech book a month. Combined with my Audible subscription, I get to read around 2 books every month.

Here’s what I have had a chance to finish and what I think about it:

Code: The Hidden Language of Computer Hardware and Software

This book is just fantastic. It starts with explaining Morse code, moves on to explaining electricity, telegraphs and relays. And then it culminates in showing how to build a primitive computer out of these components. The computer will have a CPU, RAM, input and output. Feynman’s quote “What I cannot create, I do not understand” springs to mind. It is so satisfying visualising how one could, in principle, connect tons of relays together and have a computer: it makes you think you understand the darn thing, finally. It also fascinates me how all of this got ultimately build and what level of sophistication modern computers managed to achieve by just manipulating a bunch of 0’s and 1’s.

Shoe Dog: A Memoir by the Creator of NIKE

I got interested in the book after reading Bill Gates’ review.

This nonfictional book reads like a novel. I just love the protagonist of this book: he’s extremely relatable. He’s also very humble. This book reminds me of “Surely You’re Joking Mr Feynman” the most: you fall in love with the storytelling and with the author.

I don’t really know what I learned from this book, apart from the fact that success is extremely fragile and opportunistic. It is amusing to me that the whole Nike brand had to be thought up in a day and how the founder didn’t even like the name.

In my pre-book worldview, names like that take committees weeks to design and everything is careful planned for the launch of a new brand.

In my post-book worldview, things are just chaotic. Nike was launched with poor quality shoes (by the admission of the founder). The brand name was created by an employee, who, frankly, comes across as insane. The launch was haphazard just like the history of the entire company. Yet it somehow worked out.

The Effective Engineer

I loved the book so much, I made the following summary for myself and my colleagues:

  1. Advice on meetings:
    • Prepare and circulate the agenda before meetings
    • Replace a meeting with email discussion/prototyping code instead if possible
  2. Openness
    • Reflect on whether product changes/feature launches/merged PR’s were worth the effort. Review returns on investment of completed work
    • Know priorities of different teams
  3. Autonomy
    • Encourage widening the breadth of codebase an individual is expected to work on
    • Allow for people to switch teams/projects
  4. Personal tips
    • Read a good book or two on the language you code in (just googling around will result in having gaps)
    • Jump fearlessly into code you don’t know.
  5. Prioritisation
    • Work on what directly produces value. Defer and ignore activities that don’t. Keep in mind the opportunity cost of say attending a meeting or fixing a bug that isn’t that important: the time spent could have been directed toward more productive activities.
    • Prioritise regularly. Give up on tasks that don’t achieve what you thought they would achieve early (on average people don’t give up early enough).
  6. Measuring
    • Just like one shouldn’t measure average response time, and measure 99’th percentile instead; one should not measure number of bugs fixed, one should only be concerned with number of bugs outstanding
  7. Collaboration
    • If possible, structure ongoing projects so that there is some shared context with your teammates. This should increase collaboration and has potential to reduce friction between projects.
  8. Strongly prefer phased rewrites. Quote:

    …Their first task, therefore, was to translate the original C# codebase into Java so that it could leverage Google’s infrastructure. One of Schillace’s co-founders argued that they ought to rewrite the parts of the codebase they didn’t like at the same time. After all, why rewrite the parts of the codebase to Java only to have to immediately throw parts away? Schillace fought hard against that logic, saying, “We’re not doing that because we’ll get lost. Step one is to translate to Java and get it stood back up on its feet again…. Once it’s working again in Java, step two … go refactor and rewrite stuff that’s bugging you.”

  9. Managing projects
    • “Deploy ASAP” encourages accumulation of tech debt. If there’s no real need to deploy ASAP consider slowing down and building the foundation first. Build ASAP + refactor the debt afterwards is less efficient than building the foundation first then adding a feature.
    • Do the riskiest parts of the project first. Which parts are most uncertain about the new proposal? Address them first. Don’t give yourself the illusion of progress by focusing first on what’s easy to do.
    • Plan and practice failure scenarios.
  10. Hiring
    • Hiring is extremely important activity as it pays off well if you hire the right person.
    • Take time with you team to identify which qualities of a potential hire you care about the most. Periodically meet and review these and previous hires.
    • Have an onboarding process/mentorship. Try to get new hires to contribute ASAP.

Others

I have also “read” the following audiobooks: “Sapiens: A Brief History of Humankind” and “The Gene: An Intimate History”. These are good, high quality books. Yet somehow I didn’t enjoy them as much as the books above. I still enjoyed them though, just not as much. I might elaborate on them later. In the meantime, stay tuned for more book recommendations! On the second thought, don’t bother because I don’t blog regularly.