Hello, I'm Anthony. I'm a full-stack developer and AI-assisted software engineer with 10+ years delivering enterprise applications. I specialize in C#, .NET, ASP.NET Core, Angular, TypeScript, SQL Server, and Azure, and I use GitHub Copilot, OpenAI Codex, and prompt engineering to accelerate design, implementation, debugging, testing, and delivery.

Design foundations

As a WordPress developer at REV Design, I worked alongside a professional graphic designer who constantly critiqued my design and UI work. I also worked with the company's CEO, who taught me Adobe Photoshop and discussed design and projects with me. I have a keen eye for UI/UX, and these are the principles I bring to the interfaces I build.

• Layout and visual hierarchy

  Composing pages with deliberate alignment, spacing and grouping, so related elements read together and the most important content draws the eye first.

• Semantic HTML

  Structuring markup with meaningful elements, landmarks and a logical heading outline, so the document makes sense to browsers, search engines and assistive technology before any styling is applied.

• Maintainable CSS

  Translating designs into precise, consistent CSS: a shared spacing and type scale, reusable styles and responsive layouts that hold up from phone to desktop.

• Color theory and contrast

  Applying color with intent: a restrained palette, accent colors that guide attention to key actions, and foreground and background pairings with enough contrast to stay legible.

• Typography

  Selecting and pairing typefaces, and tuning size, weight, line height and line length, to build a clear typographic hierarchy that is comfortable to read.

• Accessibility

  Designing for everyone from the start: sufficient color contrast, readable type, visible focus states and keyboard-friendly interactions, guided by WCAG.

What I'm learning

Talks, videos and books on computer science and software craft that shape how I build and keep sharpening my skills.

• LIVE: Uncle Bob on Software Fundamentals in the Age of AI(opens on YouTube in a new tab)

  Matt Pocock

  Robert C. Martin (Uncle Bob), author of Clean Code, talks with Matt Pocock about building software with AI coding agents. His point: agents are fast, but messy code trips them up much as it trips up people, so clean code, well-shaped modules and strong tests still matter, for the same reasons they always have.

  Key ideas

  • Agents thrash on messy code. Stack task on task without cleaning up and they start breaking one thing while fixing another, going in circles - the same wall humans hit.
  • Rules in a long prompt are "more like guidelines": instructions get lost in the middle of a growing context window. Keep the prompt short and enforce quality with deterministic tools instead.
  • Put agents in a loop with automated checks they must pass: CRAP scores (complexity weighed against test coverage), mutation testing, and rules for which modules may depend on which.
  • Chain focused agents: a specifier writes acceptance tests and a written QA procedure, then a coder, a cleaner, a hardener running mutation tests, and a QA agent that turns the procedure into an executable script. It takes about an hour instead of five minutes, but it is still several times faster than a person, at higher quality.
  • Give agents human values, not human disciplines: keep the quality bar, adjust thresholds to what agents handle well, but don't force strict test-driven development on them.
  • He has given up on big up-front specs. Change is now cheap, so he is experimenting with building a story or two, reviewing the architecture, and iterating.
  • Fundamentals still matter because software is enormously complex, and they are how we organize that complexity so both people and models can understand it.

  How to apply it

  • Keep CLAUDE.md or AGENTS.md short, and turn every rule you can into a linter, type check, test or CI gate the agent has to pass.
  • Add a complexity and coverage check, and try a mutation-testing tool (such as Stryker for JavaScript and TypeScript) to find logic no test really covers.
  • Write down which modules may import which, and check it automatically so the architecture can't drift.
  • Split agent work into stages - implement, then clean up and review, then harden - each starting from a fresh context.
  • Work in small increments and review the structure between them instead of handing an agent a long plan.
  • Keep writing some code by hand and read the classic books, such as those by Tom DeMarco and Ed Yourdon, so you can recognize when an agent is struggling.
  • Clean Code
  • Software Craftsmanship
  • AI-Assisted Development
