- 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
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- robotics
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- talent
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Foundations of sand
When the 18th century Scottish philosopher was formulating his sceptical philosophy, he experienced a crisis of confidence, writing in the Treatise of Human Nature:
Where am I, or what? From what causes do I derive my existence, and to what condition shall I return? ... I am confounded with all these questions, and begin to fancy myself in the most deplorable condition imaginable, environed with the deepest darkness, and utterly deprived of the use of every member and faculty.
Fortunately, Hume finds that the concerns and distractions of every day life serve to dispel this gloom: that there is a way to doubt the very foundations of the world, and yet still to go on:
I dine, I play a game of backgammon, I converse, and am merry with my friends. And when, after three or four hours' amusement, I would return to these speculations, they appear so cold, and strained, and ridiculous, that I cannot find in my heart to enter into them any farther.
Innovation and application
A couple of months ago, I wrote about the book The Elements of Computing Systems, by Noam Nisan and Shimon Schocken, and how it was helping me traverse the layers of abstraction out of which computing is constructed. After many hours of reading, thinking and programming, I am nearing the end, and was struck by a few sentences in the penultimate chapter which are worth quoting in full:
Modern high-level programming languages are rich and powerful. They allow defining and using elaborate abstractions like functions and objects, expressing algorithms using elegant statements, and building data structures of unlimited complexity. In contrast, the hardware platforms on which the programs ultimately run are spartan and minimal.
At a time when Moore’s law has been running for decades, when semiconductor manufacture is an industry of global significance, and when ever more specialised chips are being produced to optimise the performance of artificial intelligence models, it’s easy to forget that, at root, all this silicon is, as Nisan and Schocken say, ‘spartan and minimal’. However we arrange them, the atomic units of computing remain ones and zeroes. (Let’s leave quantum computing to one side for a moment.)
That’s why they call it the future
What does the future look like, seen from the past?
Recently, I’ve been doing a lot of reading about the early days of the public Internet, and revisited the book ‘What Just Happened?’ by James Gleick. It’s a collection of essays about technology, written through the 90s and published in 2002. It was already a time capsule when it was published, and is even more so from the perspective of 2024. For anyone who lived through those times, it’s a mix of nostalgia (dial-up modems; Usenet; multimedia content on CD-ROM), prescience (GPS in your pocket; personalised feeds; digitisation of money) and emerging questions of behaviour and social impact (privacy; etiquette; trust).
The themes I found most interesting, though, were optimism and frustration.
Try visiting a different layer of abstraction
I had a brush with assembly language over the Christmas break.
I’ve always counted myself fortunate that I started programming in the microcomputer era, when BASIC was the most common entry point for hobbyists, and that I got my first programming job when assembler programming was becoming rare, and languages such as COBOL were the norm.
BASIC and COBOL are regarded as old-fashioned now, but their core programming paradigm - a simplified, English-like syntax used to construct logic and manipulate variables - endures. However, I’ve always been aware of the assembly programming paradigm that involves loading, incrementing and comparing registers, and that it’s a lot closer to what is actually happening at a hardware level. I’ve also been aware that many large enterprises still depend on code written in assembly language, and have been grateful that I’ve never had to attempt to learn, read or debug it.
Are we there yet? When can we stop mapping our technology architecture?
In his short story On Exactitude in Science, Jorge Luis Borges writes about a historical Empire so taken with cartography that it makes a map of itself at a 1:1 scale: so big that it covers the territory it describes. Such a map is, of course, useless, and it is allowed to decay into tattered ruins.
This story raises a common question faced by technology architects: when does it make sense to stop mapping?
I believe that the discipline of technology architecture first arose from the desire for a map. Back in the 20th century, when we had been building software for long enough that things were starting to get complicated, but not so long that they were impossible to understand, people realised that it might be a good idea if we had some sort of systematic explanation of how things worked. So, we started modelling and mapping, and building repositories, and producing diagrams, and creating methods, and inventing governance structures, and all the other things that we do to keep us busy.
One book a week: simple goals signal purpose
A few weeks ago, I was intrigued to receive an email at work headed ‘One-Book-A-Week is back! Sign up now!’. It came to me (and everyone else at Google who subscribes to a mailing list of productivity tips) from a colleague who was inviting us to pledge to try to read at least one book a week from April to June. We could do it as a team or we could do it individually. There were no prizes for succeeding or penalties for failing - but there was a page to log our books read, a regular email to encourage us and to tell us how we were doing as a group, and a bingo card of different types of books (a novel, a business book, a book by an author we hadn’t read before, a book we had been meaning to read) which we could optionally aim to complete.
I like reading, so I signed up, and pledged to read 13 books during the challenge. Four weeks in I have learnt a few things.