“Mastering API architecture” book review

Some time ago a blog post titled “Being glue” by Tanya Reilly caused some ripples in the IT industry. For some reason I remembered it when reading “Mastering API Architecture” by Gough, Bryant and Auburn.

 “Glue work” is the work that is something, that senior devs and upper ranks should do all the time. It’s the work, that must be done, but it tends to be “invisible”. It does not bring the palpable results – not only because it’s impossible, but companies/teams usually don’t event think about measuring it. Do you have a metric for onboarding time of the new member in your team? Yeah, didn’t think so.

Why am I mentioning this? Because as I was reading “Mastering API Architecture”, my thinking was constantly seeing it, as that kind of “glue work”. Let me explain.

I have attended self-paced architecture courses, read tons of books and listened to all the podcasts. Unfortunately, there’s always some lack in them. I would argue, that they usually concentrate on the “big guys” – types of the architectures, consistency, separation of concerns and all the other big-picture ideas. On the other hand, specific, low-level materials about application refactoring or quality, are too low-level. I missed the ultimate source, that could cover the middle ground. That could answer lots of questions that arise during implementation phase. When you need to combine unicorns-and-rainbows diagrams and cloud, with the crude reality of your company, lack of tests, big ball of mud and corporate inertia. In my opinion – this book tries to achieve that. Unfortunately – only tries.

As usual, upon reading I was creating ANKI flashcards, for a future reference and learning. Unfortunately, with the book that has over 400 pages, I created not even 30 flashcards. Why? First of all – I have learnt nothing new from this book. The knowledge already existed in my brain. Cards I have created are mostly what I call “reminder flashcards”. As you may have guessed – they’re to remind me of something, not to present some new knowledge.

Do I regret reading this book then? Absolutely not! As I’m in the middle of my #SeniorDevRevamp project, I have chosen this book mostly for this reason. To gather and structurize the things that I already knew. Obviously, I was hoping to get more knowledge per se, but I got confidence instead. I proved to myself, that playing “House M.D. of legacy code” for the last three years, did not destroy my knack for architecture. I still got the moves 😉

Who should read this book then? People like me – aiming for comprehensive middle-ground summary. On the other hand, I would recommend it for all the devs that are somehow around mid-level (whatever that means nowadays), that are thinking about upping their game. As an entry-level material for the API topic, this book will serve them well.

1 comment