17.3.24

Build

I just finished Build: An Unorthodox Guide to Making Things Worth Making (Tony Fadell, 416 pages, 2022). This is remarkable book, from a special person.

When I think about great books, especially technical and business ones, the best archetype that pops-up to mind is having a first-hand story told by someone with loads of practical experience, and huge failures and successes accounts.

If you think alike, this is an indispensable book to your list. Tony Fadell started early, got into the “right spot” on his early 20’s, and worked his way up in an industry that went just up just like him. Tony basically worked on early versions of what one day would be the modern smartphone, 15 years before it became a real thing.

And so, when Steve Jobs got back control over Apple and tried desperately rebuilding the broken empire, Tony was at his prime, with a great team alongside, and was able to make the iPod. Some years later, he did the same again by leading the first two versions of the iPhone.

If that was not enough, he went on creating Nest after leaving Apple in 2008, which was later sold to Google in 2014 for 3.2B USD.

So, in terms of CV, it is very hard to beat someone like him. And it turns out that he is also very prolific in ideas and management style. Of course, he is also somewhat product of his time and shares different ideas of corporate cultures he was integrated to and co-creator of. But his vision on Apple and its style (like in the “visionary asshole” concept) and Google (which has too many perks spoiling its people and culture, according to Tony) also shows his critical thinking on two of the mammoths of our technological age.

And I’m not exactly sure how it may have been to work for someone like Tony. But I’m sure that people like him are the ones behind many of the central pieces of hardware we can’t simply live our lives without anymore. Not that he would do much alone, single-handedly, but the ones like Tony are almost a sine-qua-non to push people (lots of people!) to building really innovative products. And that’s why I love this book, and its honest approach on how hard it is to make things worth making.

4.2.24

97 Principles for Software Architects

I just concluded 97 Principles for Software Architects – Axioms for Practitioners (Multiple authors, 2020), and it was a great journey.

To start with, it is not usual to have such a large collection of chapters put together by so many different practitioners. At least it is unusual for me to read or listen to something like that. But, in this case, I must say it works.

And it does so because of the quality of the voices put together. And the cadence of the change of topics and perspectives along the way. Although I know little to nothing about the experienced software architects behind each chapter, I understood right-away they are indeed experts in their field. In short, due to the sheer amount of high quality and relevant insights they present.

Being a great software architect is all about trade-offs. It is all about people, technology, business, and a whole bunch of other things. It is simply too overreaching to simplify it any way. There are always multiple layers of meaning and considerations behind the skills required of a good architect.

That’s again why 97 Principles makes for such a great companion. It brings a large number of relevant discussions, distilled from multiple and diverse real-life experiences. If you’re a software architect, or an aspiring one, you will not be disappointed.

1.2.24

Team Topologies

I concluded recently Team Topologies – Organizing Business and Technology Teams for Fast Flow (Matthew Skelton, Manuel Pais, 2019, 240 pages), and I think this is an impressive book for those thinking about how to organize teams in a software company.

I’ve actually started noticing this book as a reference in several other good books about technology, products and teams that I read in the last couple of years. So, I knew this would be good. But it actually surpassed my expectations.

What is so interesting here is that this book builds on top of solid traditions of Agile, Lean, DevOps, etc., and focuses on the problem of organizing teams. To start with, teams are the unit we all should have adopted for getting complex work done. That’s because of the sheer brain bandwidth required to deal with hard problems or complex systems.

Then, one of the ideas I like the most here is that stream-aligned teams are key to keeping the flow from the tech side to the final users. Stream-aligned just means aligned with value streams in the company, which ties it back perfectly with the overall business goal in the organization. The book brings lots of ideas about how to organize such teams.

In addition, complex sub-system teams, platform teams and enabling teams are the remaining team types that all other teams can be mapped to. With only 4 team types, and some pattern of expectation on how these teams will work and interact with others, the whole structure can be much easier to understand and implement.

If those ideas sound interesting, this book is definitely a great reading for you too.

31.12.23

The Phoenix Project

I concluded today The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win (Gene Kim, Kevin Behr, and George Spafford, 345 pages, 2013), and I think it is a great book.

This is actually a novel around very realistic and relevant organizational aspects and technology. Anyone with experience in IT operations or Software Development will recognize oneself in at least a few or many of the scenes along the story.

Building on the tradition of The Goal, by Eliyahu M. Goldratt, it follows an IT middle manager, Bill Palmer, who is suddenly promoted to VP of IT Operations, against his will, and is then confronted with a multitude of issues reflecting the organizational deficiencies and challenges in his company, Parts Unlimited.

