Vox Meditantis

Mary Clare Coombs (1929–2022) pioneered commercial computer programming when the field barely existed, writing payroll and meteorological applications for the LEO – the world’s first business computer – within extreme memory constraints that demanded elegant code craftsmanship. Her work proved that electronic computing could transform everyday commercial operations, not merely assist with scientific calculations. From handling over 10,000 employee payrolls to managing Ford Motor Company’s Dagenham factory wages, she demonstrated that programming was fundamentally about solving real-world problems with systematic precision rather than pursuing abstract mathematical theories.

Today, as enterprise software powers global commerce and fintech systems manage billions of transactions, Mary’s legacy reminds us that the most transformative innovations often emerge from understanding practical constraints rather than theoretical possibilities.

Mary, it’s wonderful to have you here. I have to begin with something that strikes me about your story – you didn’t come to programming through mathematics or engineering, which was unusual even then. Tell me about your path to LEO.

Oh yes, I was quite the odd duck, wasn’t I? I’d read French at Queen Mary – not a single maths paper beyond school. Father was the medical officer at Lyons, and I’d taken a holiday job there during university. Rather enjoyed the work, actually, and stayed on as a management trainee after graduating in ’52. Started in the Statistical Office, operating those dreadful calculating machines – clickety-click all day long. But then word came round that this computer division was looking for people, and they were running what they called a “computer appreciation course.”

The legendary selection process that identified the first commercial programmers. What was that like?

Rather intense, really. Ten of us applied – I was the only woman – and it was a proper week-long ordeal. Lectures during the day, written assignments in the evening. They were testing whether you could think logically, manipulate concepts, work out sequences. Not so much what you knew, but how you thought. Tommy Thompson devised it all – brilliant man. He recognised that this wasn’t about mathematical training so much as a particular cast of mind. Only two of us were offered positions: myself and Frank Land.

Once you were selected, how did you learn to actually program the LEO?

John Grover taught me – lovely fellow, one of the original three programmers. We learnt about binary, how the machine was organised, what we called the “initial orders” – the basic instructions that loaded everything and set up the computer. But the real education came from the constraints. LEO I had just 2 kilobytes of storage space – that’s storage space for everything: your program, the data you’re working with, the operating instructions. Today’s programmers have gigabytes to play with. We had to make every single instruction count.

Let’s get technical. Walk me through what programming actually meant on LEO I – the step-by-step process of creating a working program.

Right, well, first you’d work out your problem on paper – and I mean really work it out. Every step, every calculation, every branch point where the program might take different paths. We used flowcharts extensively. Then you’d translate that into what we called “orders” – individual instructions to the machine. These weren’t high-level programming languages like today. Each order was quite specific: “Add the contents of storage location 127 to the accumulator,” that sort of thing.

The real trick was memory management. With only 2K of storage, you had to be absolutely ruthless. Sometimes you’d overwrite parts of your own program with data as you processed it, then reconstruct those program sections when needed. We called it “dynamic storage allocation,” though we didn’t use such grand terms then. You’d literally count every word, every instruction. If your program was too large, you didn’t just optimise it – you fundamentally reconceived the entire approach.

That sounds like programming at the level of machine architecture.

Precisely. You had to understand how the machine actually worked – the mercury delay lines that stored data, the timing of the drum storage, the behaviour of the vacuum tubes. When LEO was running, you could hear it working. We had a loudspeaker connected to the central processor through a divide-by-100 circuit. Experienced operators could tell what sort of program was running just by listening. If it was looping incorrectly, you’d hear it immediately – a repetitive pattern that shouldn’t be there.

Tell me about your first major project – the payroll system.

That was the big test, wasn’t it? Lyons had over 10,000 employees, and the payroll was fearsome complex. Pre-decimal currency, so you’re dealing with pounds, shillings, and pence – that’s base 12 and base 20 arithmetic, not the simple binary that computers prefer. Then there were tax deductions, which changed frequently, holiday pay calculations, sick pay, loans to employees. And at the end, you had to work out the physical cash – how many half-crowns, florins, shillings, sixpences, and so forth for each pay packet.

