What I learned from books in 2019

Books 2019

Last year, I decided to review most interesting books I read last year, and write down my thoughts. Inspiration comes from GatesNotes. This post is long overdue, but I’m glad I managed to publish it before the end of 2020 ūüôā

  • Deep Learning with Python
    • good overview of different types of ML applications: from basic models than can be mapped to 0 and 1s, through computer vision to text
    • using Keras and writing python to actually train neural nets while reading this book was super helpful in understanding ML
    • I think thanks to this book I understood that I do not want to build Machine Learning models, but rather apply them in products
  • Principles: Life and Work
    • life principles
      • Decide 1) what you want, 2) what is true, and 3) what you should do to achieve #1 in light of #2 – many time we want to achieve things, but we are not willing to acknowledge reality, I’ve been guilty of that many times in the past. Realizing that some things are just harder to do than they appear helps tremendously.
      • open-mindedness and radical transparency are invaluable for rapid learning and effective change
      • look at yourself with other’s eyes – many times (always?) we have totally different image of ourselves than other do
      • 5-Step Process to Get What You Want Out of Life: 1) identify clear goals, 2) identify problems, 3) diagnose problems, 4) create a plan how to deal with problems, 5) execute
      • remember that all people are wired very differently (they come from different backgrounds, have different experiences and goals)
      • in his book, Ray Dalio outlines framework for effective decision making: first learn, then decide (be aware of harmful emotions)
    • work principles
      • Ray Dalio believes in meritocracy and radical transparency for running organizations
      • hiring right people is most important thing
      • there is much more that can be found in¬†this¬†great, more detailed summary
  • The Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good Life
    • have good values
    • remember that you are not special
    • instead of chasing fame, try to be useful in what you do today
    • struggle for what makes you happy
    • remember that you are probably wrong about majority of things you have opinion about
    • when making decision, imagine yourself 5-10 years from now and think what would you do if you look back
  • Lean Enterprise (book worth reading more than once!)
    • focusing only on maximizing profits has the paradoxical effect of reducing
    • MVPs over long term efforts
    • solid CI is a must for rapid development
    • delivery in small batches is a key to success
    • get hypothesis from user research and validate with A/B testing
    • check this great summary for more
  • 100 Tricks to Appear Smart in Meetings
    • this is a sarcastic story how meaningless can actually play on people emotions and make a difference
    • top 10 tricks:¬†Draw a Venn diagram,¬†Translate percentage metrics into fractions,¬†Encourage everyone to ‚Äútake a step back”,¬†Nod continuously while pretending to take notes,¬†Repeat the last thing the engineer said, but very very slowly,¬†Ask ‚ÄúWill this scale?‚ÄĚ no matter what it is,¬†Pace around the room,¬†Ask the presenter to go back a slide,¬†Step out for a phone call,¬†Make fun of yourself
  • Seven Languages in Seven Weeks
    • great book presenting 7 totally different languages that get your out of your comfort zone
  • Measure What Matters
    • book about achieving results through OKR: Objectives and Key Results
    • approach is widely used at google
    • it’s all about defining specific goals (objectives) and steps that would take you there (key results)
  • Designing Data-Intensive Applications
    • this is bible for distributed systems, as well as good prep book for system design interview
  • Why we Sleep
    • probably the most influential book I read in 2019, made me reprioritize life
    • before reading this book, my priorities were: 1) working out and healthy eating, 2) work 3) hobbies
    • after reading this book, my priorities are: 1) sleep, 2) working out and healthy eating, 3) work, 4) hobbies
  • Hello, Startup – awesome book! See separate post.

I’m curious what did you read and learn. Share your thoughts. You can also follow me on GoodReads to stay up to date with my readings!

Hello, Startup – 360 overview of running tech business

Hello, Startup

Some time ago, Remo Jansen recommended me to check out awesome book Hello, Startup by Yevgeniy Brikman. I finally got into it, and I need to admit that it is a gem describing startup and tech World end-to-end.

