Senior Software Engineer · AI Engineer · Data Scientist · Project Manager

Growing up, I couldn't stop taking things apart—mentally if not physically. Physics, biology, mathematics, art—I wanted to understand all of it. But somewhere along the way, I noticed a pattern: every field I explored used computing as its backbone. Data visualization, modeling, information transmission—software was the universal language. That's when I knew where I belonged.

Since earning my engineering degree in 2011, I've spent the last years turning concepts into production reality. I've built enterprise applications across fintech, edtech, and e-commerce—the kind that have to work when thousands of users show up at once. I've led engineering teams, served as CTO, and designed platforms that need to scale under real-world pressure. Leading teams taught me that great technology isn't just about writing code—it's about building systems and people who can sustain them.

My technical foundation spans full-stack development, cloud architecture, data science, and AI—both classical machine learning and the latest generative approaches. My M.Eng. in Big Data and Data Engineering crystallized something I'd learned the hard way: architecting AI for enterprise means solving constraints, not just chasing demos. Real solutions need to work in production, not just in presentations.

What draws me to AI isn't the headlines or the hype. It's the practical question: what if we could automate the tedious parts of work—the repetitive, mind-numbing tasks—so people have bandwidth to think creatively? Technology should amplify human capability, not just replace it. That's the kind of AI worth building.

My approach is simple: ship working software, communicate constantly, iterate fast, and measure what matters. I'd rather show you a working prototype than hand you a 50-page spec. Results speak louder than documentation. That's not just how I code—it's how I solve problems.

Senior Software Engineer

There's a particular satisfaction in writing code that solves a real problem—watching tests turn green, seeing a feature click into place, hearing a user say "this just works." I've moved through JavaScript, Ruby, Python, Elixir, not collecting languages like trophies, but because each one opened my eyes to a different way of thinking. Ruby on Rails taught me convention over configuration. Next.js showed me what happens when you optimize for the developer experience. Phoenix proved that fault tolerance isn't just a nice-to-have when you're building systems people depend on.

The cloud changed how I think about infrastructure entirely. I remember the first time I watched a Docker container spin up in seconds instead of fighting with server configs for hours—it felt like magic, until I understood it was just very good engineering. GraphQL replaced my REST APIs not because it was trendy, but because I got tired of over-fetching data and making three API calls when one would do. And PostgreSQL? It's been there through it all, quietly reliable, proving that sometimes the tools that last are the ones that solve fundamental problems really, really well.

AI Engineer

I fell into AI through curiosity and stayed because of the possibility. Early on, I built neural networks in TensorFlow and Keras, tweaking hyperparameters at 2 AM, watching loss curves drop, trying to understand what was happening inside those layers. It was humbling—these weren't magic boxes, they were math, and the math had to make sense before anything else would.

Then LLMs arrived and suddenly everyone was an AI expert overnight. While others chased demos, I went deeper—learning LangChain, LangGraph, LlamaIndex, figuring out how to orchestrate these powerful but unpredictable models into systems you could actually rely on. The difference between a demo and production is everything: error handling, context management, cost optimization, the thousand details that separate "wow, cool" from "I use this every day."

Now I'm focused on RAG architectures and tools like Gradio and the Model Context Protocol—building AI that augments human work rather than just replacing it. The best AI systems I've built aren't the ones with the most impressive tech stack. They're the ones that solve a real problem so well that people forget they're using AI at all.

Data Scientist

Data science feels like detective work—you've got clues scattered across spreadsheets and databases, and somewhere in there is a story that matters. I started with the fundamentals: hypothesis testing, feature engineering, building Scikit-learn models that actually predicted something useful. The first time I watched a model's accuracy climb from 60% to 85% because I engineered the right features, I understood why they call it "learning."

Supervised learning taught me to predict the future. Unsupervised learning taught me to find patterns I didn't know to look for. Time series analysis taught me that context matters—last Tuesday's sales spike might mean nothing, or everything, depending on what happened the Tuesday before. Each technique is a different lens for seeing what the data is trying to tell you.

But here's what took me longer to learn: the best model in Jupyter is worthless in production if it can't be deployed, maintained, and explained. That's why I care about MLOps and Power BI now. Because stakeholders don't want to hear about gradient boosting—they want to know if we should expand to the Southeast market. The real skill isn't building the model. It's translating the math into decisions that move the business forward.

Project Manager / Executive

I started in the era of RUP and waterfall—detailed requirement docs, sequential phases, change requests filed in triplicate. When Agile arrived, I was skeptical. It felt like chaos compared to the structured process I knew. But after my first successful sprint, watching a team deliver working software every two weeks instead of waiting six months for a big-bang release, I understood. Having lived through both worlds gives me something the Agile-native generation doesn't have: I know exactly why these ceremonies matter and what happens when you skip them. Then came the executive role—suddenly I wasn't just managing projects, I was making strategic bets that would shape the company's future. Should we build in-house or buy? Microservices or monolith? Hire senior engineers or grow juniors? Every decision had trade-offs, and the hardest lesson was this: being technically right doesn't matter if you can't bring the business along. I learned to translate between worlds—turning "we need to refactor the authentication layer" into "this prevents the security breach that keeps leadership up at night."

But here's what really defines leadership: it's not about having all the answers. It's about building teams resilient enough to find answers you never would have thought of alone. It's mentoring someone through their first production outage at 3 AM and watching them handle the next one like a seasoned pro. It's growing a team from 2 to 15 engineers and realizing your job isn't about the code you write anymore—it's about the code your team can write. That shift from doing to enabling is what separates an individual contributor from a multiplier. And honestly? Watching someone you mentored solve a problem better than you could have is more satisfying than any code I've ever written myself.