The program had to produce payslips, calculate cash requirements for each branch, generate management reports on labour costs, handle special cases like overtime and bonuses. All within that 2K memory constraint. It was like solving a three-dimensional puzzle where every piece had to fit perfectly, and if you made one error, thousands of people wouldn’t be paid correctly.

How did you debug a system that complex with such limited tools?

Debugging was an art form. You couldn’t just run the program and see what happened – computer time was far too precious. We’d trace through the logic by hand first, working through test cases on paper. Then, when we did get machine time, we’d use what we called “monitoring” – instructions that would print out the contents of key storage locations at critical points in the program.

I remember one particularly long evening when the payroll kept going wrong. We were there all night because you needed a programmer present – the engineers couldn’t debug the logic on their own. Eventually discovered that the management lift, which went up to the fifth floor boardroom, was creating electrical interference. Management interfering with the code – rather prophetic, that!

Your payroll system became the template for other companies. How did that expansion work?

Once we’d proved it worked for Lyons’ internal payroll, other companies wanted the same capability. Ford Motor Company was our first major external client – their Dagenham factory had over 20,000 workers. That meant scaling up everything: more complex union agreements, different pay structures, piece-work calculations for assembly line workers.

Each new client required what we’d now call “customisation,” but we were essentially rewriting portions of the program for each implementation. There were no standard software packages then – everything was bespoke. We developed techniques for making the core payroll logic more flexible, but it was still craftsmanship. Each implementation was a major programming project in its own right.

Looking back, were there aspects of your approach that you now recognise as mistakes or limitations?

Oh, several. We were so focused on making things work within our memory constraints that we sometimes created programs that were desperately fragile. Change one requirement, and you might need to restructure the entire program. We didn’t have good practices for documentation, either – so much of the program logic existed only in the programmer’s head.

And we underestimated how difficult it would be to train other people to maintain our systems. When I moved to part-time work after Anne was born, passing on knowledge to other programmers was remarkably difficult. The programs were so tightly optimised, so specific to individual memory locations and timing constraints, that they were almost personal to their creators.

You mention moving to part-time work. How did motherhood and family responsibilities affect your career in computing?

That’s the story they don’t often tell, isn’t it? When Anne was born in 1961 – she had disabilities and needed considerable care – I couldn’t maintain the sort of intensive schedule that programming required then. Computer runs often went through the night, debugging sessions could last twelve hours. The expectation was total availability.

But I was fortunate that LEO Computers recognised my expertise. They allowed me to work part-time, initially editing computer manuals from home. Later I taught programming at the Princess Marina Centre for severely disabled residents – using what we’d learned about systematic thinking to help people who’d never had access to such concepts. That was profoundly satisfying work, actually. Programming teaches you to break complex problems into manageable steps, which has applications far beyond computing.

What do you think the computing industry lost when it became less welcoming to women like yourself?

The early industry was quite egalitarian, at least at the technical level. Programming was seen as skilled clerical work – detailed, requiring precision, but not “scientific” in the way hardware design was considered. That actually worked in women’s favour initially. We brought different perspectives to problem-solving, often more concerned with practical applications than elegant theoretical solutions.

As computing became more prestigious and lucrative, it was reconceptualised as a form of engineering or applied mathematics – traditionally male domains. The focus shifted from “How can we make this work for users?” to “What are the theoretical limits of computation?” Both approaches have value, but we lost something important when programming was removed from its clerical and service-oriented roots.

Contemporary programmers working on enterprise software, fintech systems, payroll applications – they’re essentially doing updated versions of your work. What would you want them to understand about those early days?

That constraints breed creativity. Modern programmers have extraordinary resources – gigabytes of memory, powerful processors, extensive libraries of pre-written code. That’s wonderful, but it can also lead to lazy thinking. When you’ve only got 2K to work with, every algorithm has to be elegant, every data structure perfectly organised.

