Collage of Thoughts - XI

Many years ago, I joined a really good architecture group at a large consulting org. I have the highest regard for the top ~1% in tech consulting (I would never make it to that tier), and I met a few there who easily fell into that cream layer - folks who built strong skills despite being pulled in all different directions. Things started well until I was eventually "sacrificed" to a high-stakes yet low-quality project. After a few frustrating months of no way out, I decided it was enough and that it was time to leave. The org then made a retention effort I never expected - I was referred to their flagship global technology group, who were ready to absorb me. The group was said to be very selective about their engagements, and to really care about the "quality of revenue" they brought in. Glad I didn't stay back, as an architect from that very group eventually replaced me; and I realised that nobody is really safe from being sacrificed when the money is good and stakeholder's noise and drama, rather than sanity, start dictating all decisions.

A lot of tech resumes talk about how much of $ impact they drove - that metric in itself means nothing at all about your tech competence or judgment, it can even be achieved by just toeing the line to move up the ladder. Ironically, almost every major technical debt story has its origins in business stakeholders hijacking tech decisions (by throwing around $$ impact), with their short-sightedness in technical matters and no understanding of the tech trade-offs whatever. That's where the spiral starts. If, for years and across different work environments, you have repeatedly found yourself as the only tech voice in large group meetings and wondered why tech is always so "under-represented" - that imbalance is by design, so the sole voice can be "managed". Majority opinion, even when misinformed, carries brute-force power - after all, what you hear back on any subject is that majority opinion echoing from all sides (can't help think of Ayn Rand's Anthem!). If you have seen the dumbest of ideas being glamorously sold in polished slides, the salesperson is playing to that very gallery and producing their desired effect.

You have seen this movie enough times that it's grown dull - and you have developed an uncanny ability to predict what comes next, and how it ultimately ends.

#TechDebt #TechStories

Ted Neward, in an old talk, spoke about how anyone can easily tell the difference between a prototype (model) of a building and a real one, and would be sensible enough not to insist on shipping the prototype. However, software may be the only field so ephemeral and abstract that people outside the development circle are so completely disconnected that they struggle to see any difference at all between a prototype and the real thing.

My gripe with frontend (not a comment on the frontend development space or its skills) has always been that, as the only "tangible" layer of software, it lowers the barrier to entry for idle commentary. Shift the conversation to backend, data, security, or platforms, and those "simply don't exist" in their universe - all the noise suddenly fades away.

Vibe-coding (no dev-literacy) has similarly lowered the barrier to entry for non-technical folks (even CXOs!) - to build hobby stuff that look like real. With this narrow but exciting first-ever exposure to tech - without even going through a full lifecycle - they end up reducing the entire world of tech to the "magic" they just experienced - a classic "unknown unknown" blind spot, you don't know what you don't know.

Buy decisions similarly lower the barrier to entry into tech adoption - if your only exposure to software is through ready-made tools delivered on a platter, which you had no role shaping, you have effectively always outsourced your thinking and never cultivated the rigour or, the critical holistic thinking it takes to shape and build software on an open canvas.

Gregor Hohpe wisely said that if and when everything else gets commoditised, the only differentiator would be your thoughts!

Look at the world around you, and you'll begin to value even seemingly simple traits like a strong common sense, self-awareness, a keen observation, clear and independent thinking and judgment (than mere repetition), a conscience and a spine.

#vibecoding #buildbuy #barrierstoentry #mindset

"The purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise" - Dijkstra.

To me, this quote is a reminder that abstraction does not imply hand-waving - it's about being precise about the things that matter the most. There's this wise quotation from Kent Beck - any decent answer to an interesting question begins, "it depends…".  If I recall right, it was Martin Fowler who added something to it along the lines of - ".. and an expert can explain exactly what it depends on!" (Google Search seems to be getting bad at surfacing older quotes). To me, Fowler here is talking about precision in inquiry. Effective abstraction begins by enquiring hard, existential questions that uncover a system's essence, so that essence can be expressed at the appropriate level of abstraction. I think DDD's Strategic Design accomplishes something similar by using bounded contexts, context maps, etc. concepts to model the business domain at a level of abstraction where it can be expressed and reasoned about with precision.

Diagrams and models are the primary artifacts through which abstractions are expressed. I have always been a believer in a strong writing culture (technical or otherwise), as it forces rigor in thinking and reasoning. If you can't document and reason through an idea clearly, you don't understand it - writing reveals the clarity of your thinking (or the lack of it) - in all its wholeness, coherence, consistency. Diagramming forces a higher form of thinking. Diagrams and models are essential artifacts I look for in any non-trivial technical communication. Modeling standards exist for a reason, and the right model teases out clarity that remains vague in language. Not to mention that large, complex systems cannot be reasoned about in any other way but through visual models. 

On a personal note, diagramming was the hardest-earned skill in my career. I don't (can't) think in images - on every official self-assessment test for visual imagery (aphantasia), I score a perfect blank. I still remember my first whiteboarding session when a senior asked me to sketch an LLD - I went totally blank and instead started coding the interfaces on the whiteboard. But the more I engaged with various modeling techniques, the deeper my appreciation grew for the unmatched value the right model brings. The same visualization struggle showed up again when I moved to doing architectural work (because the level of abstraction had changed). Over time, I realized that modeling is less about visual imagination (an innate ability should certainly help a lot!) and more about developing the mental models to reason about systems - diagrams being an externalization of those mental models. It's about learning to "see" systems (even if not literally through mental imagery!) - and once you see them, you can't unsee them. :)

#SystemsThinking #Modeling

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

Collage of Thoughts - X

A weekend filled with viral posts and memes of some Indian founders and chairs advocating absurd 70-90-hour workweeks brought to mind Albert Camus's "absurd hero" from his profoundly brilliant title essay, "The Myth of Sisyphus".