Trying to juggle multiple issues thrown at him, Bill gets eventually the guidance of a mysterious board member candidate, Eric Reid, who guides his thoughts along understanding how much IT resembles manufacturing, and how flow, feedback, and continuous improvement (the Three Ways) can help turn the business around, and achieve the ultimate financial goals it so desperately needs.

I find the book a great source of inspiration and practical insights on how to direct a company towards DevOps practices, which was in great part promoted by this very book and its set of authors.

13.12.23

Only the Paranoid Survive

I recently concluded Only the Paranoid Survive – How to Exploit the Crisis Points that Challenge Every Company and Career (Andrew S. Grove, 224 pages), and it was great.

Andrew Grove is a legend. His is probably most known for his leadership during the time Intel moved

away from being a memory chip company, due to harsh Japanese competition on that market, in the mid-1980’s, to become the world’s leader in processing chip. Looking back, this may sound natural. But achieving it was all but so. The whole identity and soul of Intel, which Andrew helped founding, was based on memory chips. Moving away from it took an arduous period of 3 years, and really strong fighting by Andrew and, on the beginning, only a handful other managers that accepted the idea.

This is one of the stories the book discusses, with lots of insights on these strategic inflection points (which can actually last years!) which a company, or even an individual, has to go through sometimes. Several inflection points in retrospective become difficult to put the finger on exactly when it actually happened, as Andrew very well describes, because there is a process of changes going on before and after, and it can all turn out into a messy process. But totally necessary, if a company or person in crisis wants to survive and thrive.

Andrew has himself a fantastic personal story, having lived under Nazi and Soviet occupation in Budapest before emigrating to the US at the age of 20, where he managed to conclude a PhD in Berkeley, and later became the third CEO of Intel (1987-97). Yet, I found inspiring his clarity of thinking about his own limitations during his time as a leader of Intel, and how he for example gives credits to plant manufacturing managers for starting taking practical decisions in allocating more processing chip production even at the time when he himself had difficulties in admitting the company needed a drastic change. His humility and openness are remarkable.

And the book also takes on the importance of constant learning and being “paranoid” about changes that may impact one’s business. With the caveat that Andrew points out that even employees should see themselves as a business, selling some service in a competitive and ever-changing environment.

So, because of all of that and lots more that I fail to describe, I think this is a great book, that is worth the time for someone looking for solid substance in a technology world that is fluently unpredictable.

26.11.23

The Art of War

The Art of War (Sun Tzu, 68 pages) is a classic, and i has long been in my list. Now I’ve finally completed it. And it was less than an overwhelming experience.

To be fair, this short book is probably more interesting due to his history than to the very content. It is after all a book written roughly 500 BC!

Also, it describes in a way timeless strategic lessons around war. The fact that we unfortunately still have critical military conflicts being fought in different parts of the world today, makes the content of this treaty still very actual.

However, it is not necessarily a complete manual on how to actually do all aspects of war. As it couldn’t be in any case. It is more like a poetic description on some key general aspects of war and peace. And, in that perspective, it is indeed a nice and interesting piece.

As I have already read some other great books on history, strategy, and war, this one gets somewhat pale in comparison. But it is still worth the time, especially due to its historical significance.

21.11.23

Hacking: 3 Books in 1

I recently concluded Hacking: 3 Books in 1 (Alex Wagner, 2019, 716 pages). It was an interesting introduction to different concepts and ways of thinking around ethical and non-ethical hacking.

I’m a Computer Engineer by background, but have worked most of my professional years in software products. The topics on this book are therefore somehow marginal to my field of action. Although several definitions and practices made sense right-away, because of my familiarity with the foundations of the digital world, other topics were relatively new to me.

For example, as is the case for most of us, I’ve also been exposed to multiple hacking attempts. Especially to Social Engineering techniques. But I quickly rebut suspicious attempts, and never understood what happens next to those that fall pray to some of these techniques. The book describes that in details, which I found very interesting to learn more about.

Other hands-on techniques on Kali Linux are also described in details. For me, these were interesting and curious, and also a way to get an overview without actually trying any of those.

So, in short, if your purpose is to get a good introduction into the world of security and hacking techniques, as it was in my case, this book is a great resource.

9.11.23

Radical Candor

I just finished Radical Candor – How to Get What You Want by Saying What You Mean (Kim Scott, 336 pages, 2019). I highly recommend this reading.

