datamays logo datamays david mays

datamays.com — A Personal Platform for Clear Thinking and Durable Systems

· 5 min read

Overview

datamays.com is my personal professional website, designed as both a portfolio and a long-term thinking surface. Rather than functioning as a static résumé or a marketing funnel, the site is intentionally structured to communicate how I think, how I build, and what I value as a data engineer.

The project serves three core purposes:

  1. Present my work and writing in a coherent, navigable system
  2. Demonstrate my approach to engineering decisions and tradeoffs
  3. Act as a living platform I can evolve as my thinking matures

This write-up focuses on the architectural, design, and workflow decisions behind the site—particularly around CSS framework choice, content strategy, and the use of LLMs as an acceleration tool rather than an authorial crutch.

Design Goals and Constraints

Before building anything, I defined a few non-negotiable principles:

  • Clarity over cleverness — both visually and structurally
  • Low cognitive load — the site should feel calm, legible, and intentional
  • Durability — decisions should age well and be easy to maintain
  • Author-centric tooling — optimized for writing, iteration, and reflection

I set out to create something that highlights the work that I do, and doesn't distract with a flashy frontend.

Choosing Tailwind CSS (and How I Use It)

Why Tailwind

I chose Tailwind CSS for three main reasons:

  1. Design tokens over abstractions
    Tailwind’s utility model makes spacing, color, and typography explicit at the point of use. This aligns well with my preference for systems that surface tradeoffs rather than hiding them behind layers of indirection.

  2. Composable consistency
    By defining semantic tokens (e.g. bg-surface, border-border, rounded-card) and reusing them everywhere, I get visual consistency without fighting a component framework’s assumptions.

  3. Low long-term maintenance cost
    There is no bespoke CSS architecture to relearn months later. The markup is the design system.

How I Avoid “Utility Soup”

Rather than treating Tailwind as purely atomic styling, I:

  • Defined a small, opinionated design system (surfaces, cards, buttons, text roles)
  • Reused structural patterns (hero cards, content sections, grids)
  • Avoided one-off styling except where it added clear semantic meaning

The result is a UI that feels cohesive without being visually loud.

Content Strategy: What I Chose to Highlight (and What I Didn’t)

Emphasis on Narrative, Not Enumeration

Instead of listing skills, tools, or years of experience, I chose to:

  • Highlight projects as stories, not artifacts
  • Emphasize motivation, tradeoffs, and lessons learned
  • Treat writing as a first-class output, not an accessory

This mirrors how I think about real engineering work: the why and the how matter as much as the what.

Intentional Omissions

I intentionally de-emphasized or excluded:

  • Long skill matrices
  • Buzzword-heavy summaries
  • Overly granular timelines

Those details already exist on LinkedIn and résumés. datamays.com is meant to answer a different question:

How does this person think, and would I trust them with complex systems?

Writings as a System, Not a Blog

The Writing section is implemented as a lightweight publishing system with:

  • Markdown-authored content
  • Automatic HTML rendering
  • Tag-based filtering
  • Strict reverse-chronological ordering

This allows me to focus on clear thinking and expression, while keeping the technical surface area small.

Posts are either:

  • Published (timestamped and visible)
  • Drafts (fully written, but intentionally hidden)

There is no concept of “content calendar” or engagement optimization—only deliberate publishing.

Using LLMs as an Acceleration Tool (Not a Replacement)

Philosophy

I treat LLMs as high-leverage collaborators, not authors.

They are excellent at:

  • Drafting structure
  • Expanding outlines
  • Stress-testing explanations
  • Exploring alternative approaches

They are not responsible for:

  • Final wording
  • Opinions
  • Architectural decisions
  • Technical correctness

Practical Workflow

My typical loop looks like:

  1. I define intent and constraints
  2. I ask the LLM to draft or explore a direction
  3. I aggressively revise, prune, and rewrite
  4. I re-assert my own voice and judgment

In practice, this cuts iteration time dramatically while increasing clarity—because I spend more time editing than inventing.

The site itself reflects this approach: the LLM accelerates development, but I remain the final arbiter of structure, tone, and meaning.

Technical Stack (High Level)

  • Django — server-rendered pages, explicit data models, minimal magic
  • Tailwind CSS — design tokens and composable UI
  • Markdown rendering — writing-first content workflow
  • PostgreSQL — structured, queryable content
  • Django Admin — intentionally designed as a writing and publishing tool

Every component was chosen for clarity, predictability, and long-term maintainability.

What This Project Demonstrates

This project is not about technical novelty. It demonstrates:

  • Thoughtful tradeoffs across design, content, and tooling
  • Comfort working across backend, frontend, and UX boundaries
  • A bias toward systems that respect future maintainers
  • The ability to use modern tools (including LLMs) without outsourcing judgment

What I’d Improve Next

  • Inline diagrams for architecture explanations
  • Versioned “thinking snapshots” as ideas evolve over time
Project Write-Ups
← Back to writing