What drives someone is always an intriguing angle to explore in truly getting to know the person. Passion for work looks fundamentally different from unchecked ambition that seeks to rise at any cost. Any leader who has known passion first-hand knows it to be rare, intrinsic/autonomous, and impossible to mass-manufacture on command - you only stifle it by being a control freak!

Self-awareness, or the striking lack of it, is something that inevitably shows through in your behavior, revealing a great deal about how wholesome, graceful, and human your rise truly was in the first place. Yet, cultivating it requires introspection and hard work on one's inner self - an undertaking that might seem like an utter waste of time to many high achievers; and thus, we sadly end up with many lesser realized humans at the helm of things!

P.S. Elizabeth Gilbert's TED Talk, "Your Elusive Creative Genius", beautifully captures the essence - and even the struggles - of creativity and passion.

#selfawareness #passion

A couple of years back, I took part in an engineering leadership MBTI test alongside 15+ other IC and org/people leaders. I topped the introversion scale with a perfect 30/30! Next in line, three points behind, was a seasoned principal who was never spotted at regular group meetings - a true recluse I met only that one time. He seemed to have already attained his self-actualised state, while here I was, accepting every random meeting thrown my way! :-)

For me, the IC path is as much about my personality - an existential habit of questioning and seeking meaning and value - as it is about my love for high-caliber tech work. The path is a non-default one - you chose it, not because the system nudged you toward it, but in spite of it. In much of the tech industry, the management track tends to branch off too early - often before one gains any experience, let alone accomplishments, in the more seasoned, high-maturity technical roles - leaving those roles less directly understood outside the immediate community. In one talk, Ted Neward likened developer and management roles as coming from Venus versus Mars, where what fuels one often puts off the other - a pattern that persists into leadership roles.

As Khalil Gibran beautifully put it, "I have learned silence from the talkative". In my career across consulting and engineering, I've often learned as much - if not more - from those who "role-modeled" what to avoid, as from those who showed me what to embrace. People often describe IC roles as "solitary" - that's again where your personality comes in - it's precisely your love for quiet, focused, higher-end work that drew you to this path. You relate well with techies and thrive in tech discussions, and you would much rather troubleshoot a system than a human any day. :-) What makes the role challenging are the parts you never signed up for (especially true in the tech and architecture consulting industry) -

- Being surrounded by stakeholders with a distinctive love for elaborate meetings, ceremonies, plans/reports and the presence of spectators.
- Dealing with non-technical stakeholders who can't even tell the difference between functional and non-functional requirements, or between architecture, high-level and low-level design.
- Getting drawn into low-value meetings as a "standby", just to field adhoc tech questions at any level of detail as may arise.
- Being pulled in to front-end raw and non-technical context-gathering exercise (in lieu of documentation) that require little real technical maturity.
- Fielding urgent tech feasibility inquiries from non-technical stakeholders - where you see so many more dimensions than they can, and where any spot response feels like handing out a half-truth.

#TechLeadership #ICCareer

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

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]

Collage of Thoughts - VIII

Attended the 4-day #GIDS conference a month ago, with an employer-sponsored all-access pass. Managed to grab first-row seats for all luminary keynotes/sessions, but that’s just how far I went. ;) I am shy to approach celebs, so of course did not bother any of them before/after their sessions.

The most novel sessions for me were the keynote by Michael Carducci (an engaging speaker I hadn’t even known of before), and the session on App Security and open-source vulnerabilities by Steve Poole. Neal Ford’s keynote and sessions were great of course! - but I follow his work quite a bit, which took away from the novelty. Also there was a bit of overlap in content with his co-author’s - Mark Richards.

Steve Poole spoke of the global cybercrime industry’s gigantic turnover that could topple the 3rd-by-GDP nation, the upcoming bar-raising EU legislation that makes companies legally/criminally liable for shipping software with known vulnerabilities, and the role that tools like BOM Doctor could play in securing the SBOM (Software Bill of Materials), and in making provable, evidence-based releases.

Michael Carducci was a revelation. A real-life professional techie/architect, professional magician, and perhaps the most gifted of speakers in the speaker line-up; his keynote was aptly titled after the famous quote - "Any sufficiently advanced technology is indistinguishable from magic". He spoke of why it’s important for individuals and teams to cultivate range and breadth, and how creative problem-solving in wickedly complex domains demand several diverse mental models in your toolkit. And how finding a solution may just depend on one rare linchpin knowledge that comes from connecting ideas and mental models from two/more diverse domains at once. This keynote (and few other sessions) truly reflected his own range and breadth across various subject matters. He also treated the audience to a complimentary card trick, deftly partitioning red and black cards from a reversed and shuffled (by an audience member) deck – and I had my little Christie-fan moment! :)

#developersummit #GIDS

Ted Neward's "Managers are from Mars, Developers are from Venus" is a talk especially relevant for management consultants at a time when the McKinsey developer productivity measurement framework has evoked strong reactions from expert practitioners and industry stalwarts alike.

The talk gives a real peek into the recesses of a developer's mind when they are deep into coding. It explains the blank stares you get from them when you interrupt their "flow state", why they find your meetings so inhibiting to their progress, or why noise-levels on the floor should be as low as possible.

As many experts have pointed out - development is in fact a craft, where traditional management (command-and-control) and metrics fall apart. Having played quite a few tech roles in my career so far - I most enviously know dev to be the only role that lets you slip into a "flow-state" every single day. And as Ted rightly points out - "every human being craves this state" - if I may humbly add, provided they have ever known this state without resorting to any kind of substance abuse! :)

#devproductivity #flowstate

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

Collage of Thoughts - VII

