On 22 September 2026, Computer Weekly turns 60. To mark the milestone, we asked some of our friends – experts, parliamentarians, IT leaders and suppliers – for their perspectives on how tech has changed their lives over six decades. What’s changed the most for you since then?
I was born in 1975. I didn’t learn engineering in a lab or an incubator. I learned it on a farm, and in front of an 8-bit computer.
Farm work teaches you one thing early – the weather doesn’t care how you feel about it. Heat, a sudden storm, a mechanical failure, whatever it was – the work still had to get done. You show up because that’s the only way anything grows.
When not baling hay on the farm, I was falling in love with my first computers – a Commodore 64 and a TRS-80. Those of you that grew up in this era of computing remember that these computers didn’t connect to a monitor, but instead to a TV. In my case, my Commodore had to share the only family TV.
Programming in BASIC meant constant negotiations. My coding windows were strictly bounded by my mom’s evening soap opera schedule – Dallas, Dynasty, and Falcon Crest are the theme songs I’ll never forget. I had to write my code then systematically unhook all the wires to reconnect the antenna before her shows started.
Vanishing work
Memory back then was entirely volatile, so if I wanted to build something, I typed it in line by line, often copied out of Byte magazine or my own handwritten notebooks. I started by coding basic logic for text-based exploration games inspired by Zork, which evolved into transcribing complex visual programs line-by-line from Byte.
“My instincts are the same ones I picked up 30 years ago – build for the failure case, not the happy path, and never forget that the most important part of the system is often the people building and running it”
Michael Facemire
If the power flickered, if a fuse blew, or if my mother wanted to watch the TV the computer was attached to, the work vanished.
Then came the cassette-tape drive. To a kid in the 1980s it felt like magic. I could finally keep what I’d built instead of losing it every night. I didn’t have the words for it then, but that was my first encounter with the idea of saving state, and it planted something that never really left me – design for a hostile environment and build things that survive the storm.
By the late 1990s I’d landed my first real job at IBM, just as the dot com boom was taking off. My contribution to that boom was enabling laptops to browse this new web using cellular networks. I was assigned to the first clamshell phone, the Motorola StarTAC.
Wireless networks were painfully primitive, grinding along at sub-10 kbps speeds with constant packet loss. Tethering that – now relic – phone opened a new horizon. Suddenly, I could walk outside or sit in a car and work, concepts taken for granted today, but pure magic then. I vividly remember the explosion of joy when I captured my first successful network trace and saw a real data response come back over the air.
In the weeds
My team built the network drivers that interfaced with the Windows 3.11 network stack. With CDMA, dropped packets weren’t the exception, they were the rule. I spent months in the weeds of TCP and UDP trying to squeeze something usable out of a signal that barely wanted to cooperate.
I was also the youngest person on that team, working alongside guys who’d spent their whole careers on mainframes. My 21-year-old ego didn’t get me anywhere with them. I had to patiently listen, ask questions I probably should have already known the answers to, and earn my place the hard way. It’s where I first realised that most technology problems were really people problems wearing a disguise.
I’m a chief technology officer (CTO) now. My days are AI token budgets, enterprise architecture, and microservices instead of cassette tapes and dropped packets. But the instincts are the same ones I picked up 30 years ago – build for the failure case, not the happy path, and never forget that the most important part of the system is often the people building and running it.
The family farm, mom’s TV schedule, and the cassette tape taught me how to secure a foundation against volatility. The StarTAC taught me how to architect for an indeterminate environment. Most important, those IBM veterans taught me how to lead.
Michael Facemire is CTO at Forrester.
S 004