- AI
- ambiguity
- APIs
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- complexity
- computer history
- corporate life
- data
- decisions
- delivery
- devops
- end user tools
- ethics
- failure
- fear
- fundamentals
- gaming
- government
- halloween
- history
- humans
- hype
- identity
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- partnership
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Anti-Shunya for careers
I knew that the concept of zero (at least as a positional notation) was invented in India, but I didn’t learn the Sanskrit term for zero (Shunya) until last month. My friend and colleague Balasubramanian Ganesh (HSBC’s CIO for Retail Banking and Wealth Management) introduced me to this term, and explained how we are using this concept (and a load of cool instrumentation) to drive zero defects, zero incidents and zero vulnerabilities for software engineering.
Ganesh also asked me on stage at our Engineering Summit in Pune, India, to share some reflections on my career, and to offer advice on what has helped me reach my current position of Chief Architect for HSBC.
My reflection was that, while Shunya is a great goal for software, it’s not something I have followed in career terms: my career has been full of defects, incidents and vulnerabilities. That’s because it has taken a while to figure out what I am good at, and it turns out that, to figure out what you’re good at, you have to do some things that you’re not good at.
Rule zero: break any of these rules sooner than do anything outright nonsensical
In his essay Politics and the English Language, George Orwell proposed several rules for writing clearly: avoid dead metaphors, cut out unnecessary words, use the active rather than the passive tense and so on.
I think that the most important of these was Rule Six: ‘Break any of these rules sooner than say anything outright barbarous.’
In fact, I think that this rule is so important that those of us in the technology architecture profession ought to promote a modified version of it to Rule Zero, and let it stand at the head of any list of rules: ‘Break any of these rules rather than do anything outright nonsensical.’