When I started my PhD in 2007 I had the chance to learn the 'new language that's replacing Fortran as the code the physics department will teach – Python.' Having just been introduced to Fortran and enjoying the logic of it, I gave Python a go but it irritated me - from the inexplicable importance of indenting, to the impenetrable terminology that obscured functionality, at least to me. So I ditched it, used Fortran where I could and effectively killed any budding Python coding skills that might have flourished in time.

Looking back I think it was the language used to explain Python that scuppered me in the same way the language of the text-based adventure games on the ZX Spectrum tripped up me and my husband. In those early days of gaming the players bought cassette tapes, inserted it into what looked like a pimped-up keyboard, connected that to a basic monitor and pressed 'play'. Text appeared on the screen –often without any fancy graphics, mostly just text in a range of colours if the authors ventured that far.

​​ Image courtesy of Centre for Computing History

​ Image courtesy of Youtube

Examples of: (left) Sinclair ZX Spectrum; (right) screenshot of a generic text-based adventure game​

The adventure games were played by reading the text as it appeared on the screen, which developed into a story with a pace that depended on how good the players were at solving the 'problems' they encountered. For example, your character might be stuck behind a locked door in a room containing a stool, a bucket, a piece of paper and so on. But, what we didn't initially realise and what only became clear as the game unravelled after many frustrating hours of typing 'get bucket' > no response, 'get pail' > no response, 'get tin container!' > no response 'what the feck else would you call it?' > no response (and none expected!) was that there were VERY specific names for all objects encountered. The (somewhat sadistic) game authors often chose not to include a dictionary of actionable words leaving the player to grab the nearest thesaurus (pre-internet days). Aargh, how do we know what we don't know?? Was the action of getting the pail/bucket/tin container etc. incorrect, or was the name of the item incorrect?

Somehow, despite being in a constant state of never knowing where we were going wrong, my husband and I persevered until we became so frustrated with the games that the frustration spilled out beyond the game into many 'heated discussions', at which point we gave up and started the whole process again with a different game or watched the tv instead.

What is now resonating with me from this past experience is that whenever I attempt to learn and use Python I get the same feeling of not knowing what I don't know. Beyond the more obvious mistakes such as missing brackets, lack of indentation etc., how do I know if, when a few lines fail, the cause is incorrect syntax, or the function won't work with a particular type of object, or something else I'm not aware of ?  And why oh why do I need to spend so much time trying to work out the issue? Is that really doing science? And even if I do manage to get something running it's going to have zero compute efficiency, which probably doesn't matter for the tiny amount of code I write, but even so the principle matters to me.

Thankfully, I was introduced to my new best coding friend - Stackoverflow with over 22 million answered questions (not all of them about Python) - by a very sympathetic collaborator who told me 'there's no one right way to do something in Python' that has since become a reassuring mantra. Together, my new friend and mantra have enabled me to write some Python that actually does what I intended, but I still begin every coding session with a sense of doom. Fortunately, to compensate this when something does work the feeling is great and keeps me typing away.

I'm never going to be a research software engineer, nor a science software developer like my STFC colleagues working in their different communities in CoSeC. I'm staying in the realm of application science where I apply software to explore research questions. In fact, I'm relying on my colleagues to one day develop a 'Smart Alexa'. This would be an interactive AI with whom I could discuss a research question, explore the simulation set-up, agree on the optimal parameters, set-up the software to run at maximum energy efficiency on the most appropriate compute architecture available, and to whom I could say 'make it so!' Then I'll be able to dedicate all of my energy to exploring the data and attempting to answer the research question, not getting lost down a rabbit hole that began with 'this is a Python generator' continued as 'yes, but so what –that's not helpful' and ended with 'ah, thanks to Stackoverflow's 'PatcheyePetra' for providing an example of how to use the 'generator!'

If a Smart Alexa seems far-fetched, it's not. And there's no reason for it to be thanks to the increasing quantity of published data and hopefully an increasing willingness to publish what didn't work as much as what did, combined with databases of simulation and experimental results, plus advances in machine learning, natural language processing, and quantum computing, and initiatives such as the Physical Sciences Data Infrastructure with its aim being 'to enable researchers in the physical sciences to handle data more easily by connecting the different data infrastructures they use. PSDI will connect and enhance existing infrastructure in Physical Sciences.' 

Until then I'll need to continue plugging away grappling with 'object-orientation', 'types', 'relative imports' and so on. I can but dream of the day to come when Smart Alexa will help me achieve a scientific 'Eureka' moment! Dear science software developing colleagues – to personalise Captain Picard's famous command (please) 'Make Smart Alexa so!' 

​

​Image courtesy of Science Fiction and Fantasy Stack Exchange

Captain Picard of 'Star Trek: The ​Next Generation' issuing his signature command from the captain's chair of the USS Enterprise​​

​​

​​