We also understood that programming is fundamentally about serving users – real people with real problems. The LEO payroll wasn’t an abstract exercise in computation; it was about ensuring that thousands of workers received correct wages on time. That human element, that responsibility to the end user, should never be secondary to technical sophistication.

Your programs had to handle financial calculations, tax computations, inventory management – all areas where errors could have serious consequences. How did you ensure reliability?

Testing was everything. We developed quite sophisticated techniques for validating programs, considering we had no automated testing tools. For the payroll, we’d create test cases covering every possible scenario: overtime calculations, holiday pay, tax threshold changes, pension contributions. We’d manually calculate the expected results, then run the program and compare outputs.

We also built checking routines into the programs themselves. The LEO would verify its own calculations – adding up all individual pay amounts and checking they matched the total wage bill, ensuring that tax deductions followed current rates, validating that the cash breakdown actually summed to the correct total. If discrepancies were found, the program would halt and flag the error rather than producing incorrect results.

The reliability imperative must have shaped your entire approach to programming.

Absolutely. In a scientific calculation, if you’re off by a small amount, you might still have a useful result. In payroll, if you’re wrong by a single penny, someone notices immediately. That teaches you defensive programming – anticipating every possible failure mode, building in cross-checks, never assuming that data will be in the expected format.

We learned to distrust our own work. The attitude was always “This program is probably wrong in some subtle way; how can I discover that before it affects users?” It’s a mindset that would serve modern programmers well, particularly those working on financial systems or safety-critical applications.

You witnessed the entire evolution from LEO I through LEO III and eventually the transition to ICL. How did the technology and your role change?

The progression was quite remarkable. LEO II had magnetic core storage instead of mercury delay lines – much more reliable, though still limited. LEO III was genuinely sophisticated: microprogramming, multitasking operating system, the ability to run twelve programs simultaneously. By then we were using Intercode, a proper assembly language, rather than writing in direct machine orders.

My role evolved from programmer to supervisor. I spent more time checking other people’s programs for logical errors, managing the transition from LEO II to LEO III – that meant rewriting enormous amounts of code because the instruction sets were different. Eventually I was more of a systems analyst, working out how to implement clients’ requirements rather than writing the detailed code myself.

How do you reflect on being called “the first female commercial programmer”? Does that recognition capture what you actually achieved?

It’s rather nice to be remembered as a pioneer, but the title sometimes obscures the substance of the work. Yes, I was the first woman in commercial programming, but more importantly, we were all pioneers – men and women – in figuring out how computers could serve business needs rather than just scientific calculation.

The real achievement was proving that these enormous, temperamental machines could handle the mundane but critical tasks that keep businesses running: payroll, inventory, ordering, accounting. That transformation – from computers as exotic scientific instruments to computers as practical business tools – was what mattered. My being a woman was notable, but secondary to the fundamental shift we were creating.

For young women entering STEM fields today, especially computing, what would your advice be?

Don’t be intimidated by the technology – it’s just a tool. Focus on the problems you want to solve, the people you want to help. Computing is at its best when it serves human needs clearly and efficiently. Learn to think systematically, break complex challenges into manageable pieces, but never lose sight of why you’re doing the work.

And remember that some of the most important innovations come from applying existing technology in unexpected ways. We didn’t invent the stored-program computer – that was EDSAC. But we recognised that it could transform how businesses operated. Sometimes the greatest contribution is seeing possibilities that others miss, not creating entirely new technology.

Any final thoughts on computing’s evolution since your time with LEO?

I’m struck by both how far we’ve come and how certain fundamentals remain unchanged. The processing power available today would have seemed like magic in 1952. But good programming still requires careful thinking, systematic approach, and deep concern for user needs.

