From Philology to Python: How I Fell Into Coding (and Why My Code Still Makes Me Wince)
A researcher, an accidental programmer, and a journey from PHP and Perl to Python, NLP, and AI.
Meet Boris Orekhov
Not every developer starts with a computer science degree or sets out to build a career in software engineering.
Boris Orekhov took a very different route.
Boris is a researcher working at the intersection of literature, language, and computation. His work spans digital humanities, quantitative literary studies, corpus linguistics, natural language processing, stylometry, and AI.
But programming wasn't originally the destination.
It was a tool he needed to solve problems in his research.
His programming journey began in 2007, when a philology graduate decided to build a tool for comparing translations of the same source text.
What followed was anything but a conventional programming education: a partially translated PHP textbook, testing code directly on a live web server, a detour through Perl, a gradual conversion to Python, and plenty of skipped chapters on things like OOP and debugging.
Over time, however, programming became much more than a way to build one research tool.
It became an essential part of how Boris approaches research — from text processing and NLP to computational literary studies and today's experiments with AI.
In this Developer Story, Boris shares how he accidentally fell into coding, why Python eventually won him over, and what happens when you learn programming because you have a problem that needs solving.
Boris's Story
I'm a researcher by trade, a scientist by temperament — not a bona fide software engineer.
But needs must when the devil drives, and my academic projects demanded that I learn to code.
Not because I wanted to, but because no one else was going to do it for me.
Let's be clear: my code has never been anything to write home about.
I've always tried to do the right thing, but most of my scripts were glorified one-off hacks — duct-taped together for a single run, with all the architectural rigour of a house of cards.
I never had the discipline to polish them up to production standards, let alone follow best practices.
Meanwhile, some of my students — bless their pedantic hearts — would write OOP-compliant code even for throwaway tasks.
Me?
I was often flying without functions.
Though I did grow fond of them over time, not just because they're "correct," but because there's a certain craftsman's joy in factoring out a clean abstraction.
There's even a joke licence called CRAPL — An Academic-Strength Open Source Licence.
I take solace in it.
It's a gentle reminder that I'm not the only one sailing this leaky boat.
It Started With a Translation Problem
It all started with a seemingly niche itch: comparing translations of the same source text.
These versions are like fraternal twins — visibly similar, yet tantalisingly different.
Pinning down those differences turned out to be unexpectedly addictive.
I wanted an electronic tool to do the heavy lifting, but nobody was keen to build it for me.
So, in a fit of hubris — or desperation — I decided to roll up my sleeves and teach myself to code.
It was 2007.
I was 24, fresh off a philology degree from a provincial university, and about as technical as a teapot.
A card-carrying humanities guy through and through.
And I wanted to build a web service.
Naturally, I chose PHP.
Learning PHP the Hard Way
At the time, I didn't even know enough to spin up Apache locally.
I just wrote code and tested it directly on the web, like a toddler learning to walk on a tightrope.
There was another problem.
My English was ropey at best.
This was before the MOOC era, and translated resources were thin on the ground. I found a PHP textbook that had been partially translated into Russian.
It covered variables, assignment, basic control structures, loops, and the other essentials.
But the chapters on code organisation, debugging, and OOP were still missing.
And I couldn't wait for the full translation.
So I plunged in, armed with only the bare essentials.
That early diet of half-baked knowledge meant I got very comfortable with if-then-else and while.
But I consistently underestimated:
- OOP
- classes
- tests
- debugging
- and the sheer sanity-saving power of a proper debugger
Instead of using a debugger, I would sprinkle echo statements through my code like breadcrumbs through a forest.
It worked.
Sort of.
The PHP Service That Refused to Die
That service I built back then?
It's still alive and kicking.
It isn't written in PHP anymore, but the project itself survived.
Sometime in the last decade, I rewrote it in Python 2, and it's been running on that ever since:
https://nevmenandr.net/slovo/
Why Python 2, you ask?
Because my hosting provider at the time ran scripts via cgi-bin, and Python 2 was the only game in town.
I have no idea whether they've joined the 21st century with Python 3, so I've left well enough alone.
If it ain't broke — even if it's a bit creaky — don't fix it.
My Database Was Probably Overkill
Initially, the texts lived in MySQL, because every tutorial hammered home the PHP–MySQL duumvirate.
In reality, I had only the foggiest notion of templating.
My PHP was positively Neanderthal.
I'd just echo raw HTML right inside the script, shuttling in and out of ?> and <?php tags like a yo-yo.
It felt transparent and fast to develop.
Of course, the chapter on templates hadn't been translated yet, so I didn't know any better.
Here's the kicker: today, I consider MySQL complete overkill for my use case.
I had a few dozen records then.
Now I have a few hundred.
These days, I store everything in JSON.
Lightweight, transparent, no fuss.
Templates, on the other hand, which I once dismissed as convoluted and unnecessary, I now regard as a godsend.
I burned hours wrestling with RDBMS administration that would have been far better spent learning templating engines.
But the textbook didn't cover them.
And the documentation?
Let's just say I had to read it straight, with all the gory detail and no hand-holding.
Then I Discovered Perl
I'd tasted the power of programming, but web services alone didn't cut it.
My day job demanded serious text wrangling — natural language processing, to be precise.
And PHP was about as useful for that as a chocolate teapot.
Around that time, Perl was still riding high as the go-to language for text munging.
It had a certain je ne sais quoi — a reputation for being the duct tape of the internet, and a decent ecosystem of battle-tested libraries to boot.
So I found myself a Russian translation of a Perl tutorial.
It was one of those "Learn X in 24 Hours" affairs.
Yes, I know.
But beggars can't be choosers.
I picked up the basics well enough, but when I hit the chapters on OOP and debugging, I gave them the old heave-ho.
Why bother?
I'd already written working code without all that faff.
And since most of my scripts were strictly disposable — write once, run once, into the bin — I didn't even bother with use strict;.
That felt like pedantry for pedantry's sake.
I had better things to do.
Perl Was Perfect for My Lack of Discipline
Perl became my second language somewhere around the late 2000s.
It's a wonderfully flexible language — the kind that appeals to folks who've grown tired of discipline.
Except I hadn't grown tired of it.
I'd never really been disciplined in the first place.
I was flying by the seat of my pants, and Perl was perfectly happy to let me.
For a while, it was a pretty good match.
Then the early 2010s arrived.
And so did Python.
Python Won Me Over
The rise of Python was hard to ignore.
NLP libraries started popping up like mushrooms after rain, and it became increasingly clear that this was where the action was.
I had to learn it.
And frankly, after Perl, Python felt like a breath of fresh air.
It was almost too easy.
I started teaching it not long after.
By 2013, Perl had fallen out of favour in my world.
The writing was on the wall.
Over the past 13 years, I've written maybe five Perl scripts total.
In the late 2000s, I'd been churning them out left and right.
Now, I'd struggle to string together three lines without an LLM holding my hand.
And here's the kicker: I don't remember natural languages that badly.
I've forgotten more Perl than I care to admit, and I don't lose sleep over it.
Unicode Helped Python Win
One of the biggest reasons Python won me over was Unicode handling.
Even Python 2 with its clunky codecs module was more predictable than Perl's voodoo.
With Perl, I'd often have to play whack-a-mole with encoding declarations just to get Cyrillic text to behave.
Python, by contrast, Just Worked™.
And when Python 3 rolled around, that particular headache vanished into thin air.
Since then, Python has grown by leaps and bounds.
I count myself lucky that the stars aligned.
So many NLP and machine learning libraries landed on Python that it became the de facto standard.
These days, I dabble less with the web, but when I do, Flask is my go-to.
And it was through Flask that I finally grokked templating — the very thing I'd dismissed as overkill back in my PHP days.
Funny how life comes full circle.
From Coding for Research to Researching With Code
Over time, programming stopped being something I was merely doing because a particular project required it.
It became part of how I approached research.
My work moved deeper into areas such as natural language processing, corpus linguistics, stylometry, and computational approaches to literature.
Instead of simply reading texts, I could ask computational questions about them.
Instead of manually comparing examples, I could process much larger collections of text.
Instead of treating code as something separate from research, code became one of the instruments of research itself.
That shift was probably more important than learning any individual programming language.
The language changed.
The tools changed.
The research questions changed.
But the basic motivation remained the same:
There is a question I want to answer, and code can help me answer it.
And Then Came AI
These days, my interests have expanded further into AI.
I work with modern NLP tooling and explore questions around language models, literary research, stylometry, and AI-generated poetry.
I've also become interested in areas such as LLM interpretability, multimodal AI, and agentic workflows for research.
In some ways, this feels like another chapter of the same story.
Back in 2007, I was learning programming because I needed a tool for comparing translations.
Today, I'm exploring how machines can help us understand language, literature, and creative work in entirely new ways.
The technology has changed dramatically.
The underlying curiosity hasn't.
What Coding Looks Like for Me Today
Now?
I love Python more than Perl, and certainly more than PHP.
Even in this age of LLMs and vibe-coding, I can still knock out a small Python script from scratch for a one-off task.
No crutches.
No hand-holding.
That's more than I can say for Bash one-liners, which remain a dark art I've never quite mastered.
And perhaps that's one of the interesting things about my journey.
I never became a traditional software engineer.
I became someone who uses programming to solve problems that matter to my actual work.
The Accidental Coder
So here I am:
A philologist by training.
A researcher by profession.
And a coder by necessity.
My journey has been anything but orthodox.
It's been a patchwork of:
- half-learned languages
- skipped chapters
- questionable architectural decisions
- old scripts that somehow refuse to die
- research problems that demanded better tools
- and a stubborn refusal to follow all the rules
But it got me where I am today.
And honestly?
I wouldn't have it any other way.
What My Journey Taught Me
Looking back, I think there's something useful in having learned programming backwards.
I didn't start by learning algorithms, design patterns, testing methodologies, or software architecture.
I started with a problem.
Then I learned just enough to solve it.
Then I encountered another problem.
So I learned something else.
Sometimes that produced ugly code.
Sometimes I made decisions that I would never make today.
Sometimes I skipped chapters because I didn't understand why they mattered.
But eventually, those experiences became lessons.
And perhaps that's the thing I would tell someone who is learning to code outside the traditional path:
You don't necessarily need to start as a programmer to become good at programming.
Sometimes you start as a researcher, a scientist, a linguist, a designer, or simply someone who has a problem nobody else wants to solve.
You write the first ugly script.
Then another.
Then you discover functions.
Then debugging.
Then testing.
Then better architecture.
And somewhere along the way, you realise that you've become a programmer.
Even if you still wince when you look at your old code.
About Boris Orekhov
Boris Orekhov is a researcher working at the intersection of literature, language, and computation.
His work includes digital humanities, quantitative literary studies, corpus linguistics, natural language processing, stylometry, and AI-related research.
His programming journey began in 2007 with a practical research problem and eventually led him from PHP and Perl to Python and modern NLP and AI tooling.
You can explore his work and projects at:
https://nevmenandr.github.io
A Final Thought
There is a common idea that you need to become a programmer before you can use programming to do serious work.
My experience was almost the opposite.
I became a programmer because I needed to do serious work.
The programming came second.
The questions came first.
And perhaps that's why, despite all the ugly scripts, skipped chapters, forgotten languages, and questionable decisions along the way, I've never really regretted falling into coding.
Sometimes the best way into programming is not to learn programming first.
Sometimes it's to find a problem you care enough about to solve.
This Developer Story is part of CoderLegion's Developer Stories series, where we share the real journeys, experiences, challenges, and lessons of developers and people who use programming in their work.
