Joseph Conradt

Software engineer

15 years of software engineering experience.

Experience across real projects, real constraints, and the day-to-day work of building software.

Selected work, writing, and more on how I approach software engineering.

About

Built to give context, not perform personal branding.

The goal of this site is simple: make it easier to understand the person behind the resume. It should feel specific, useful, and clearly authored.

I am most useful when the work is important, a little messy, and not yet fully shaped. That usually means some combination of engineering judgment, product sense, and the patience to reduce ambiguity before trying to scale a solution.

I like software that earns trust by being clear, resilient, and considerate of the people using it. I am less interested in performance theater and more interested in systems that hold up when real work starts flowing through them.

Why this format

  • A resume shows chronology. A site can show judgment, taste, and working style.
  • It creates room for projects, writing, and context that would feel cramped on a single page.
  • It also leaves room to grow into a publishing surface instead of staying a static artifact.

How I Work

A few instincts that shape the work.

These are the tendencies I come back to across engineering, systems design, and operational cleanup.

Principle

Clarity over theatrics

I like work that gets sharper as it gets simpler. The best systems make complex things feel understandable without pretending the complexity is not there.

Principle

Useful beats impressive

I care more about whether a thing solves the right problem than whether it sounds exciting in a status update. Reliability, maintainability, and clarity matter.

Principle

Calm under ambiguity

Messy work is usually not blocked by effort. It is blocked by confusion. I do well when the job is to reduce noise, define the shape of the problem, and move things forward.

Stack

A working set of technologies, not a random logo wall.

A sample of the tools and platforms I have used across frontend, backend, data, and delivery work.

21 items

Frontend

Interfaces, state, and browser work

TypeScript

TypeScript

JavaScript

JavaScript

React

React

Angular

Angular

Redux

Redux

Material UI

Material UI

Storybook

Storybook

GraphQL

GraphQL

Tool

REST APIs

Backend

Services, APIs, and systems work

Node.js

Node.js

PHP

PHP

Postgres

Postgres

Python

Python

Data

Pipelines, analytics, and platform tools

Databricks

Databricks

SQL

SQL

Moodle

Moodle

Tool

CI/CD

Tool

Testing

Selected Work

The work should feel grounded, not inflated.

These entries are intentionally written more like working notes than polished marketing copy. The important thing is what problem the project helps solve.

Resume tailoring workflow

In progress

A system for generating tailored resumes and supporting materials without losing the signal that makes them human and specific.

Why it matters

Brings structure to repetitive job-search work while keeping the output thoughtful.

  • Automation
  • Content systems
  • Quality control

Reusable personal-site foundation

Current build

A shared website system that can support both a personal site and a future company site through themes, shared components, and site-specific content.

Why it matters

Lets one clean foundation support multiple identities without looking templated.

  • Astro
  • React
  • Tailwind
  • Design tokens

Operational cleanup

Representative work

The kind of work I enjoy most: taking brittle, high-friction workflows and turning them into clear, dependable systems teams can trust.

Why it matters

Reduces decision fatigue, handoff errors, and invisible maintenance costs.

  • Process design
  • Systems thinking
  • Execution

Writing

A place for notes, patterns, and sharper thinking.

Writing here should support the same goal as the rest of the site: to make the work and the way of thinking behind it easier to understand.

Draft topic

What good internal tools actually optimize for

A note on usefulness, trust, and why polished interfaces do not matter if the workflow underneath is brittle.

Draft topic

The difference between motion and progress

Thoughts on how teams get stuck performing productivity instead of reducing actual uncertainty.

Draft topic

Why compact interfaces often feel more confident

A short piece about density, pacing, and making room for substance without making the page feel cramped.

Contact

Useful conversations welcome.

If you are hiring for product-minded engineering, systems work, or thoughtful execution in ambiguous environments, this is the kind of work I want to do more of.

The current content is intentionally lightweight so the structure can harden first. From here we can replace the placeholder details with your real bio, project narratives, writing, and links.

hello@example.com