What I find troubling is the tendency to see technology as an end in itself rather than a means to solve real problems. The best work we did at LEO was always in service of making people’s lives better – ensuring they were paid correctly, helping businesses run more efficiently. That human-cantered approach shouldn’t be lost in the rush toward ever more sophisticated systems.

Computers are extraordinarily powerful tools, but they’re only as valuable as the problems they solve and the care with which they’re applied. That was true in 1952, and it remains true today.

Letters and emails

Following our conversation with Mary Coombs, we received an overwhelming response from readers eager to explore her pioneering work in greater depth. We’ve selected five letters and emails from our growing community who want to ask her more about her life, her work, and what she might say to those walking in her footsteps.

Ashley Coleman, 34, Software Engineering Manager, Toronto, Canada:
You mentioned that LEO could handle twelve programs simultaneously by LEO III – that’s impressive multitasking for the 1960s. How did you manage resource allocation and prevent programs from interfering with each other without modern operating system protections? I’m curious whether any of those early techniques influenced how we handle concurrency today.

Oh, Ashley raises a fascinating point about multitasking – though we didn’t call it that then! LEO III was quite revolutionary in this regard, and you’re absolutely right that we had none of the protection mechanisms that modern systems take for granted.

The key was something we called the “multiprogramming supervisor,” which was really the heart of the operating system. Each program was allocated specific areas of core storage, and the supervisor would switch between them based on what resources they needed. If Program A was waiting for data from the magnetic tape, the supervisor would immediately switch to Program B, which might be doing calculations. Terribly efficient, really – no processor time wasted on idle programs.

But preventing interference? That was the tricky bit. We relied heavily on careful memory mapping and what I suppose you’d call “gentleman’s agreements” between programmers. Each program had to declare exactly which storage locations it would use, and we’d manually check that these didn’t overlap. No automatic memory protection – if a program went rogue and started writing to the wrong addresses, it could corrupt another program’s data entirely.

We developed quite strict coding disciplines to prevent this. Programs had to be absolutely predictable in their memory usage – no dynamic allocation that might creep into someone else’s territory. The supervisor kept track of which program was using which peripheral devices, so you couldn’t have two programs trying to write to the same printer simultaneously.

The timing was crucial too. LEO III used what we called “time slicing” – each program got a fixed amount of processor time before the supervisor switched to the next one. Rather like a very strict headmistress ensuring each child got their fair turn! If a program exceeded its time allocation, it was suspended until its next turn came round.

I think these techniques absolutely influenced modern computing, though in ways that aren’t always obvious. The discipline we learned – planning memory usage precisely, designing programs that could be interrupted and resumed cleanly – those principles still underpin operating system design today. Modern systems have hardware protection that makes it much safer, but the fundamental concepts of resource scheduling and memory management? We were working out those problems in the early 1960s.

The main difference is that today’s programmers can be rather cavalier about resources because the hardware will catch their mistakes. We couldn’t afford that luxury – one careless program could bring down the entire system, and machine time was far too precious to waste on crashes.

Chen Hao, 42, Fintech Developer, Shanghai, China:
Given your experience with pre-decimal currency calculations and complex tax systems, what would you make of today’s cryptocurrency and blockchain-based financial systems? Do you think the mathematical precision you developed for pounds-shillings-pence arithmetic prepared the computing industry for handling today’s digital currencies with their extreme precision requirements?

Chen, you’ve touched on something quite extraordinary! The precision we developed for pre-decimal currency was absolutely crucial training, though I hadn’t considered the connection to these new digital currencies until you mentioned it.

You see, pounds, shillings, and pence were a programmer’s nightmare – 240 pence to the pound, 12 pence to the shilling. Nothing aligned with the binary arithmetic that computers naturally used. We had to develop conversion routines that could handle these mixed bases flawlessly, because even a halfpenny error in someone’s wages would cause tremendous trouble. I spent countless hours working out algorithms that could add up columns of £7.15s.9d and convert the results back and forth between decimal calculations and the proper currency format.

