About Me

Once I realized software was something I could actually learn, I went all in.

Outside of being a husband and dad, most of my free time went toward learning how to code. Nights, weekends, books, YouTube, Codecademy, side projects, and pretty much anything else I could find that would help me understand how software worked.

I built things just to see if I could. I broke things so I could figure out how to fix them.

Early on, I was also lucky enough to meet a senior developer who was willing to help me. At that point I was trying to absorb everything I could find, and he helped give me direction instead of letting me get lost in the endless amount of information available.

That experience has stayed with me. I still learn the most from people who are willing to share what they know.

When I started my professional career, I was very green.

I understood the fundamentals, but there was still an enormous amount I did not know. The thing that helped me most was being comfortable admitting that.

I asked a lot of questions. I listened. I tried things. I made mistakes and learned from them.

It was a sink or swim environment in a lot of ways, and swimming was really the only option I was interested in.

Over time, I went from trying to understand how everything worked to taking ownership of increasingly larger parts of the products I was working on.

That shift changed the way I thought about software.

I stopped seeing the job as simply building what was put in front of me and started thinking more about what should be built, why it mattered, and whether it actually solved the right problem.

That is ultimately why product engineering feels like such a natural fit for me.

The more experience I gained, the more I realized that the part of software I care about most is not the technology by itself.

I care about what we are trying to accomplish with it.

I may not always be the best pure coder in the room, but I believe I can help build the best product in the room.

A big part of that comes from listening.

I like understanding why someone is using something, where they are getting frustrated, what they are trying to accomplish, and whether the thing we are building actually makes their life easier.

My favorite part of building software is seeing someone use it.

Getting someone to pay for something you built is obviously great, but before that happens they have to care enough to use it in the first place. Once they do, the next question becomes even more interesting.

What is going to make them come back?

That is the part of product development I keep finding myself drawn toward.

Because of that, I like ownership.

I like being responsible for an outcome instead of just being responsible for completing a task.

My approach has changed quite a bit over the years. I used to think the whole product needed to be figured out before it was ready to put in front of someone.

Now I would rather get the useful version into somebody's hands, learn what is working, learn where I was wrong, and improve it from there.

That does not mean I do not care about polish. I care about it a lot.

Confusing interfaces and experiences that feel unfinished bother me because they make the entire product feel less trustworthy.

I just think there is a time to move quickly and a time to slow down and polish. The important part is understanding which one the product needs.

When I care about a problem, I tend to stay with it. I will keep learning, testing, and refining until I feel like I have given the idea the best possible chance to work.

That same mindset carries into how I work with other people.

I try to be someone people enjoy working with.

I like helping people, and I try to bring a positive attitude even when there is a lot going on.

I also believe pretty strongly in leading by example.

I would never want to ask somebody to do something I would not be willing to do myself. It does not matter how small or unglamorous the task is.

I also gravitate toward people who are highly driven and willing to share what they know.

I want to work around people who are better than me at things.

That is how I grow.

Long term, leadership is where I see myself heading, and that is the kind of leader I would want to be.

Outside of software, most of my time belongs to my family.

I am a husband and dad, and that has shaped a lot of the way I think about work, responsibility, and what success actually means to me.

When I get some free time, I am usually watching Cardinals baseball, convincing myself the Titans are going to have a good season, playing a game late at night, or finding some other project to mess with.

CarShow Coordinator even started because of a car show connected to a nonprofit my wife and her family created in memory of her dad.

I want to keep growing as a product engineer.

That means becoming a better engineer, developing better product judgment, and putting myself around people who will push me beyond what I can do today.

Long term, I want to be in a position where I can help set direction, build strong products, and make the people around me better.

Whether that eventually means leading a product team or building something of my own, I know leadership is where I want to end up.

I took an unconventional path into software, but I think that path taught me a lot about how I want to approach the rest of my career.