In my first decade at work, I used to joke about Java being my mother-tongue. Then Scala and Big Data happened, and I looked at programming and patterns with fresh eyes. Clojure remained a distant dream. In 2018-end, I was rather abruptly pulled out of an IC role, wherein I put my head down and coded my entire day away - the IDE is such an introvert's delight! Enough of coding, I was told - as I got moved into "higher-impact" roles for good. Which meant alternating between architecture solutioning for proposals, consulting engagements, and delivery; with literally no sane moment left to code.

Each time I get back to coding, I realize there's so much of unfinished coding still left in me. I have no claim to greatness at this craft. Rather it's the very lack of it that makes it so ever- aspirational and awesome!

#coding #delight

There is a reason why language paradigms have evolved from procedural to OO to functional – each is about an evolved way of “thinking and approaching” a problem. Within each paradigm, there is, in turn, an expert catalog of documented patterns of reusable solutions to recurring problems.

Out of all these, syntax is the most superficial and “visible” part of a language. Any seasoned programmer knows that a language is way beyond just syntax - it has a "philosophy". And while mastering the syntax is relatively easy and mechanical, it takes relentless years of practice to master the paradigm – to “acquire the mindset”. Without an appreciation of the paradigm; you may still be thinking in C, but coding in Java - or worse in Scala! Your code would still compile, your Sonar dashboard would still go green – but nobody in native Scalaland would ever call it Scala!

