Answering the question: ‘How do you stay current?’

Photo credit: Fredy Jacob on Unsplash

How do you stay current?

I have to admit that, every time I am asked this question, I panic a little internally. I have an answer: there are blogs and sites I read, there are people I follow on social media, I have a long list of courses and books, and I try to do some real coding when I get the chance. But I also know that all those activities are flimsy bulwarks against the rapidly rising tide of ignorance, and that if I truly wanted to ‘stay current’ I would have time to do nothing else. In recent years and months, the press has been full of stories about new technology: ChatGPT and LLMs are the latest topics to grab the global imagination. But, for technologists, these are just the highly visible tips of a very large iceberg of trends in computing, networking, cyber security, software engineering and data science that most people don’t see. We are used to our concepts being disrupted.

Does this mean that there is no point in trying to stay current, that we should abandon all attempts to maintain a general understanding of the field, and only learn about new topics as we need to (perhaps using an AI assistant to explain things to us)? Unsurprisingly, I don’t think so: I enjoy learning, and think that the dynamism and volatility of the technology market make it fun. I do believe, however, that we should be thoughtful about what we learn, and distinguish between knowledge that will last and knowledge that will fade.

Let me illustrate with a few examples from my own journey through computing.

Although the first machine I ever programmed was the ZX81, I wrote much more code on the Acorn Atom. I spent many hours learning Acorn System BASIC, and the tricks of how to squeeze as much performance out of the tiny machine as possible. Although it is painful to admit it, much of that knowledge is genuinely useless now: I’m never going to program on the Acorn Atom again, even for the sake of nostalgia. However, some parts of what I learnt have stayed with me throughout my career: the fundamentals of logical constructs, the essential elements of programming, and, most importantly, the revelation that if you type in commands, then the computer will do what you tell it to do.

Some years later I was working as a programmer, having transferred some of my knowledge from BASIC on a microcomputer to COBOL on a mainframe (this was still a very long time ago). I was part of a big project, and we used SSADM (Structured Systems Analysis and Design Method): the sort of heavyweight, upfront design approach which is deprecated today. There are a lot of components of that method which aren’t relevant to an Agile world and which lie, dusty and rusty, at the bottom of my mental toolbox. At the same time, though, there is much of that experience that has stayed with me. SSADM was a data-centric method (at least in my memory) and I learnt some important lessons about how to think about data, and how to make good choices about data structures. To this day, if I am designing a system, I usually start with the data. More importantly, though, I learnt about the work of translating problems into concepts which can be communicated and shared across people and teams. Whether we are using a fashionable method or an unfashionable method, this work remains.

Even later (but still a long time ago) I was leading a project to migrate file servers from Novell to Windows 2000 (I said that it was a long time ago). There were lots of nitty gritty details in this project: the configuration of the servers, naming conventions for users and data, the operation of the migration tool. And, critical thought they were at the time, all of those details that me and my team painstakingly learnt are irrelevant now. We are never (I hope) going to do that particular migration again. And yet, once again, there are concepts that I learnt on that project that will stay with me: how to assess and communicate the impact on users, how to plan work to protect data and user experience, and how to design pilots which actually prove something and lift the skills of the team.

I have chosen these ancient examples deliberately to illustrate how quickly and irrevocably some knowledge decays. But I hope that they also show some knowledge has persistent and enduring value. It can be hard to tell the difference when you’re in the middle of learning, but a rough rule of thumb seems to be: syntax decays; concepts endure.

When you next face the question, 'How do you stay current?' it may be worth answering by explaining not just how you acquire new knowledge, but how you identify, retain and apply those enduring concepts that matter most.