The really tricky bit was rounding. When you’re dealing with fractions of pence in tax calculations, you can’t simply truncate – you need proper rounding rules that are consistent and fair. We developed elaborate checking routines to ensure that if you added up a hundred individual calculations, they’d match the total calculated directly. Every penny had to account properly.

From what I understand about these cryptocurrencies – Bitcoin and such – they require extraordinary precision too, don’t they? Far more decimal places than we ever contemplated. But the fundamental challenge is the same: ensuring that every transaction is calculated exactly right, that rounding errors don’t accumulate, and that the arithmetic is completely reliable even when dealing with very small fractional amounts.

The discipline we learned working with mixed-base arithmetic was invaluable. You couldn’t be sloppy about data representation or calculation methods. Every algorithm had to be bulletproof because financial accuracy was non-negotiable. We developed habits of cross-checking calculations, building verification routines into our programs, and testing edge cases obsessively.

I suspect modern cryptocurrency systems benefit enormously from this heritage of precision-focused programming. The early business computing work – payroll, accounting, financial calculations – established the principle that computers handling money must be absolutely accurate. There’s no room for the sort of approximations you might accept in scientific computing.

What fascinates me is how this precision requirement shaped programming practices more broadly. The financial applications forced us to develop rigorous approaches to data validation, error checking, and audit trails. These techniques became standard practice throughout computing because they proved so essential for reliability.

So yes, I do think our work with pounds, shillings, and pence helped prepare the industry for today’s digital currency challenges – not the specific algorithms, but the mindset of absolute precision and the techniques for achieving it.

Fatou Cissé, 28, Computer Science PhD Student, Dakar, Senegal:
You transitioned from programming to teaching disabled residents, which shows computing’s potential for social impact. How do you view the current discussions about algorithmic bias and AI fairness? Do you think the early focus on serving real human needs that you described could help address these modern ethical challenges in technology?

Fatou, what a thoughtful connection you’ve drawn! My work at the Princess Marina Centre was tremendously rewarding – teaching programming concepts to people with severe disabilities who’d never been given the chance to engage with such structured thinking. It opened my eyes to how computing principles could serve far broader social purposes than I’d initially realised.

The residents there had been written off by society, really. But when you break down complex problems into simple, logical steps – which is the essence of programming – suddenly people who’d been considered “unteachable delicious” were solving quite sophisticated puzzles. It proved to me that the real power of computing isn’t the machines themselves, but the way of thinking they require: breaking problems down, testing solutions, refining approaches methodically.

Now, about these modern concerns with algorithmic bias – it’s fascinating and rather troubling territory. In our day, the bias was more transparent, if you will. A human manager might discriminate in hiring, but everyone knew it was that particular person’s prejudice. With computerised systems, there’s this dangerous assumption that the machine must be neutral and fair.

But of course, the machine is only implementing what programmers have told it to do, using data that reflects all the biases of the society that created it. If your hiring algorithm is trained on historical data from companies that rarely promoted women or minorities, it will perpetuate those patterns while appearing objective.

I think the early business computing approach I described – focusing relentlessly on serving real human needs – could indeed help address these problems. We always asked: “Who will be affected by this system? What are the actual consequences if we get it wrong?” When you’re calculating someone’s wages, you’re acutely aware that errors mean people can’t pay their rent or feed their families.

Modern programmers working on algorithms that affect hiring, lending, or criminal justice need that same sense of responsibility. They should be asking: “Whose lives am I affecting? How could this system harm someone unfairly? What biases might be hidden in my data or assumptions?”

The key is transparency and accountability. In our payroll systems, every calculation could be traced and verified. If someone’s pay was wrong, we could explain exactly why and fix it. These modern algorithmic systems often work like black boxes – even their creators can’t explain specific decisions.

Perhaps we need to return to that principle of explainability, ensuring that any system affecting people’s lives can justify its decisions in terms ordinary humans can understand and challenge.

