Today I thought I’d write about coding. Not in a technical manual, how to do your first “Hello World” widget kind of way, but just to give a general sense of how it’s done, and how things have changed over the years. This was prompted by the passages I have been writing for Timing recently, in which Mitnash and Slate have been crafting a fix for a particularly unpleasant hacking threat. The plot is all wrapped up in blackmail and personal relationships, but their ability to code is what gets them sent here and there. But first, let’s look back in time.

Not so many years ago, computers were relatively simple things to work with. They didn’t look it – all the complexity was visible by way of valves and a spider’s web of cables connecting them. But the range of things you could tell them to do was quite limited. The available options were limited, and they were essentially isolated from each other. Today’s computers are almost the opposite – they look simple on the outside, but they have a hugely expanded range of capabilities, sensory inputs, and ways to communicate with nearby devices.

The art of the coder has changed along with that. Once upon a time the programmer had to do everything. If you wanted to draw a blob on a screen you had to know exactly which bit of memory to poke with which binary digit. You needed to master a whole range of disparate skills in order to accomplish quite modest tasks, and oftentimes you needed to deal with the innards of the machine’s firmware. Porting the results to a different machine was a serious challenge.

Times have changed. If you need graphics animation, or remote communication, or artificial intelligence, there’s a library for that nowadays. Today’s coder relies on standard modules and frameworks, pulling in this one and that as the need arises. Moreover, he or she is insulated from the nuts and bolts of the device, so can write essentially the same program to run on a high-end server, a regular desktop or laptop, and any one of hundreds of different mobile devices. That is enormously liberating, but brings in a whole raft of new problems.

Does the borrowed code actually do what you want, neither less nor more? Do you trust the library writer with the innards of your system and, what is usually more precious, the data it contains? Does it already come with adequate security against hacking, or do you need something extra? On one level, the coder is freer than ever to be creative with a wealth of open source material, but to offset that, there’s a long and rather dull checklist to work through.

Some while ago I made the transition from pure development to testing and QA: it’s a decision I have had no cause to regret! I still get to write code, but it’s behind the scenes code to validate, or sometimes to challenge the work of others. QA has changed over the years alongside development. Once upon a time there was an adversarial relationship, where the two teams were essentially pitted one against the other by commercial structures, with almost no rapport or dialogue. That has largely gone, and the normal situation now is that developers and testers work together from the outset – a collaborative effort rather than competitive. There’s a lot of interest in strategies where you write the tests first, and then code in such a way as to ensure they pass, rather than test teams playing catch-up at the end of a project.

Coding and hacking are central to the plot of Far from the Spaceports, and its successor Timing. Hacking, then and now, isn’t necessarily bad. It all depends on the motive and intentions of the hacker, and the same techniques can be used for quite opposite purposes. Some of the time Mitnash and Slate are hacking; some of the time they are defending against other people’s hacks.

I have taken the line that the (future hypothetical) work of the ECRB, to – protect financial institutions against fraud and theft, would need a freelance coder more than a policeman. Moving from place to place around the solar system’s settlements takes weeks or months, and even message signals can take hours. It seems to me that it would be much more efficient for ECRB to send someone who could actually identify and fix a problem, rather than someone who might just chase after a perpetrator.

On one level, Mitnash has it easy. He can pass all the necessary but time-consuming work of testing, validating, and productionising his code to somebody else. If I ever worked with him, I’d get frustrated by his cavalier attitude to the basic constraints of working in a team, and his casual approach to QA. But then, he gets to travel out to Mars and beyond, and has Slate as his team partner.