P.S.: On modern language paradigms, I would recommend talks/books by Neal Ford, and Rich Hickey (Hickey's talks shine with directness and practical wisdom!).

#paradigmshift

In a highly engaging talk (The Scribe’s Oath) that dates back to 2015, Robert Martin makes a prophecy about the future of our industry being a highly regulated one. He warns that an impending catastrophe would be the turning point - a bug that would cause a massive loss of lives or fortunes! It’s a talk about the need for a professional code of ethics and a tighter internal culture of rigour; similar to any other critical profession.

Uncle Bob takes you through the journey of the software engineer through time – from being a not-so well-understood figure, to becoming a hero, and then down to a scapegoat! From drawing a parallel with the scribes in ancient civilisation who had a "special literacy" that the society critically depended on; to calling out the Volkswagen story of the CEO testifying before the Congress by putting the blame of cheating emission tests on a “few rogue software engineers” (the emissions scandal); to talking about confronting situations head-on where your morals feel compromised; to doing the math for arriving at an (astounding) estimate of the doubling-time of programmers (what he calls “an industry in a perpetual state of inexperience”); to explaining why the software discipline should internally police itself before the legislators do; to finally proposing his own version of the “Hippocratic Oath” – each piece of the narrative is a gem of an insight by an industry stalwart and a master storyteller who has seen it all!

And while he rightly alludes to a future where software engineers can land up in jail for not practising TDD properly; here is the oath from his toolkit that saves you from seeing that day! 😊

“#3 I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.”

Do watch it!

#robertmartin #softwareengineering #ethics

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

Collage of Thoughts - VI

"Being abstract is something profoundly different from being vague … " - Dijkstra

Same goes with "Agile" - regardless of how heavy your pitch is; if you are clueless and directionless, no methodology can save you.

Here are a few tell-tale signs of a very anti-agile structure and culture prevalent in most enterprises obsessed with "agile" -

- Fat layers of management/key decision makers who neither understand how softwares are built, nor how they work. Higher the ignorance, more the need to "control" that which you do not understand.

- Presence of legacy systems with ownerships spread across heavy departments/units; and ceremonious meetings to negotiate integration contracts.

- Dozens of connections/dependencies pointing to one person - the dreaded "God Class" that knows and does too much.

- A constant tension between productive work v/s overheads demanded by management. Reminds me of Kipling's words - "She sends 'em abroad on her own affairs, From the second she opens her eyes— One million Hows, two million Wheres, And seven million Whys!"

Agile is about a bunch of smart builders coming together in "self-organizing teams" - you are either smart at domain or, tech. There are no dimwits to be "managed". It's more of a choreography than an orchestra.

#antipatterns #antiagile

Let "teams" not be a sheer brute force of numbers. May they feed and nourish each other, and reinforce each other's faith in "team-work".

One dozen piggyback'ing on one individual is not "team-work". An individual's potential sacrificed in the name of the greater good of the team or the organization is not "team-work". Dumping all real work and risk onto one individual, while keeping yourself busy with routine or fancy work is not "team-work".

Ayn Rand beautifully portrays the horrors of the "one in all, and all in one" collective society of "equals" - where the quick-minded child with scholarly ambitions, who understood even before the teacher had spoken, is ultimately "chosen" for the vocation of a street-sweeper; as penalty for transgressing and rising above his fellow-brothers in having a "preference".

"He was enslaved by his birth, by his kin, by his race. But he broke their chains. .. But then he gave up all he had won, and fell lower than his savage beginning. .. What brought it to pass? What disaster took their reason away from men?.. The worship of the word "We.""

#Leadership #Team #Nourishment

It's a sad myth that managers "manage" dev projects/teams. Your dev leads are the real ones doing the bulk of the project management, in their carefree, by-the-way style - without making an ostentatious show out of it. That's "white-box" project management - they are not just blindly tracking an opaque task list prepared by the team. And that's in addition to their technical job - individual contribution, tech leadership/guidance and, of course, tech representation in all stakeholder meetings. Everything about planning as well - from scope evaluation, work breakdown, estimates, the right parallelism, the right scheduling, the right skills/people-needs - is done and can only be done by an SME, not a manager.

Before beefing up your management layer while ignoring the bandwidth demands of your technology leadership, do assess whether that need is so real after all (the need should be external-focused). Too much of excess bandwidth at a layer that has no subject matter understanding, and no individual contribution to make (layman review and interference doesn't count as individual contribution - though Trump meddling with scientists is the unfortunate world we live in!), can cost an overloaded team tons of productive hours in fancy meetings and asks, and fancy action items as takeaways from such meetings.

As a pure-play manager; if you sincerely wish to contribute to the team's success, and not otherwise - practice and learn to step out of their way; and realize that it's incredibly taxing to answer all your layman questions; shield the team from all kinds of man-made complications and drama; and strictly refrain from "using" the team to fill up your excess bandwidth. If you feel empty without meetings, find yourself a like-minded counterpart and do yourselves the mutual favor of filling up each other's calendars.

#management #myth

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

Collage of Thoughts - V

Input: x + y = 10. Ask: Solve x and y within a 10% error margin. You look at them with rolling eyes. You tell them that's an infinite space of possibilities!! No takers for your answer. You are outnumbered - they are 20, you are 1. Sounds familiar?

#commonsense #majorityrule

To the layman user, the world begins-ends-and-revolves around the user-interface. S/he is happily unaware of the vast complex universe behind that makes the system a (pleasant) living reality. And that's perhaps how it should be.

When it comes to businesses, however, it is not only childish but also suicidal to be ignorant of; or, to wish away the role, size or, complexity of any work that is not directly "demoable". Businesses particularly have a hard time appreciating any effort spent on the non-functional; as they are the most "invisible", hardest-to-track by non-techies, and not instantly encashable in fancy demos.

Every architecture scales and performs in powerpoint. For businesses overly exposed to presentations, the quality attributes are mere clichés which magically get realized. Whereas nobody has ever seen a ppt execute to prove itself; code does everyday.

The next time you hear wild words being thrown at you - "quick", "agile", "demo", "mvp", "ai/ml" - with tons of features squeezed into a crazy timeline; you know exactly where the person is coming from - the user interface is his/her universe; and the vast complex system beyond simply doesn't exist. Sherlock Holmes would have remarked - "Dear Watson - You see, but you do not observe!" :-)

#seeing #observing

Architecture/Design is not just about drawing and connecting boxes. Coding is not just about typing syntax. Just like the last book you read - unless it was absolute crass - was not about frantically typing away words on paper.

Any finished artifact you "see" is the outcome of a creative and intellectual thought-process. The thought-process itself cannot be "seen". The only way to understand it is to have the ability to (critically) appreciate the artifact itself. Length is not a reliable measure of the thought or work that has gone in, and may well have an inverse relation. Whoever said it (Mark Twain?) - "I didn't have the time to write a short letter, so I wrote a long one". Economy of expression is often a sign of a clear, well-rested mind performing at an optimal, but controlled speed - whereas length is often a sign of rawness, noise and unfinished work left behind due to intellectual lethargy or lack of time.

Any team rightly deserves a manager who understands the work they produce. You are not a mail-forwarding proxy server, and you are not a calendar. Those functions can be automated. They look up to you as a human being in possession of a sound mind that can independently think and judge; and a spine that can stand up for what is right.

#knowledgeindustry #leadership

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

Collage of Thoughts - IV

Uncle Bob, in one of his lectures that has stuck with me for years, asks you to imagine yourself having an out-of-body experience and watching over your own open-heart surgery! How would you expect your surgeon to behave at this moment, even in the face of his deadline? Careful, deliberate, knowing what he is doing? The only way to go fast is to slow down and do a good job, and the bad code you wrote yesterday will slow you down today; he firmly reminds you.

Code Quality is perhaps the hardest-to-quantify metric in the industry. In many organizations, it stands for a bunch of static code analysis reports that gets fed to management dashboards. While certainly a good starter, they are far from adequate. Just like you can write a perfectly crappy novel even with the help of a writing assistant (for writing is way more than just structure, grammar, and textbook rules), so it goes with code.

Coding is akin to writing – it takes skills, experience, and thought. A prerequisite to sound thinking is "thairaav" (for lack of a better word in English) – the antithesis of what in Zen is symbolized by the "Monkey Mind" jumping around from one unrelated activity to another, settling on nothing. Building a coding culture in any organization starts with this realization.

#coding #culture

One of my favorite poems I recall particularly on this day is Tagore's "Let my country awake". Most Indians are familiar with the famous first line, of course. The poem is a grand vision of a truly "free" and progressive India; but the message is so universal and ageless that it applies equally to a progressive world, a progressive organization or, even to an individual's personal world and awakening. It reminds us of all that in our culture imprisons versus liberates us.

Here's the full version from Gitanjali, translated by the Nobel Laureate himself -

Where the mind is without fear and the head is held high;
Where knowledge is free;
Where the world has not been broken up into fragments by narrow domestic walls;
Where words come out from the depth of truth;
Where tireless striving stretches its arms towards perfection;
Where the clear stream of reason has not lost its way into the dreary desert sand of dead habit;
Where the mind is led forward by thee into ever-widening thought and action–
Into that heaven of freedom, my Father, let my country awake.

#tagore #culturetransformation #india #republicday

There are no unqualified problem statements in the real world. Any real-world objective function comes with it's (externally) stated set of equations/inequations that bound the feasibility zone of finding an optima. An optima that goes beyond these extremities is hence a mathematically impossible ask. A mutually contradictory set of constraints can even make this feasible zone vanish completely, making the problem itself an infeasible one to solve. Often times, while judging the merit of a solution, one gets too obsessed with the objective, while being lazily ignorant of the set of constraints the objective was subject to.

#problemsolving #review

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

Collage of Thoughts - III

Of all perspectives on mentorship I have come across, my favorite is from an insightful chapter of the novel Siddhartha. The book narrates the journey of another Buddha in the making.

When a young Siddhartha and his friends get to meet the enlightened Buddha - while his friends yearn to be accepted as disciples; Siddhartha, though immensely impressed, decidedly stays away.

In an interesting dialogue that follows, Siddhartha is effectively telling the Buddha that I don't want to the best Buddhist; I want to be a Buddha! And even the Buddha himself cannot teach me how to become one!

I think same goes for even us, the lesser mortals, in any field of life. Experience and realization can neither be "taught" nor "transferred" as-is. They are best meant to be sought and gained first-hand in distinct, personal ways.

Leaving you with these wise words from the Nobel Laureate's celebrated work -

".. But there is one thing which these so clear, these so venerable teachings do not contain: they do not contain the mystery of what the exalted one has experienced for himself, he alone among hundreds of thousands."

#mentorship

In his TED talk, and his book "Flow", Mihaly Csikszentmihalyi describes the "flow state" as being a state of intense focus and complete absorption in an activity, for it's own intrinsic sake. Interestingly, he describes one of the key conditions that induces such a state, as being in a zone where your skills either match or, can be stretched to match a worthwhile challenge at hand. When the challenge is relatively too low for your skills, you experience boredom; while in the reverse scenario, you experience anxiety. He also talks about the altered sense of time you experience in this state of mind.

So, when was the last time you found yourself working an odd hour? - not because you had a deadline to meet, not because you had been asked to, not because you were driven by external rewards and praise, not even out of a noble sense of duty - but simply because the task at hand felt so worthy and challenging in itself, and your skills felt so perfectly utilized, that you couldn't wait for the next day to see what you have built! :-)

#workplace #engagement #productivity #happiness

Technology is under-represented in the leadership across the industry, and no diversity council in the world happens to question that. The tech pipeline of your organization just mirrors that, as success gets blindly copied as a formula.

A general awareness of tech jargons, trends, and case studies is not to be confused with tech capability, and in itself doesn't qualify one for a tech position. Just like googling/researching about COVID doesn't make me a doctor. "Talk is cheap", as Linus Torvalds aptly puts it.

Regardless of which one of the plethora of fancy tech titles you hold; if all you do is delegate, coordinate, control, streamline processes, conduct so-called "reviews", and give out knee-jerk reactions when things go wrong; you are an administrator, not a techie.

When you review my work, make sure you understand the technical subject matter, and review substance over anything else. If you can line up an army of "reviewers" for every contributor; that itself is a worrying metric. As a rational being, the least I cannot help but do is question what qualified each one of you to show up for that review session. And I would expect the army to collectively be a powerhouse of technical expertise and competence, and share some real feedback.

#technology #leadership

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

Aaj Jaane Ki Zid

Time and again, many great singers have attempted, but have failed to match up to the legendary Farida Khanum in her unforgettable rendition of "Aaj Jaane Ki Zid"! Last week, thanks to my sister-in-law, I heard this purely instrumental attempt (a fusion sitar-tabla-violin trio) that instantly felt so right! Unfortunately, I don't even know the name of the artists - but what a fine, nuanced performance! This appears to be a limited-audience mehfil in our neighbour country, with Rahat Fateh Ali Khan gracing the occassion!

I usually connect better with a vocal performance any day. Verses and vocal expressions are important, in that they convey rich context and feelings, thereby lending more soul to music.

In this exquisite performance, however, the lead artist has attained the outsized goal of almost blending the singer and the musician into one! - effortlessly moving back-and-forth between extreme restraint in playing the vocal sections, and intense adventure over the musical sections which he owns exclusively! You almost get to experience a soft, nuanced and very measured singer seamlessly morph into a bold and unrestrained musician in masterly command of his every stroke, nonetheless! Check it out and judge for yourself! :-)

Collage of Thoughts - II

Try and recall the most productive and skilled individual contributor you have ever watched closely in action. Think of the signal-to-noise ratio in his/her one undisturbed hour of "flow".

Now try and recall the most productive group meeting you have ever been a part of. What hard skills did it take? What was the signal-to-noise ratio in this meeting like? How many person hours did this one hour of meeting consume? Weigh that against the outcome the group as a whole produced in that one hour.

Group meetings are highly overrated and overdone, and generally contribute to your self-importance and your time-sheet. Two is company, three is a crowd.. and one is transcendence. Great work stands on the shoulders of giant individual contributors, who you let be masters of their own time and work.

If, as a leader or as an organization, you are okay with losing this giant share of productivity and magic to the mediocracy of meetings; that's your loss.

Modern development takes an incredible level and mix of skills ranging from problem-solving, to design elegance, to language nuances and fluency, to mastering the intricacies of every framework, technology and tool in use – all in unison!

Many of these may even have been non-existent a few years ago. Technology landscape and paradigms shift often, and enough to topple all your old practices and limits - so that what was your best practice is now an anti-pattern or plain redundant.

So, as an architect, are you still qualified to lead a modern dev team? It's a tall order, especially if you have cross-skills.

   - When was the last time you have written complex production code in this same space?
   - How updated are you with new languages or versions?

If you have answered poorly (I haven’t impressed myself either!), do you have the bandwidth and focus at work and a personal urge and passion to catch up?

If no - strictly keep your old-school ideas to yourself and make way for the new generation of leads. Just having problem-solving skills without up-to-date tech skills, doesn’t qualify you to lead (if you knew better, it might be a solved problem in that technology already!). You will do more of a disservice to the team and take them behind many years, otherwise.

Which book would you imagine is the best to read in such an absurd time? I would imagine it’s Camus’ “The Plague” - though I would prefer to grab a paperback and not read an electronic copy.

Camus’ “The Stranger” had lingered on my thoughts for long, and perhaps I understood it better after I read his essay “The Myth of Sisyphus” – wherein I got a clearer glimpse of his “absurd hero”, in his immensely powerful expression of stoicism in the face of an overwhelming and inescapable absurdity. It’s a different brand of stoicism from Viktor Frankl’s “Man's Search for Meaning”, wherein the author personally bears testimony to witnessing a handful few (including himself) discover meaning even in the worst of human circumstances. Camus’ stoicism stems from defiance and scorn, rather than as a response to/submission to a higher force.

As someone who would question and search for meaning in everything, these books held a strange appeal for me. You would be drawn towards the characters and be left wondering whether what you see is ultimate dispassion or ultimate passion - perhaps two sides of the same coin. And perhaps the ones who have mastered enough and are capable of the highest passions, are also the ones capable of the deepest dispassion.

Do read Camus, if you get a chance. :-)