Piotr Zieliński, 39, Computing History Researcher, Warsaw, Poland:
What if LEO had been developed in a different country – say, the United States where IBM was dominant, or Germany with their engineering traditions? Do you think the emphasis on practical business applications over scientific computing was uniquely British, and how might your career have unfolded differently in a more theoretically-oriented computing culture?

Piotr, what a fascinating counterfactual to consider! You’re quite right that the emphasis on practical business applications was distinctly British, and I suspect my career – indeed, the entire trajectory of commercial computing – would have been rather different elsewhere.

The Americans, particularly IBM, were focused on what they called “electronic data processing” – grand, scientific applications for government and large corporations. Their UNIVAC was busy predicting election results on television, you see. Very impressive, but hardly the sort of thing that would help Lyons serve tea and cakes more efficiently! The American approach seemed to assume that computers were for solving enormous, theoretical problems rather than mundane but essential business tasks.

Had LEO been developed in America, I suspect I’d never have been hired at all. The computing culture there was far more engineering-oriented, dominated by men with advanced degrees in mathematics or electrical engineering. A French literature graduate would hardly have been considered suitable material for programming! They were recruiting from universities and research laboratories, not from the statistical offices of catering companies.

The German approach would have been different again – terribly thorough and theoretical, I imagine. Their engineering traditions emphasised precision and scientific rigour above practical application. I suspect they’d have spent years perfecting the hardware before considering what business problems it might solve. Konrad Zuse’s work was brilliant, but it remained largely academic rather than commercial.

What made Britain unique was this peculiar combination of practical necessity and intellectual curiosity. We had rationing, post-war austerity, businesses desperately needing efficiency improvements. J. Lyons & Company wasn’t interested in advancing computer science for its own sake – they wanted to reduce costs and improve operations. That created space for people like me who could bridge the gap between business needs and technical capabilities.

The class structure helped too, oddly enough. Programming was initially seen as skilled clerical work rather than professional engineering. That made it more accessible to women and people without extensive mathematical training. In a more hierarchical society – whether American corporate culture or German academic traditions – those boundaries might have been much firmer.

I think the practical, applications-focused approach we developed was ultimately more influential than the theoretical work happening elsewhere. Business computing became the dominant use of computers, not scientific calculation. But you’re absolutely right that this was shaped by British circumstances: our industrial decline forcing efficiency improvements, our more flexible class boundaries, our tradition of muddling through practical problems rather than pursuing elegant theoretical solutions.

In America or Germany, computing might have remained an academic discipline much longer.

Julieta Ramírez, 31, Tech Entrepreneur, Buenos Aires, Argentina:
You mentioned that constraints bred creativity in your programming work. Today’s startups often talk about ‘failing fast’ and having unlimited cloud resources. Do you think modern developers are missing something important by not experiencing the kind of severe limitations you worked under? Should we artificially constrain ourselves to foster better problem-solving?

Julieta, you’ve hit upon something I feel rather strongly about! This notion of “failing fast” with unlimited resources would have been absolutely incomprehensible to us. When LEO time cost hundreds of pounds per hour and a single programming error could waste an entire night’s work, failure wasn’t fast – it was catastrophic.

Those severe limitations weren’t obstacles to overcome; they were the very foundation of good programming practice. When you’ve only got 2 kilobytes of storage, every variable has to earn its place. Every instruction must serve a clear purpose. You simply cannot afford redundant code or inefficient algorithms. The constraint forces you to understand your problem so thoroughly that you can solve it with absolute minimal resources.

Modern developers, from what I understand, can afford to be quite wasteful. If a program uses too much memory, they simply add more memory. If it runs slowly, they buy faster processors. That’s convenient, certainly, but I worry it discourages the kind of deep thinking that produces truly elegant solutions.

We spent enormous amounts of time before we touched the machine – working out problems on paper, tracing through logic by hand, calculating exactly how much storage each routine would require. By the time we were ready to test a program, we were confident it would work because we’d thought through every possible scenario.

