This was a very eventful year for me with a lot of things going on in my personal and professional life. Throughout the year I felt bouts of anxiety on what’s to come next, and felt uneasy about the future. Eventually, the year turned out very well for me, and I was fortunate enough to receive the best outcome of all the paths that every aspect of life was taking. What’s interesting though is that my anxiety didn’t subside, it reduced from what it was, but it seemed like I had acquired this terrible habit of living in the future, and trying to predict what was to come, and quite often found myself down a rabbit-hole of worst case outcomes.

That was pretty much my trigger to buy a book on mindfulness, to try and learn to be present in the moment, and I think this is a good book to do just that. Give an introduction to mindfulness in a very simple accessible way, get you started on some form of meditation, and help you understand some of the concepts behind it. This book helped me in all of these things, and for the first time ever I started meditation as well. That alone is worth the time and energy spent in this book.

I feel like this book will be useful for someone who’s curious about mindfulness, and is not looking for something very comprehensive or in a guide like format. This book is about basics, and fundamentals, and if that is what you are looking for then I would recommend it.

Personally, one of the most fascinating things that is currently taking place in the software industry is the speed and frequency at which companies like Google, Amazon, Netflix etc. ship their code to production.

These companies are long past the age where a production deployment was a major milestone, and required a whirlwind of activity by many different teams to accomplish.

However, the majority of other companies are still a few years behind these players, and production releases are still a big deal, and are a quarterly event at best.

I have always been curious about how companies such as Google manage testing because in almost every project that I have worked on testing has been this huge monolithic activity that has given everyone headaches. And given how much time testing takes I couldn’t imagine how someone ships their code multiple times a day to production?!

How Google Test Software is a very insightful book into the leading practices and philosophy behind Google’s testing. It is written by people who have been deeply involved in testing for Google, and I’ll paste a little snippet about the authors here to give you a sense of their background and expertise on this subject.

James Whittaker is an engineering director at Google and has been responsible for testing Chrome, maps, and Google web apps. He used to work for Microsoft and was a professor before that. James is one of the best-known names in testing the world over.

Jason Arbon is a test engineer at Google and has been responsible for testing Google Desktop, Chrome, and Chrome OS. He also served as development lead for an array of open-source test tools and personalization experiments. He worked at Microsoft prior to joining Google.

Jeff Carollo is a software engineer in test at Google and has been responsible for testing Google Voice, Toolbar, Chrome, and Chrome OS. He has consulted with dozens of internal Google development teams helping them improve initial code quality. He converted to a software engineer in 2010 and leads development of Google+ APIs. He also worked at Microsoft prior to joining Google.”

The biggest takeaway for me from this book was the focus on automating tests, and on treating testers and developers the same way. The idea that a tester and a developer should have the same skills because the tester will ultimately write code to automate tests was new to me, and one that made a lot of sense if you think about test automation as one of the key things that will enable consistent quality and speed to market for your product.

Another wow moment for me was reading that in Google people raise bugs in the automated tests, and treat automated tests just as they would treat the code itself!

I also really liked the last chapter on the role of test engineers and test managers in the future, and how the authors see this shaping up. It is a little bit of a dire forecast if you are in this role yourself, but I do the see the industry tending in the direction of wanting fewer specialist testers and therefore test managers, and instead the mindset is shifting towards quality being the responsibility of every developer, and quality being baked into the development process itself.

Overall, I quite liked the book; I would however say that there seems to be a lot of repetition in the book, and it could have been a lot shorter without losing any of its key messages.  That being said, there’s a lot to learn from this book, and was a definite worthwhile read for me.