Last week marked the 25th birth anniversary of #Java. I owe this language, and the JVM platform so much! I had professionally embraced Java by choice than by chance; by giving up my campus job in Mainframe (biggies don't care about a fresher's inclination). Rather than having to maintain COBOL for a living, Java gave me not just a good living but so much exposure to modern software development at large!

There is a wise saying that resonates deeply with me - "Tell me and I forget. Teach me and I remember. Involve me and I learn." Having spent innumerable quiet and productive hours building software with Java, Scala and the JVM ecosystem at large; Java/JVM has taught me whatever I know of Enterprise Backend, Distributed Systems, and Big Data. It has taught me the joy of thinking, designing, and programming in OO and functional paradigms. It has also taught me what a thriving ecosystem and community can build around an open source platform (we moved to Amazon Corretto OpenJDK, when Oracle started charging for Java LTS).

I only hope I have earned a rightful claim to call JVM my home-ground, and Java my mother-tongue (though it's been more of Scala, of late). It's more of a hard-earned deep familiarity than any expertise I have a claim to.

Long live Java & the JVM! #MovedByJava #jvm

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

Collage of Thoughts

Somewhat ironically mirroring real-life progression; I believe most people in career start off by suffering from near-sightedness (can't focus on far objects), and later develop long-sightedness (can't focus on close objects).

Both are vision problems; and a direct result of exclusively dealing with things too close or, too far off; at the neglect of the other side. Only a handful few of us, through conscious practice, learn to beautifully navigate back and forth as the situation demands. The lesser mortals (including me) need a "power correction", so that we can continue to "spot" and "see" the important things - be it close or far. Agree? :-)

