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 the other 20%

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 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 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: BackboneJS, EmberJS, 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, built hierarchical loss functions for nuanced classification, experimented with topic modeling (multi-grain, hierarchical pachinko allocation), and written information extractors from dependency tree rules. 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. SSL certificates, partition management, security patches, Docker deployments, load balancing. Disaster recovery plans that actually get tested. Dependable infrastructure without drama.

Server-Side Web Development

Ten years building backends in Django, Adobe Experience Manager, Laravel, and more. APIs, WebSockets, database integrations—the invisible plumbing that makes front-ends feel seamless.

System Architecture

I design systems that scale without ego. Docker, orchestration, microservices, gRPC and REST APIs—components that communicate reliably and fail gracefully. Architecture shaped by experience, not trend-chasing.

Through the Looking Glass of Literature

I read a lot. Speculative fiction, mostly, alongside the technical papers and textbooks that interest me. Growing up in Tidewater, books were how I learned that other ways of organizing the world existed.

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 a system's assumptions becomes second nature. The same instinct that spots a flawed premise in a novel helps me find the unstated assumptions buried in a codebase.

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...serene even. 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.