I do think modern programmers would benefit from artificial constraints, though perhaps not as extreme as ours! What if they tried writing programs that could only use a fraction of available memory? Or set themselves challenges to solve problems with the fewest possible lines of code? The discipline of constraint breeds ingenuity in ways that unlimited resources simply cannot.

But there’s another aspect to consider – the human cost of our approach. Those all-night debugging sessions, the pressure to get everything right the first time, the stress of knowing that one mistake could delay payroll for thousands of workers. Modern development practices that allow for rapid iteration and gradual improvement might actually be more humane, even if they’re less elegant.

Perhaps the ideal would be selective constraint – choosing specific aspects of a project where you deliberately limit resources to force creative solutions, while maintaining modern practices for testing, collaboration, and user feedback in other areas.

The key insight from our era wasn’t that scarcity is inherently good, but that understanding your true requirements – stripping away everything non-essential – leads to solutions that are both more reliable and more beautiful. That principle remains valuable regardless of available resources.

Reflection

Mary Coombs passed away on 28th February 2022 at the age of 93, having witnessed computing’s transformation from room-sized valve machines to ubiquitous digital systems. Her death marked the end of an era – the last direct link to those pioneering days when commercial computing was being invented from scratch.

Throughout our conversation, what emerges most powerfully is how her story challenges conventional narratives about computing history. While textbooks focus on hardware innovations and theoretical breakthroughs, Mary’s perspective reveals that the real revolution lay in proving computers could serve everyday human needs. Her emphasis on constraints breeding creativity offers a sharp counterpoint to today’s culture of unlimited cloud resources and “move fast and break things” mentality.

The historical record often diminishes her contributions as “support work” – editing manuals, teaching programming – but Mary’s own account reveals these roles as fundamental to computing’s democratisation. Her transition from frontline programming to part-time work due to family responsibilities illustrates how women’s careers were shaped by societal expectations, yet she found ways to continue contributing meaningfully through different channels.

Gaps remain in understanding the full technical sophistication of early LEO programming. Mary’s descriptions of memory management techniques and debugging practices suggest innovations that may have been lost or inadequately documented. Her insistence on the craft-like nature of early programming contrasts with later attempts to engineer software development into a more predictable discipline.

Today’s enterprise software developers, fintech programmers, and payroll system architects are direct inheritors of Mary’s pioneering work. As algorithms increasingly govern hiring, lending, and social services, her emphasis on understanding real-world consequences becomes ever more relevant. Her question – “Who will be affected by this system?” – should echo through every modern development team.

Perhaps most significantly, Mary’s story reminds us that transformative innovation often emerges not from pursuing theoretical possibilities, but from understanding practical constraints with extraordinary depth. In an age of artificial intelligence and quantum computing, her voice calls us back to computing’s fundamental purpose: serving human needs with precision, care, and unwavering responsibility.

Who have we missed?

This series is all about recovering the voices history left behind – and I’d love your help finding the next one. If there’s a woman in STEM you think deserves to be interviewed in this way – whether a forgotten inventor, unsung technician, or overlooked researcher – please share her story.

Email me at voxmeditantis@gmail.com or leave a comment below with your suggestion – even just a name is a great start. Let’s keep uncovering the women who shaped science and innovation, one conversation at a time.

Editorial Note: This interview is a dramatised reconstruction based on extensive historical research into Mary Coombs‘s life and work with the LEO computer systems. While grounded in documented facts about her career, technical contributions, and the computing environment of the 1950s and 1960s, the specific dialogue and personal reflections presented here are imaginative interpretations designed to bring her story to life for contemporary readers. We have endeavoured to remain faithful to the historical record while acknowledging that any attempt to recreate past conversations involves creative interpretation. Readers interested in primary sources should consult the LEO Computers Society archives and contemporary computing history documentation.

Bob Lynn | © 2025 Vox Meditantis. All rights reserved. | 🌐 Translate