Disclosure: Even with 15y+ of work experience; I am a self-confessed myopic always drawn to details, who wears big round glasses to see far off things. ;-)

Just like true players at heart, I believe, true practitioners in any field love to be on the ground up until the time they are either rendered unfit or, declared unfit to play the game anymore. Whereupon, they silently pack up and retire to the commentary box or to the gallery - watching and commenting about a game being played out at a far distance.

On and off, I get an opportunity to contribute to a high-end project with a steep "learning curve", in an IC role. Nothing pleases me more. I code in a high-intensity gym-mode, writing production-code perhaps no more than 1.5-2 hours a day; and still get considered "highly productive" in the team - a mode that can be sustained for such short bursts only, as I "burn" really fast. The rest of my working hours, I am quietly researching, learning, figuring out better ways to solve the problem, launching my code with a heightened pulse, watching and tuning how it behaves on the cluster, and attending highly focused discussions/meetings. But those 2 intense hours of execution, where "things just fall in place", make all the difference to my work and my day.

What does your most productive hour at work look like? :-)

It's been a long time since I had watched this brilliant talk by Rich Hickey, the father of Clojure, on simplicity in software. And his brutally honest talk still haunts me.

He starts by reminding you that simplicity is a prerequisite for reliability. I am sure it's a prerequisite for all other desired -ities as well, including agility.

He further clarifies that "simple" is objective, versus "easy" is subjective (a measure of your "familiarity" with something).

He talks of "essential/inherent complexity", which is inherent to the problem versus "accidental/incidental complexity" - the complexity that was not required to solve the problem in the first place - basically "man made complexity" through convoluted approaches taken to a simple problem.

He draws an interesting parallel between "trying to make sense of, and untangle complexity" and juggling; and the human limitations of even the most amazing juggler in the world!

As techies, we are naturally drawn to problems that are "essentially complex", as opposed to addressing technical debt of a massive scale. As an architect, how many hours do you spend addressing "essential complexity" versus "accidental"? #architect #simplicity #agility #technicaldebt #productivity

As we patiently wait in hope, and contribute our bit towards containing the spread of #coronavirus; if your weekends suddenly feel empty, here are some tips from someone who is a natural at being socially aloof, and finds the world way too chatty and way too busy for the value we create. :-)

I remember a line from a Christie book I can't recall right now - that "lazing is an art". Not everybody can do it well.

Sleep - If you feel tired, just sleep without an alarm. And without guilt. Weekend mornings don't necessarily have to start at 8 AM. Jab jaago, tabhi savera! ;-)

Marathon reading - Pick up an unread book from your shelf, and soak yourself in it.

Learn by doing - Learn by doing something you have not had time for.

Contemplate - Turn inward. Think and feel deeply about something important you only had rushed time for. Thinking, at least deep thinking, is ultimately a solitary and a no-rush process.

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

Minimalism

To me, Zen stories stand for mindful living and minimalist habits. Likewise, they set a unique benchmark for coherence and minimalism in story-telling. Even though the message, quite often, may be subtle and even escape me altogether; as prose, they read like beautiful, concise and elegant blocks of programming code :) - having the same time-honored qualities of being simple, readable, single-purpose and piercingly precise! And they are profound and timeless! Which makes them a fascinating read any time.

One of the many stories that stand out in my memory from the book Zen Flesh, Zen Bones, is about a Zen master, who, having happily given away his last of material possessions to a thief he had caught red-handed; sits naked, basking in the moonlit sky, in quiet wonderment of creation. His only regret being that his moment of bliss and contentment under the moon cannot be given to the thief. The moon that shines on the thief alike, but is wholly lost on him. And the master knows that his real "riches" - a beautiful moment such as this - can neither be stolen, nor be given away to another at will!

