Software Engineer + Product Builder

Engineering judgment with product instincts.

I build software to meet user needs.

Focus

Full-stack systems

Background

Engineering + product

Style

Calm, rigorous, practical

Who am I?

I like building things that add positive value to the world. My background in behavioral science and product management helps me ask time saving questions before writing code, and my engineering knowledge keeps the timelines and final output valuable.

Tools I Use

I equally engjoy identifying the core user needs on product and writing the code that addresses those needs for the users.

Edge cases are the most common failure point in code, and the only way to proactively address them is by knowing the use cases fully.

Front End

JavaScriptJavaScript
TypeScriptTypeScript
ReactReact
Material UIMaterial UI
BootstrapBootstrap
CSSCSS
HTMLHTML

Back End

Node.jsNode.js
AWSAWS
MongoDBMongoDB
PostgreSQLPostgreSQL
ExpressExpress
DockerDocker
JestJest

Product

Agile MethodologyAgile Methodology
Roadmap PlanningRoadmap Planning
User AnalyticsUser Analytics
WireframingWireframing
Behavioral ScienceBehavioral Science
User TestingUser Testing
Risk MitigationRisk Mitigation

Selected Work

A few projects that show how I approach product and engineering together.

They are different in scope, but each one had good lessons for me.

Personal Site
Next.jsTypeScriptTailwind CSS

Personal Site

A Next.js and Tailwind site for portfolio work and writing, built to keep content easy to maintain.

E-Commerce Backend
Node.jsPostgreSQLExpress

E-Commerce Backend

A commerce backend built around response-time constraints, API shape, and an inherited frontend.

nVision Nutrition
ReactNext.jsBootstrap

nVision Nutrition

A mobile-first nutrition product built with a client team, balancing playful interaction with practical tracking.

How I Work

I like hard work when the outcome is worth the effort.

Good work feels a little like a long day of weeding. The middle can be frustrating, but the result should make the effort feel obvious in retrospect.

01

Learn the Shape of the Project

I like to understand the people, the work, and the real goal before changing the system. If users are part of the project, they belong in that first pass too.

  • Talk with the people closest to the work
  • Clarify what needs to be built before touching the code
  • Make a plan that can ship in useful, sequential releases

02

Protect the Good Idea

Small problems should not kill interesting ideas. The useful conversation is usually how to make the strong concept real while still respecting the hard parts.

  • Bring energy to changes that could matter
  • Treat objections as design constraints, not automatic vetoes
  • Keep brainstorming until the idea is either better or honestly impossible

03

Be Honest About Tradeoffs

Every shortcut has a cost. Sometimes it is worth paying, but I want the team to understand what the choice will mean later.

  • Count the future cost before accepting a special path
  • Prefer autonomy when a team needs to make consequential changes
  • Aim for work people want to use, even when the middle is difficult

Writing

Notes on engineering systems, product thinking, and the tradeoffs in between.

These are short notes from my work: the decisions, patterns, and small failures that I've come across worth remembering.

Aysnchronous Pancake Delivery in Javascript
Engineering Notes5 min read

Aysnchronous Pancake Delivery in Javascript

Analogy: The Javascript engine as understood from a server and consumer of pancakes. A beginners primer on asynchronous behavior wihthin Javascript