Small-town developer building tomorrow's tech

I'm Doug Fenstermacher, and I build software from a place where the internet still goes out when it storms. Growing up in rural Gloucester, Virginia, where I downloaded MS-DOS games on dial-up as a child, I learned that great technology works everywhere.

I spent high school working at a funeral home, which sounds like a non sequitur next to a career in software, but both jobs are about solving problems for people during complicated moments. The work has to be invisible, reliable, and exactly right. A decade working in research and higher education only sharpened that instinct to build things that are technically rigorous and genuinely useful to the people who need them.

Engineering for both corporate and customer budgets

The Tidewater region, like most of rural America, exists in a different technological reality than Silicon Valley assumes. Broadband and cell phone service are not ubiquitous and technical literacy varies dramatically. Rather than disrupting lives to fit technology, effective solutions meet people where they are, adapting to existing rhythms and realities.

These resource constraints require the same technical rigor I applied to distributed systems and NLP models, but demand software-defined solutions that can be remotely upgraded rather than expecting users on a budget to purchase new hardware. This discipline transforms how we think about impact. When rural students can access MIT courseware on limited connections, elderly neighbors on a fixed income consult specialists via telehealth, and local businesses reach customers beyond county lines, technology becomes a bridge rather than a barrier. Thoughtful engineering dismantles the structural disadvantages that separate resource & budget constrained communities from opportunity.

Where Research Meets Resource Reality

I've spent ten years in higher education and research. The skills below aren't exhaustive, but they are ones where I can walk into a project and deliver value immediately.

The common thread is that I think in systems. Whether I'm tinkering or working, I'm asking the same questions: What happens when this breaks? Who has to maintain it? What does this actually cost to run?

Data Persistence

I architect databases that applications can rely on. MySQL, PL/SQL, NoSQL, whatever fits the problem. I design schemas for clarity and optimize queries for speed, because performance matters most when resources are tight.

DevOps

I automate the tedious stuff so teams can focus on building. GitLab CI/CD pipelines from linting to deployment. Monitoring dashboards that surface real problems. Alerts that mean something. Less firefighting, more shipping.

Front-end Web Development

Ten years with frameworks as they’ve come and gone: Previously BackboneJS & EmberJS, and now ReactJS & AngularJS. I build interfaces that work when the connection is solid and degrade gracefully when it isn’t.

Natural Language Processing

I’ve trained and deployed PyTorch text classifiers via REST APIs trained on hierarchical loss functions, bulk evaluated corpuses with topic models, written information extractors from dependency tree rules, and used semantic embeddings for retrieval and classification. I like the puzzle of teaching machines to find meaning in messy human language.

Operations Research

Resource allocation problems are puzzles I enjoy. Linear optimization, combinatorial optimization, min-cost flow, and graph coloring are all tools for untangling constraints and finding efficient paths through complicated systems. I’ve also done sensitivity analysis and risk modeling, because real-world solutions need to handle uncertainty.

Server/Cloud Administration

I’ve managed Linux web servers across dozens of domains including SSL certificates, partition management, security patches, Docker deployments, load balancing, etc.

Server-Side Web Development

Ten years building backends in Django, Adobe Experience Manager, Laravel, and more. APIs, WebSockets, database integrations.

System Architecture

I design systems that can grow using Docker, orchestration, microservices, gRPC and REST APIs; components that communicate reliably and fail gracefully.

Compounding Interest of Reading

I read a lot. Speculative fiction, mostly, alongside the papers, essays, and textbooks that interest me. In fact, I credit reading about topics I didn't understand, or that made me uncomfortable for most of my successes. That curiosity has compounded over decades of grappling with hard questions and built fluency with pluralistic reality. Growing up somewhere small means the available answers come from a narrow set of sources and perspectives, and reading revealed there were others. Once I accepted the world isn't organized the only way it could be, there's nothing left to stop me from holding multiple truths at once.

Le Guin taught me that every system embeds values, whether it admits them or not. Butler showed me how power structures replicate themselves, even in new technologies. Gibson's reminder that the future is already here, it's just not very evenly distributed feels different when you live in the unevenly-distributed part.

This matters for engineering. When you've spent years thinking about how societies might work differently, questioning assumptions becomes second nature and so does asking how things might be made better.

The Long Run Home

I run the same routes I trained on in high school, back when I was competitive enough to run Division I in college. There's a particular clarity in covering familiar ground with a decade of distance from it. Long-distance running and system architecture are not so different as they look. Each is built slowly, in long seasons, on foundations laid before the work is seen.

The night before a race I would feel pretty calm. The race was the culmination of the workouts and the recoveries of the weeks and months before. The same was true of everyone on the line. I (like everyone else) wanted to win, but the outcome had largely been decided already, in the choices we'd made. So there was nothing left to do but run my race.

Software is similar. Whether a thing turns out simple or complicated is usually the sum of small decisions made long ago. When a feature that seems hard goes in quickly, it's rarely momentary cleverness; it's mostly because the foundation was carefully laid long before in the pieces this new feature rests on. When it fights you, you're paying down a foundation laid carelessly. So the work is never only the work in front of you. It is laying the foundation for the features that, a few months from now, should be simple.

The View from Between

I live in Tidewater by choice. Being physically removed from tech hubs gives me something immersion can't: perspective on both what technology promises and where it actually fails to deliver.

I'm interested in bridging worlds but also understanding what parts to take from each to build the world we aspire to.