Here's the Zen story, verbatim -

Ryokan, a Zen master, lived the simplest kind of life in a little hut at the foot of a mountain. One evening a thief visited the hut only to discover there was nothing in it to steal.

Ryokan returned and caught him. "You may have come a long way to visit me," he told the prowler, "and you should not return empty-handed. Please take my clothes as a gift. "

The thief was bewildered. He took the clothes and slunk away.

Ryokan sat naked, watching the moon. "Poor fellow, " he mused, "I wish I could give him this beautiful moon."

Source: The Moon Cannot be Stolen | ZEN FLESH, ZEN BONES

Reminds me also of the protagonist Lizzy, from the brilliant "Pride and Prejudice", acknowledging the same, as she puts herself in the shoes of her beloved sister on the latter's new found fortune - "Till I have your disposition, your goodness, I never can have your happiness."

The Better Story

"Life of Pi" had this beautiful philosophy about "choosing the better story"; which essentially tells you that ultimately it is how we interpret our own realities, based on our personal ideals, that gives meaning to our experiences and a shape/direction to our existence. It goes without saying that it takes a highly elevated state of mind-and-soul to actually work out "the better story" in the face of such utmost adversity!

As someone with zero visualization; thoughts (in the form of words, without an associated "vision" in the literal sense) and feelings are my only medium of exploring reality. Nonetheless, they are both rich and powerful. People naturally confuse a lack of "vision" (again, in the literal sense) with a lack of imagination - which is not really true. I actually do have quite a rich "inner life", not entirely bereft of imagination - and often so much richer than the world outside that it is only natural to "turn inward".

Would like to wrap up this post with these wonderful and precious insights from the Booker winning novel! -

The world isn't just the way it is. It is how we understand it, no? And in understanding something, we bring something to it, no? Doesn't that make life a story?

So tell me, since it makes no factual difference to you and you can't prove the question either way, which story do you prefer? Which is the better story?

It was my first clue that atheists are my brothers and sisters of a different faith, and every word they speak speaks of faith. Like me, they go as far as the legs of reason will carry them - and then they leap.

I can well imagine an atheist's last words: "White, white! L-L-Love! My God!" - and the deathbed leap of faith. Whereas the agnostic, if he stays true to his reasonable self, if he stays beholden to dry, yeastless factuality, might try to explain the warm light bathing him by saying, "Possibly a f-f-failing oxygenation of the b-b-brain," and, to the very end, lack imagination and miss the better story.

A Simple Tale of Wisdom

Amidst battling a nasty cold during this visit to Kolkata, I managed to rummage through and pull out this old possession of a book. It was an unusual gift of an expensive but used book, from a prominent sculptor/mural artist - Late Alokmoy/Alo Datta - on his very first visit to our place. I can't recall whether the date signed stands for the day he had acquired the book for himself (most likely), or the day he fondly gave it to us shortly after having read it. Either way, I was too young for this book, and it had taken me almost a decade thereafter to finally pick it up one fine day and finish it cover to cover. Now, with almost another decade gone by, what still lingers on my mind is it's beautifully-crafted one-pager gem of an opening tale! - a dead simple narrative with such a profound spiritual lesson in it! Check it out for yourself - bare your whole soul, and liberally soak in all the wisdom! :-)

Visualization

I had casually discovered this during my late school days – that "visualization" is for real, and almost everybody around me can literally visualize! Yesterday I came across a scientific name for this inability to visualize – it's called "Aphantasia" (absence of fantasy), and supposedly only about 2% of the population can't visualize! And if that 2% forms a spectrum, I am at the extreme 0-end – I see not even the vaguest hint of anything beyond what exists before me for real; eyes open or, shut! In sleep, however, I do certainly dream in clear colored visuals (I rarely dream). 😊

Since "a picture speaks a thousand words" – it certainly must be a very useful and interesting faculty to have in your toolbox – serving as a constant aid in learning, in thinking/conceiving, in storing and in recalling concepts. And especially as an architect, you can so literally "see the whole big picture" emerge right before your eyes! My memory would probably be something as drab as an object store – where you serialize, commit, and retrieve back entire objects wrapping data and data only!

To my advantage, though, I am far less distracted. Anyone who can magically conjure up all sorts of images at will, would necessarily need a lot of mental discipline to achieve the same tranquil depth or, the same intensity of inner focus that would come to me so naturally. Not sure if related, but I am highly effective at switching off almost all visual noise from my immediate surroundings at will (in contrast, I am pretty bad at filtering out/ignoring auditory noise). And I have other optimized "memory techniques" that may not be too commonplace either – e.g., I have some definite "edge-caching" mechanisms at play 😉 – where my fingertips mechanically "remember"/"cache" passwords whenever I type on my laptop (without making round-trips to my memory)!

Wanted to know if there are others like me who can’t conjure up images before their eyes? #diversity

[Simultaneously posted by me on LinkedIn]

The Joy of Building

Here's a nice and candid interview clip of Steve Jobs talking about the "doers" being the major "thinkers", and here's Linus Torvalds being much more blunt about "the hype" versus "the real work". These are things I have known only too well intuitively - that thinking and doing, like inseparable twins, nourish each other - but it's always heartening to see it coming from stalwarts of such stature!

My observation is that the doers are the major thinkers. The people that really create the things that change the industry are both the thinker-doer in the same person. .. There's just a tremendous amount of craftsmanship in between a great idea and a great product. And as you evolve that great idea, it changes and grows. It never comes out like it starts, because you learn a lot more as you get into the subtleties of it. .. And it's that process that is the magic!