The first time I came across the basic ideas in this book was through a TED talk by the author a while ago. It had some interesting insights on how to give good guidance through feedback, and some good stories too. But it did not prompt me to try getting hold of the book.

In some other recent readings, however, I got a reference to this book again, and I decided to give it a try. It was a good move.

The book contains indeed lots of interesting first-hand stories, which only an author who has hold positions like Kim has could offer. Because of her many years at Google and Apple, among others, and the knowledge and experiences she acquired in her career.

Not to say that all that happens at Google and Apple is necessarily good, despite their enormous technological and financial success. But to say that such big corporations have had the time and resources to try and act on developing a good culture over time. And Kim has been a part of that.

At the core, the main message goes something like that: if one really cares about his or her peers, giving honest feedback is the best way to help them. If everyone around are candid with each other, giving and receiving clear and honest feedback, a great culture can blossom.

Lots of other practical insights and tips follow. And they are worth reading through.

In short, this is a very interesting and useful book. The time spent on it is a great investment for those wanting to achieve a more meaningful work-life.

14.9.23

Side Hustle

I just finished Side Hustle – From Idea to Income in 27 Days (Chris Guillebeau, 2017, 272 pages). Although the title for this book sounds very appealing, the content is a less interesting than one could expect.

If you like a stories-based book, with some examples and a To-Do list that will inspire you to solve a hard problem, then this might be a book for you.

However, if you want more rigor than just following some few examples of people that made things happen, then it may just not work.

The problem with books like this one is that a few inspiring examples and some generic advice is not good enough to show you how to really do something. It can be helpful to some, but it may also be misguiding to those trying to comprehend the chances and not only the rosy side of a few good examples.

As an example of interesting questions that go unanswered: what are the percentage of people who try building a side business? How many of those report success? How long the process take on average? What profiles or fields of operation are over-represented between those who managed? What are the evidences backing up any of these more generic claims?

In any case, once you know this is one of those books with simple encouraging steps and superficial justification, then it’s up to you if it can be useful or not.

27.8.23

Software Engineering at Google

I just concluded Software Engineering at Google – Lessons Learned from Programming Over Time (Titus Winters, Tom Manshreck, Hyrum Wright, 2020, 599 pages), and it was a long and surprisingly entertaining account of the main technical challenges behind the ascension of Google to being what it is today.

Just imagine a corporation growing from a few engineers in the late 1990’s to having over 30.000 engineers, maintaining and improving an impressive repository of over 2 billion lines of code!

In a sense, Google’s story is unique. The scientific background of the founders, and technical ingenuity of its incredible pool of talent, together with some quite unique business practices and value-based management (not covered in this book, but mentioned in some other books on this blog), made possible this colossus of a company that we see today.

This book is but a reflection of the qualities of the company, which is open to talk publicly about its technical innovations in detail, and even the weaknesses and failures committed along the way.

In the meanwhile, the findings and technical advances Google did in software engineering have to a great extent shaped the computing industry as a whole. And what are the main topics involved in the technical history of Google, you may ask? Well, there are plenty.

To start with, there is the simple and yet powerful distinction made in the book between programming (creating a piece of code that works here and now) and software engineering (building code that can last, and adapt, on long term; decades, in Google’s case). This distinction is spot on, because it permeates most of the main challenges that come up when scaling.

Unit testing, for example, is something Google learned and started adopting in 2005, to basically give confidence in further changes over the growing code base for the Google Web Server. Code review, and all the internal tooling created for it is another great asset in the company, shaping its culture from the beginning, and properly scaled-up over time.

Building, and the continuous integration (CI) of changes is yet another area where massive tooling were added over time, allowing for performant distributed builds of parts of their large code base.

By the way, the choice to keep the code in just one repository (Google’s famous Monorepo), and all the work around managing code dependencies is also described in great details in the book.

In addition, very interesting discussions over the evolution of CaaS (Compute as a Service) brings great food for thought, with the many trade-offs between the multiple options for “sourcing hardware”. From running code on local workstation, to managing (or not) virtual machines and containers, to serverless architecture.

Finally, the multiple effects of Hyrum’s law is another very interesting aspect of this book. Basically, the law states that “any observable state of a system may come to be relied upon”. At the scale Google operates, this plays a significant role, not only technically with the multiple challenges associated, but also business-wise, since different systems at Google, whose idiosyncrasies some clients may come to depend on, may also need to evolve over time, in order to keep up with the pace of technology. I find, therefore, this book to be a fascinating insight over a successful technological evolution for a company that is a daily part of billions of people’s lives, including mine.