Here are my key take aways:

  • Building successful company requires give or take 10 years (this is short overview why from other source).
  • These 10 years are not 955 work weeks, it’s 996 on the good days.
  • Tip: Have a notebook to write down any idea that comes to your mind. Even the most stupid one! You will be surprised when a few years later someone turn it into the product. Someone, but not you.
  • New business recipe: copy, transform, combine.
  • Initial startup idea requires many iterations. Always! Yevgeniy gives a lot of simple examples including creating resume (from very raw to very nice looking).
  • Doing things that don’t scale is ok at the beginning to validate the idea, you can automate later. Launching business that automates something? Hire vendors that would do it manually, and once it take off hire developers who will automate it. As automation and scaling is usually much more expensive.
  • Metrics to track:
    • acquisition – its sources, conversions and cost
    • activation – how many new users engage with the product, and why
    • retention – how many users stays after week, month, year…
    • referral – channels and conversions
    • revenue – month over month, year over year, CLV (Customer Lifetime Value)
    • magic number – e.g. once facebook user connects with 7 friends within 10 days they usually become highly engaged, for twitter it takes following 30 people, and for Slack – exchanging 2000 messages (how to find insights like that¬†by Andrew Chen)
  • Data-Driven Development: idea -> develop MVP -> A/B Test -> Release (requires well defined metrics and measurement tools)
  • Distribution channels for startups:
    • word of mouth
      • build better product
      • great customer service
      • build viral loops into your product
    • marketing
    • sales
      • automated – website checkout
      • inside – sales representatives at the store, or by phone
      • outside – “traveling salesmen”
    • branding (Apple = “Think different”, Red Bull = extreme sports, Nike = great athletes)
  • Use OSS and buy SaaS solutions for everything, but your competitive advantage (“secret sauce”).
  • Align tech stack with current market trends (in 2020 it’s much easier to hire React developer than Backbone developer).
  • Against Joel Spolsky opinion that rewrite is worst thing you can do, these days startups often change technologies (Twitter migration from RoR to Scala, Coursera moved from PHP to Scala or¬†AirBnB is moving from React Native to pure native). Thus do not worry too much about stack choice – treat it as it will eventually be rewritten. Microservice architecture over monolith helps with that!
  • Keep code clean! Good naming, conventions, DRY, SRP, tests. It can bite even within first year. Especially because at¬† Startup you will be constantly evolving existing code!
  • Company culture (mission and values) helps to avoid processes. People can trust each other to do the right thing.
  • First 5-10 hires can kill or make your company successful. Look for: “smart and get things done“, culture fit, communication skills and “would you be ok reporting to them?”.

This book is GOLD! I strongly recommend everyone to read it. Besides awesome 360 overview of startup World, there is a lot of great insights into everyday developer’s life. It’s worth to remember that pretty much every tech company is a startup…just in different phase.

If you are still in doubt, this book has 4.9/5 rating on Amazon and 4.45/5 on goodreads!

There is one quote from the book that I would like to finish this summary with:

I started asking, “What are the important problems of your field?” And after a week or so, “What important problems are you working on?” And after some more time I came in one day and said, “If what you are doing is not important, and if you don’t think it is going to lead to something important, why are you at Bell Labs working on it?”

Richard Hamming, You and Your Research

The Clean Coder: A Code of Conduct for Professional Programmers

The Clean Coder (Robert C. Martin)

You are probably familiar with Uncle Bob’s classic:¬†Clean Code. While Clean Code is about good engineering practices, and writing good code, The Clean Coder is more about communication¬†aspect of developer’s work. It’s about how to behave professionally, be disciplined, and stick to¬†good coding practices. What’s more, it demonstrates how to avoid common pitfalls¬†in software development process. Such as underestimating time, undergo management pressure or cutting corners (AKA writing bad code).

In Clean Coder, Uncle Bob is explaining by example how to communicate at work. Don’t try to be just a “nice guy”. Be professional and responsible,¬†while being polite. There is nothing worse than giving false promises just to make others happy. However, I have an impression that a lot of people are able to get away with that.

Does below sounds familiar to you?

Clean Coder - rush to complete

Do you remember a situation when you thought: “Damn, I wish I didn’t add this test. I would save a day”? What about situation like: “Damn, I wish I did add that¬†test. It would cost me 1 day, but I would save 2 days I spent fixing the bug this test would guard against”? I’ll let you to deal with the answer.