— Steve Jobs

Fourteen years into this industry now, I still remain a firm believer in practicing my craft first-hand. Through all these years, I have had wonderful opportunities to think, do, learn, unlearn, diversify, grow and mature. I have been fortunate to work with a few really smart people who besides being great thinkers are great "doers" too. And all my choosiness about work/projects notwithstanding, I have enjoyed a tremendous amount of goodwill at work - right from my customers to my seniors, peers, and juniors alike. And I have known the joy and fulfillment of building and shipping consistently - an exercise that is so nurturing to your curiosity, creativity, and overall growth.

And through all this - absurd as it may sound to many - I have come to believe that a developer, designer, and architect can co-exist in one person; s/he stepping back or forward from time to time, to take up something challenging of each role. After all, which seasoned developer is not a designer too, and which seasoned designer is not an architect too?

On Beliefs and Perceptions ..

Lies –

Lots have been written about body language in the detection of lies. Isn’t inconsistency the true hallmark of lies? That is, if you believe there are no perfect lies or, liars. And that lies can ultimately be just as revealing as truth can be. As Christie had so rightly pointed out in one of her books –

For in the long run, either through a lie, or through truth, people were bound to give themselves away.

Closed-Ended –

Imagine being asked a personal question where you immediately realize that the enquirer has already decided upon a narrow and closed set of options in his/her mind; and is only trying to validate/eliminate each such option with you, so as to be able to reach a definite conclusion.

Real life outcomes may be a result of many intertwined stories. As human beings, wherever we lack real-life exposure, we are prone to over-simplifying – as when trying to trace back the one visible result to one of our preconceived and handful set of "obvious" possible causes – thereby grossly undermining the role, the impact, and the sheer diversity of stories possible.

Negative Role Models –

They serve us by being a living model and a stark reminder of everything we don’t want to be in our lives, and to teach us of what we can be or, become in spite of them. In the wise words of Khalil Gibran –

I have learned silence from the talkative, toleration from the intolerant, and kindness from the unkind; yet strange, I am ungrateful to these teachers.

Appearances –

We do realize that two extremely opposite things may appear the same. After all, that is what we call deception – the fake tries to imitate the real, and hence it’s only natural that it will assume the appearance of the real. Perhaps a more important realization, however, is that dangerously, the opposite is possible too – for the real to have the appearance of the fake; simply because the fake has imitated too far, leaving the real behind in the game – for we may not know what the real in any given circumstance looks like, and may consider the "more" to be the "real".

Originally posted by me on LinkedIn.

Simplicity

Came across this nice talk on the pursuit of simplicity in building software - by Rich Hickey, the father of Clojure. Apart from correcting a few mis-notions around the terminologies of simple versus easy, he also contributes his new-found dictionary word, "complect", to the software vocabulary! And goes on to draw such a nice parallel between the human limitations in dealing with complexity/complected pieces vis-a-vis those in juggling too many balls in the air. Here's his very apt analogy -

The average juggler can do three balls. The most amazing juggler in the world can do like nine balls or twelve, or something like that. They can't do twenty, or a hundred. We are all very limited. Compared to the complexity we can create, we are all statistically at the same point in our ability to understand it, which is not very good.

Tells you something about how important undivided time and attention really is, and why distractions, multi-tasking/context-switching are such sure productivity-killers for even the smartest amongst us!; and why some of the finest minds you meet seem to be frantically striving to simplify and avoid what has come to be known (and dreaded) in software as "accidental"/"incidental" complexity (as opposed to "essential"/"inherent" complexity) - un-tangling things so as to be able to grasp them in isolation, stripping them down to their bare essentials, and putting them neatly back into their right place.

The philosophy of simplicity, of course, uniformly applies to every facet of life in general - for instance, falsehood, in whichever of it's multifarious forms, hugely complicates life by tangling the true with something that is not true. And Christie would extol the virtue of simplicity even in unraveling mysteries! - by claiming that the simplest explanation is always the most likely! :)

Camus

Read Albert Camus's "The Stranger", and then this really nice essay "The Myth of Sisyphus". Both are stories of heroes caught up in a sudden, irrevocable, and downright absurd turn of fate. Rather than losing their heads over it, they rise up to stare back in the eyes of the enormous absurdity facing them - with calm indifference - and keep going, in utter defiance of it!

Sisyphus was a Greek mythological figure, who was condemned by the Gods to an eternity of futile and hopeless labor - wherein he had to roll a huge rock up a mountain, place it at the top, see it roll down, and start all over again at the bottom! - and repeat this whole pointless sequence ad infinitum!! - what Camus calls the "unspeakable penalty in which the whole being is exerted towards accomplishing nothing"! In the essay, Camus interestingly imagines and explores Sisyphus's state of mind as he descends the mountain. Here are some wonderful excerpts! -

I see that man going back down with a heavy yet measured step towards the torment of which he will never know the end. That hour like a breathing-space which returns as surely as his suffering, that is the hour of consciousness. At each of those moments when he leaves the heights and gradually sinks towards the lairs of the gods, he is superior to his fate. He is stronger than his rock.

Sisyphus, proletarian of the gods, powerless and rebellious, knows the whole extent of his wretched condition: it is what he thinks of during his descent. The lucidity that was to constitute his torture at the same time crowns his victory. There is no fate that cannot be surmounted by scorn.

I leave Sisyphus at the foot of the mountain! One always finds one's burden again. But Sisyphus teaches the higher fidelity that negates the gods and raises rocks. He, too, concludes that all is well. This universe henceforth without a master seems to him neither sterile nor futile. Each atom of that stone, each mineral flake of that night-filled mountain, in itself forms a world. The struggle itself towards the heights is enough to fill a man's heart. One must imagine Sisyphus happy.

And here's a full online version, for your reading!