• A Philosophy of Software Design | John Ousterhout | Talks at Google(opens on YouTube in a new tab)

  Talks at Google

  Stanford professor John Ousterhout, whose systems include Tcl and Raft, argues that the most important idea in computer science is problem decomposition - splitting a complicated system into pieces you can build independently - and that it can be taught. He walks through the core ideas of his book and his Stanford design course.

  Key ideas

  • Classes should be deep: a small, simple interface hiding a lot of functionality. The interface is everything a caller has to know, side effects included, so shallow classes add cost without hiding much. The five-call Unix file API is his favorite example.
  • Beware "classitis": lots of tiny classes because methods "should be short." Length isn't the real problem; abstraction is. Make the common case simple.
  • Define errors out of existence: change what an operation means so the error can't happen. Tcl's unset should simply have succeeded on a missing variable - throwing there was his own mistake; Unix lets you delete a file that is still open; a substring call could return the overlap instead of throwing.
  • Still throw an exception when you truly can't do what the caller asked, such as a failed disk read. Part of design is deciding what matters.
  • Working code isn't enough. Tactical programming - get it working, allow a few shortcuts - piles up into spaghetti through hundreds of small mistakes, and the "tactical tornado" who ships fast leaves a mess behind.
  • Program strategically: aim for a great design, because most of the code you will write is in the future. Investing roughly 10-20% more time pays for itself, in his opinion (he has no hard data), within six months to a few years.

  How to apply it

  • Before adding a class or function, weigh its interface against what it hides; fold wrappers that only forward a call back into their caller.
  • Design the interface first, and make the most common use the simplest one.
  • Each time you reach for a throw, ask whether the operation could be redefined so the case is normal: idempotent deletes, clamped ranges, empty results.
  • Spend about 10-20% of your time on design, and leave code a little better every time you touch it rather than making the smallest possible change.
  • In code reviews, talk about design - shallow modules, complicated interfaces, too many exception handlers - not just style and bugs.
  • Software Design
  • Complexity
  • Modular Design
• AI Skills with Matt Pocock(opens on YouTube in a new tab)

  The Pragmatic Engineer

  Matt Pocock, creator of Total TypeScript and of the widely used "grill me" skill for AI coding agents, explains how he plans, delegates and course-corrects with agents. His view: AI has largely eaten tactical programming, leaving us the strategic work, and the classic software engineering books turn out to hold the ideas that work best with agents.

  Key ideas

  • An agent can't read your mind. "Grill me" is a very small skill that tells the agent to interview you relentlessly, so it learns what you value and what is in and out of scope before it writes code.
  • The more context an agent holds, the worse it performs (Dex Horthy's "smart zone" and "dumb zone"). So he turns a grilling session into a spec that says where the work ends, splits it into tickets of one session each, and runs an implementer loop over them while he is away from the keyboard.
  • Match planning to the work: a small change you can check afterward needs no grilling, work that fits one session gets "grill me", and work spanning many sessions gets his Wayfinder skill - a map of decisions with a fog of war that each grilling, prototype or research ticket clears.
  • Cheap prototypes are what keep up-front planning from becoming waterfall: build three or four versions, pick a favorite and iterate before writing the spec.
  • "Leading words" steer agents. Terms like "tracer bullets" from The Pragmatic Programmer, "deep modules" from A Philosophy of Software Design, and "vertical slices" are in the model's priors. He reached for them because agents kept building the whole database layer before the app on top of it, and once he used them, the agent repeated them in its own reasoning.
  • Build a shared domain language with the agent, Eric Evans's ubiquitous language from Domain-Driven Design. Once you both say "materialization cascade", you can describe a change in far fewer words.
  • Memento-driven development: an agent starts every session with no memory, so it can't learn to work around a bad codebase the way a person does. Optimize the code for a newcomer - which is what software fundamentals have always aimed at.
  • He has mixed feelings about test-driven development for agents. It suits small human working memory, which agents don't share, but agents do need feedback loops, so he asks for proof that a change works and watches for tautological tests that just restate the code. He still recommends it for the confidence it gives people.

  How to apply it

  • Before a large or hard-to-reverse change, have the agent interview you until the scope and tricky decisions are settled; skip that for a quick fix you can review afterward.
  • Write the decisions down as a spec, then split it into tickets small enough for one fresh session each.
  • Ask for a thin tracer bullet through every layer first, and name the concepts you want ("vertical slice", "deep module") in prompts and skills.
  • Keep a glossary of domain terms, and use the same names in conversation and in the code.
  • Ask for evidence that a change works, such as a test that fails without it, and have a review agent reject tests that only restate the implementation.
  • Schedule regular codebase care - he runs an architecture-improvement skill every morning and turns its proposals into tickets - and treat yourself as your agents' platform team.
  • Read his three picks: The Pragmatic Programmer, A Philosophy of Software Design, and the first few chapters of Domain-Driven Design.
  • AI-Assisted Development
  • Agent Workflows
  • Software Fundamentals

Books

• The Pragmatic Programmer, 20th Anniversary Edition(opens in a new tab)

  by David Thomas and Andrew Hunt

  Status: Reading