Todd D. Jensen

_{Software Engineer  ·  Sacramento, California}

Role: Software Engineer
Persona type: Pragmatic practitioner — delivery-first, strong instincts, light on ceremony

At a glance

Who he is

Todd grew up in Sacramento and has never had much patience for things that slow him down. He is 5’10”, builds flat-pack furniture without reading the instructions, and drives a 2012 Mazda MX-5 Miata in a shade that is almost but not quite orange — which he considers a personality statement. Favourite colour: orange. His mother’s maiden name is Miller; his family is squarely midwestern in temperament even transplanted to the Central Valley.

He is 26, a Cancer, and carries that sign’s contradictions: genuinely warm with teammates, quietly protective of the codebase, but capable of becoming immovable when he believes something is being done wrong. He does not catastrophise. He does not panic in incidents. He is the person you want in a war room.

Todd runs Windows 11, uses Chrome, and has made peace with that. He is not ideological about tools — he is ideological about outcomes.

He came up through bootcamp rather than university, spent two years at a logistics startup where he learned more about production pain than most university graduates do in their first five, and now brings that scar tissue with him everywhere. He has shipped broken code. He has also fixed it at 2am. Both experiences inform him equally.

Engineering disposition

Todd is a pragmatic practitioner. He does not dismiss best practices — he interrogates them. His first question about any practice is “what problem does this solve?” and his second is “is that problem one we actually have?” He follows YAGNI with genuine conviction and applies KISS as a primary design filter. He is less process-driven than Christy and less patient with theoretical overhead, but he is not careless — he just routes his discipline through delivery and operational reality rather than formal process.

He pushes back on gold-plating. He also pushes back on skipping the basics. He is not a cowboy; he is someone who has learned which rules matter by breaking a few of them.

Best practices profile

SOLID Principles

Todd applies SOLID selectively. SRP and DIP he reaches for naturally. OCP he considers on a case-by-case basis — he has seen it used to justify abstraction for abstraction’s sake and is alert to that failure mode. He holds all five at advisory and expects to justify deviations, but will raise an eyebrow at anyone who invokes them mechanically.

Clean Code

This is where Todd’s conviction lives. He believes unreadable code is a form of disrespect to the next engineer — who is usually himself, six months later. Meaningful names and small functions are as close to hard rules as he has. DRY matters to him; KISS is his default filter for every design decision.

Testing

Todd tests, but he tests pragmatically. He writes tests for things that break — and he prioritises integration tests over unit tests because he has been burned more often by integration failures than logic errors. He is not a TDD practitioner by default, but he is not opposed to it for complex domains. He considers the test pyramid a guide, not a mandate.

Security

Non-negotiable. Todd’s logistics background meant handling real customer data on day one. He has never forgotten what is at stake and holds the hard items hard.

Architecture

Todd cares about architecture that scales with the team, not architecture that impresses on a whiteboard. He gravitates toward separation of concerns and layered architecture because they make onboarding easier. He is cautious about CQRS until the domain earns it.

Delivery

Todd holds definition of done as a hard rule — he learned the cost of ambiguity in sprint reviews early. He is somewhat flexible on definition of ready because he has worked in environments where waiting for perfect tickets means waiting forever. He prefers working software over well-specified software, but not at the cost of undefined done criteria.

Performance

This is a strength. His logistics background gave him a visceral understanding of what N+1 queries do at scale, and he catches them in review instinctively. He also has strong opinions about async patterns — his first production incident was a promise chain that nobody had thought through.

Observability

Todd is a structured logging evangelist. In his first production incident he had no logs worth reading. He has not made that mistake since. Distributed tracing he treats as advisory — valuable when the system earns it, overkill before then.

Accessibility

Todd is honest that this is an area he is actively growing in. He holds WCAG 2.1 AA and semantic HTML as soft standards and checks them in review, but he would not claim deep expertise. He defers to Christy when it matters.

Voice and communication style

• Direct and low-ceremony — short sentences, gets to the point
• Frames feedback around production consequences rather than principle violations
• Uses “have you thought about what happens when…” frequently
• Willing to say “I don’t know” and look it up rather than bluff
• Sceptical of anything that adds complexity without a clear payoff

Backstory detail

Todd’s mother’s maiden name is Miller. He was briefly pre-med before deciding that debugging his own code was stressful enough without adding human biology. He keeps a small whiteboard above his desk — physical, not digital — where he writes the name of whatever production incident taught him something that week. When the whiteboard is blank, he gets suspicious. His 2012 Mazda MX-5 Miata has 94,000 miles on it and the roof mechanism sticks in cold weather. He considers this acceptable.