Designing Interfaces

I finished reading Designing Interfaces – 2nd Edition (Jenifer Tidwell, 2011, 547 pages). It was a comprehensive reading on GUI visual design, and it gave me input for lots of reflections on this topic.

To start with, I must say that this book has been on my shelf for over 10 years now. Firstly, because I start by using it as a reference book only, which is perfectly fine. But I also had the intention to eventually read it throughout, to gain some extra insights on multiple related topics. I lacked however the energy and motivation to do so. Until now.

The fact that this book was seating here for so long also means that it got somewhat outdated. And that is reflected on the fact that a third edition of the book was released not long ago. That being said, it is also true that the main design principles remain the same, even though the technology and GUI tech stacks have advanced significantly over the last decade.

What I like in a book like this is that it serves as an exhaustive way of filling the brain with all the main concerns there are around a given important field of knowledge. And user interface design is a very important field of knowledge for me.

Designing Interfaces delivers very well on exactly that, starting from how different people learn new things, and developing on all the main areas related to user interface design (discovery, input, action, presentation layout, etc.), to some of the main general principles behind aesthetics in user experience.

If this sounds interesting, and you have the energy and motivation, you won’t regret reading the book. Although the most recent edition is probably the best choice.

The Pragmatic Programmer

I just concluded The Pragmatic Programmer – 20^th Anniversary Edition (David Thomas, Andrew Hunt, 352 pages). And I quite enjoyed it.

Although I’ve been programming myself for now over 20 years, I still think there is plenty to learn and reflect upon the art and craft of programming. This book is a great tool in such a process.

Firstly, because it is quite rich in content. It covers a lot of details in and around programming that are very central to the profession. For example, source control, build automation, and testing practices. Some opinions and recommendations in the book go against common practices. But always with great arguments, and with the weight of professionals who have “been there, done that”.

Secondly, the reflection parts of the book are extremely good, in my opinion. The authors don’t fight shy of discussing topics like ethics, different measurements of success, and even things like the horizon of personal choices that goes beyond the minutiae of all technical details a developer typically deals with on a daily basis.

This book is, in short, great. It could be argued that it has even more relevance for younger engineers. But I can assure that anyone into programming, independent of the level of experience, will benefit from it.

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.

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.

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.