Collage of Thoughts - IX

I recently rediscovered Grady Booch (for his take on AI), and while scrolling through his feed, I chanced upon his recommendation of the classic systems book, Systemantics – published in 1975, by a Pediatrician (to add to the impressive list of physician writers like Chekhov, Doyle, Hosseini, ..)! It’s a philosophical book about all kinds of large, complex systems that we humans build – how they work, and how they fail. Although software systems hardly existed back then, it’s a timeless and influential book that has inspired modern system designers in our world too!

While the book is a witty, light-hearted account of how Systems display antics – there’s uncanny truth and wisdom behind the axioms it lays out – we would learn them anyway the hard way, through experience. Jotting down a handful such gems of wisdom –

-             The crucial variables are discovered by accident (Chaos Engineering?)
-             When a fail-safe System fails, it fails by failing to fail-safe (Titanic? Our state-of-the-art distributed systems?)
-             Any large System is going to be operating most of the time in failure mode (Fallacies of Distributed Computing?)
-             A System is no better than it’s sensory organs/If it’s not official, it hasn’t happened/The chart is not the patient/In complex systems, malfunction or even total non-function may not be detectable for long/Eventually, your own perspective gets distorted by being in the System (Observability? Our systems are far more intangible than the human body, and the only way to “observe” them is to stack up more code to diagnose our running code/systems!)
-             Systems tend to grow, and as they grow, they encroach/The System does not do what it says it’s doing.

A few years ago, I was part of a team evaluating a vendor offering of a low-code platform. I skipped the prototype/happy-path considerations to delve into the non-trivial aspects of dev., and as I was growing impatient with the evasive answers to my enquires – a really senior person, who had the gift of plain-speak, recalled how a project had adopted a leading LCDP 1.5y ago, and how the team had never stopped coding since then! I think this is what Neal Ford refers to as the 80-90% trap – you are already struggling at the 80% mark, hacking your way by bending/twisting the tool to somehow reach the 90% mark (by straying too far into wilderness!), at which juncture you have hit the limits, and no further progress is possible. At this wild juncture, what really matters is how naturally/elegantly can you fall back to custom dev.

But if you have stopped even questioning what you have given away in return, and have happily settled for whatever and however the tool delivers; or stopped wondering why your municipal corporation mandates you to do your unit-area-assessment for them, and yet runs an Assessment Dept – then – as the author rightly affirms, the system’s encroachment is now complete! :)

#systemantics #systemsbible

It’s a common misconception that tech lacks in soft-skills. Context matters, and the soft-skills in tech just manifest differently, as they are quite intertwined with the hard-skills. There’s craft and creativity inherent in all of design, architecture, coding, and in technical communication - and taste really does matter! Some of Gregor Hohpe’s talks on platform/architecture mindset are a masterclass in clarity, style and precision (check out his AWS Innovate Keynote “Thinking like a cloud architect”); just as Khaled Hosseini’s books are an absolute masterclass in creative writing! And perhaps subtle learning by just watching the masters of your craft in action is the most engaging way of honing your soft-skills in tech.

#softskills #tech

Learning is practically free today – you don’t have to clear a tough entry-barrier or pay a hefty fee to learn from the best of minds. This is the best time to be a student, and it makes more sense than ever to be highly selective about who you learn from. Always start with the most authoritative in the subject-matter. If that’s too dense for you (I recall an old session where Eric Evans polled the audience on how many could read his DDD book beyond the first few chapters!), downgrade to the next best that’s accessible to you. If a book is too much of a time investment, listen to original talks "straight from the horse's mouth". To learn about Data Mesh, read the original book by Zhamak or, listen to her keynotes/talks. If that’s too abstract, supplement it with another authoritative book that talks more concrete. Just do not settle for any random trainer/youtuber interpreting and translating a large or complex subject-matter for you - that sort of "gyaan" is free and most abundant, but almost everything is lost in those repeat layers of shallow translations.

#learning

[Re-posted from my recently authored posts on LinkedIn]