Mark Hazleton, solutions architect

Mark Hazleton · Wichita, KS

I design software for a living, and I still write a lot of it myself.

My day job is leading a team of developers in healthcare, where I design the system and help build it. My rule is to solve the problem, then get out of the way. This site is where I keep notes on what works, what doesn't, and the things I build on my own time.

Want the longer story? Where I've worked and what I've done

How I work

  • Substance over sizzle.

    Something new shows up every week, especially in AI. I only pick it up if it makes this problem easier for this team right now. Being new doesn't count.

    Sidetracked by Sizzle: Staying Focused on True Value
  • Change starts with a real need.

    I build when someone can show me the problem, and often that someone is me, hitting the same wall for the third time. A hunch that it would be fun to build isn't enough.

    DevSpark: Change Must Start With a Real Need
  • Build it so I can leave.

    If something I built only keeps running while I'm around to babysit it, I didn't finish the job. I write it and document it so the next person can pick it up without calling me.

    The Art of Making Yourself Replaceable: A Guide to Career Growth
  • Judgment outlasts the tools.

    I've swapped out my whole toolset more times than I can count since 1991. Judgment, craft and caring about the people who use the thing are the parts I've never had to upgrade.

    The Dependencies I Never Upgraded

I've written the long version down as two methods: Project Mechanics for running projects and DevSpark for building software.

Things I've built

A few I use most or am proudest of, from a NuGet package with thousands of downloads to a website for a local sewer business. The Work page has the full story behind each one: the problem, and why I built it the way I did.

Everything else, experiments included