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]