If you don’t want to read entire book, read first 3 chapters. It is a¬†great summary and advice on common wrong doing of most programmers that is not caused by their lack of proficiency, but rather not sticking to their professionalism and discipline.

Ohh…and if you have never heard about Uncle Bob checkout Every Uncle Bob Robert C Martin Video playlist on youtube, his blog, and SOLID principles. Uncle Bob is like your doctor who is telling you that you should eat healthy and exercise regularly. He has similar advises, but about how you should write code.

The Clean Coder is definitely one of the best books I’ve read about Software Development, and I’m adding it to my favorites.

Are you developer? What are your thoughts? Does some situations described in this book happened for you? Maybe you are business person? What do you think? Leave a comment!

Lean Startup

The Lean Startup (Eric Ries)

If you are building a product that is not yet released you should read this book. If you are building a product that is already released you should also read this book. If you are working on some overnight idea this is a must read! Why? In all cases it will help you to plan features, use data-driven approach for making decisions, and avoid waisting time by doing work that is not needed.

Eric Ries¬†describes – on example of his own startup – how his team wasted weeks and months of development work, by working on features that turned out to be not needed nor wanted by customers. To avoid such pitfall, he is proposing different approach: create simplest possible prototype, release it and wait for users’ feedback.

Lean startup is not only for startups. It is for everyone working on some product. From 1 person to international corporation. Eric gives great advice on how to evolve products and how to maximize your ROI (Return of Investment). He emphasize the importance of ability to reacting to feedback fast, not focusing too much on vanity metrics, but focusing on long term vision instead.

This book goes to my favorite books list!

If you haven’t read it yet, I strongly encourage you to do so. If you did, share your thoughts in comments!

Working Effectively with Legacy Code

I haven’t publish any book review for a while. It does not mean I am not reading books anymore. I just didn’t¬†feel that some of the books I read recently requires my recommendation, or I didn’t have any thoughts that I needed necessary to share right now.

I have added a few books to my favorite books list though. Check them out!

Working Effectively with Legacy Code deserves blog post because of a few reasons:

  1. Every Software Developer should read it
  2. It’s not really about legacy code
  3. Published in 2004 (12 years ago!) is still very up to date

Working Effectively with Legacy Code 1st Edition by Michael Feathers (Michael Feathers)

The book has three parts:

  1. Importance of unit tests when changing software
  2. Recipes for real World problems that we face when changing software (e.g., “I need to change a monster method” or “What methods should I test when¬†introducing a change”)
  3. Dependency-breaking techniques catalog

The first part should be familiar to most of programmers these days. If it is not for you then you should read Agile Principles, Patterns and Practices (by Robert Martin), TDD by Example (by Kent Beck), and The Art of Unit Testing (by Roy Osherove). You can thank me later.

The second part is the essence of the book. It shows, by example, how to add new feature, make a change to existing code, or fix a bug. Most books about software development, present examples on very simple, clean code that we never see in real World. This book, takes some messy piece of code and shows how to make it testable, how to get rid of too many side effects, and clean it up by separating dependencies and responsibilities. Many times we want to test one functionality, and then we realize that we need to instantiate tens of objects that other method depends on. Sounds familiar? This chapter shows how to handle that.

The last part (Dependency-Breaking Techniques) is very similar to Martin Fowler’s Refactoring: Improving the Design of Existing Code. It’s a set of techniques, and step by step description how to apply them to existing code.

As I mentioned earlier. This book is not really about legacy code. I think it is more about evolving existing code. It is natural, when adding features, we¬†add lines of code to the method. The hard part is to know when you should extract new method, or introduce a class, and refactor dependencies. It’s OK¬†to have global variables. The problem is to keep track of them or localize them.¬†How do you know, that adding a new functionality will not break something? You have 100% test coverage for every possible use case? That’s not possible because of¬†complexity of software we are creating today. “What¬†methods should I test” shows neat technique to backtrack effects, and side effects of a change that we are introducing.

There is much more, and¬†you should check out this book. You don’t have to read it from cover to cover. I strongly recommend you, at least, to scan through part 2 (changing software), and I am sure you will learn something new that you can apply¬†for your project today!