About

Who

I’m Tom Hyndman — an engineer. This is my personal site.

What’s here

Writing and project notes, kept deliberately simple. Browse the posts, skim the archive, or follow a tag.

Contact

Reach me at mdashx@gmail.com.

Hi my name is Tom. I love formal methods. I love never leaving my small town on the beach. And I love doing nothing all day with my kid and my dog. I am an amateur mathematician, amateur musician, and although I’ve been a professional programmer for twenty years, I still do it for the love of it.

In my career and my personal life, I always find myself in positions of leadership and problem-solving. My favorite job at a company is figuring out how to do whatever it is that stumps everyone else.

This site is a collection of stories, opinions and information about computer programming and who knows what, but on this page, my job is to show you why you want to work with me.

Full-color product vision

True AI-first software development

Top-secret engineering techniques

Leadership from deep in the trenches

Your MVP isn’t minimal enough

In my career and my personal life, I always find myself in positions of leadership and problem-solving. My favorite job at a company is figuring out how to do whatever it is that stumps everyone else.

Fortunately, I’ve gotten to do this over and over again. First, through many years of freelancing and then in startups. In freelance contracts, I often found myself the solo developer with complex problems to solve and no one to tell me what to do. I got those jobs easily and couldn’t get rid of clients because I understood all of the business problems, I contributed to the product vision, and then I actually executed to a high standard and solved problems that other people couldn’t.

I got to do it with a machine-learning startup that hired me to scrape data that no one else could scrape, and ended up trusting me to build their entire information system and integrations with their proprietary ML models.

For six years in the threat intelligence world I was shifted around to solve technical problems, work with people and create new teams in the organization. To be honest, I don’t care about cybersecurity all that much, but when the dark web operatives needed a safe screenshot solution and no one could build it because the high-level APIs were insecure, I was stoked to jump in and build a PNG decoder from scratch to solve our problem. So I never learned a whole lot about security, but I kept finding new cool things to do at that job.

The home services industry was a world I wanted to get into, for some reason, I guess it reminded me of being in Philadelphia and people I knew, so for one year I created an AI-first product development team inside a company in that industry. We successfully worked through a complete product development lifecycle starting with an analysis of all available prior art, interviews with stakeholders and customers, prototyping, specification, early demos with customers, user experience refinements, and finally deploying for iOS and web. It was extremely exciting to be an early adopter of OpenClaw and to orchestrate workflows like delivering automated screenshots to Google Sheets for co-workers to review. For a few weeks, I was pretty sure that custom, persistent agents were going to solve all of our problems.

Recently, I’ve been going all out on Element Sketchpad. It’s the math, drawing, animation, music, programming, shared workspace and tutoring app that I’ve always wanted (and you can bet Euclid would’ve wanted it if he had an iPad). Element Sketchpad is all about expressing yourself in a world where there are no words, no numbers and no coordinates, only compass, straight-edge, colors, animations and sound. My six-year-old loves it, my nerdy fisherman neighbor loves it, and you’re gonna love it.

I’m also working on Dev Log, which is about going beyond open-source and sharing the step-by-step process itself in the world of coding agents. Consolidate all of your chat logs, combine coding sessions into a narrative and publish the story of your app.

I’ve got 20 years of projects under my belt and I try to share as much as I can about my experience, so check out the complete list of stories I’ve shared here:

All Project Stories (so far)

If there is any specific experience, technology, domain or role that you’d like to know more about, please let me know, so that I can share more.

I dreamt about homeschooling long before I became a father, now I’m also involved in tutoring and designing educational software. My daily life is structured by principles from people like Maria Montessori and Marshall Rosenberg. The same principles translate to creating systems and user experiences. The best experiences start with honesty, empathy and goodwill.

Giraffes have the largest hearts…

I’m a humanistic programmer. Since I was twelve-years-old, I’ve seen that reading code lets you drop into another person’s thought process, where you see what they build and how they solve problems in a world of abstract constraints. Of course, literate programming made perfect sense to me the moment I laid eyes on it and Donald Knuth instantly replaced whoever had been in my programming pantheon. Over the years, the programmers who remained role-models were the ones who focused on communication and careful thinking, and who understood computer programs as artifacts of thought, just like math proofs, musical compositions and drawings. Edsger Dijkstra wrote and spoke beautifully about problem-solving, math and computer programming. His book, A Discipline of Programming, is one of those long-term reads that shape how I think about things every day.

Dijkstra might be a bit gruff and formal to present as humanistic, but in the long list of computer programmers who I’ve looked up to, many of them illustrate that computer programming is 100% a human activity. Larry Wall is an obvious example, maybe an example gone wrong, where a linguist is able to pick up enough tools to become dangerous and prove that you really can build anything, and even help power the Internet. Guido van Rossum was right there alongside him, with a different take on how to design a scripting language for humans. I don’t have anything to say about Matz XD, he seems cool. The guys who I consider back up on S-tier with Dijkstra are people like Ken Iverson and Fred Brooks, or Sussman and Abelson. I still watch SICP lectures and I still read Iverson’s books.

Edsger Dijkstra, 1994. Photo by Andreas F. Borchert, CC BY-SA 4.0.

Those two pairs of programmers both worked with programming languages that were human-centric. Both APL and Scheme were created for writing on a blackboard. The point wasn’t to make a computer do anything, those languages were as notation for thinking through problems in a certain kind of way. With APL you learn to see the world as some kind of linear algebra ninja, and with Scheme you become a wizard for whom reality is lambdas all the way down. My favorite language is Z (say: “zed”) because it is the ultimate language. I learned first about Alloy and TLA+. I spent a couple years banging my head against Software Abstractions by Daniel Jackson and I watched everything I could from Leslie Lamport. Then, a guy on the Internet messaged me about the book Using Z, and that became my bible. The difference between Alloy, TLA+ and Z, is that like APL and Scheme, Z was intended from the beginning for a human audience, it’s just math notation for another person to read, it’s not meant for a model checker. With Z, you learn to see problems decomposed into sets and logical relationships, and then solutions composed of state transitions and invariants. Zooming out to this level is like a video I watched about abstraction where the rancher sees each cow as an individual, but many layers of abstraction away, the banker sees the whole ranch as just a number on a spreadsheet. Using Z lets you express any system by its most crucial and abstract characteristics. It puts you at any level of abstraction, without getting your hands dirty in any real-world mess. It lets you create a model of any system, so you can clearly think through and simulate the system, long before you break ground to start pouring cement and nailing together boards.

Another video on the watched list is Lamport’s “Thinking Above The Code”. You should watch that with some kind of feeling of “oh snap, he knew all along”. I think all of the best computer programmers knew, and that’s why smart programmers talked about solutions like domain-specific languages and The Joel Test. The idea is simple: people don’t think. Whether you do a big waterfall design with UML or you throw spaghetti at the wall each week with Agile, both approaches give people a lot of room to hide the fact that no one is really thinking and for sure no one knows what is going on. Learning to express problems and solutions using modeling languages (which is exactly what programming is, we’re just changing the paradigm of the model from imperative or object-oriented to set theoretic) opens up the ability to get concrete feedback about design decisions in a fraction of the time it would take to build.

A page of Iverson notation. Via “Iverson notation” on the APL Wiki.

Vibe-coding is off-the-hook if you know how to vibe your way through formal methods. When I send a 2000 word message describing the vision for my project to the coding agent, the next step isn’t for it to start building the first iteration, the first thing we do is clarify that vision and start producing formal notation that guarantees that me, the machine, and any coding agents that might pick up the project in the future are on precisely the same page. Compared to firing up a JavaScript project, it takes the LLM only seconds to produce a spec in Z or BNF, or a high-level pseudo-program in Scheme. Reading Z, I can iterate through five versions of a complete project in an hour or two, and then once the starting specification is ready, I can walk away from the machine for two hours and come back a version one that looks and works pretty much like we drew it up.

I did grow up on GW-BASIC, the original brainrot, and then Perl and Python, so I’ve been on the REPL, I’ve been there, re-running my script every few keystrokes hoping that I fixed the problem. I can’t claim to be all high-and-mighty now with this mathematical toolkit. I’m a blue-collar programmer, and whatever bits of math I’ve acquired I’ve had to scratch and claw for.

My origin story is in shady poker bots in the early-2000s. When you’re in a greyhat world, it’s hard to come by instruction manuals and tutorials. I figured out early on that the way to get ahead (at least in my little world of programming and problem-solving, I can’t say what’s working out there in the real world) was to step outside of problems and reframe everything in whatever way unfolds when you follow the logic from first principles.

Everyone else was building harnesses for Paradise Poker and Party Poker using windows processes and it was a constant cat-and-mouse game to avoid detection. I was the only person who built a harness in Linux using xdotool and pixel recognition to drive those poker apps running in a Windows virtual machine on a Linux host on a headless server. I had already spent most of my brief time in college compiling kernels and installing Gentoo, so I never even saw the problem in the same way as the Windows developers.

One type of perspective shift is also to go low-level. This helped when a co-worker was blocked on a project for the Tor browser, and I suggested right away that the simple solution was to build our own PNG decoder and they said I was insane. It wasn’t insane and it wasn’t difficult, it just takes a willingness to get your hands dirty reading some specs and writing some code. There’s not always going to be a library there for you to rely on.

Sometimes I’m the guy who writes the library. I’m almost always the guy involved in research and development, and sometimes the product of that is a process for other developers to follow, and a library to help them stick to the process. I’ve followed that game plan a few times, it worked the best with BreachRecon a gigantic and messy ETL job which I setup on Hadoop and Spark. I created a library of chainable functions for parallel processing of large datasets, and then I created training videos showing how to use the library. The plan worked and the team I hired and trained was a success.

…

and so on and so on.

it’s pretty nice being me, though now a couple minutes fucking around editing in vim and I lost that little flow that I started to sit down with, but now my little world is right, my little environment is right, and I’m remembering how to type. Just doing whatever I thought Steve Yegge was doing and I wished I could do, I always thought I was a good writer, but I didn’t publish all of this stuff like Yegge did, or plenty of other people, but most “bloggers” made me cringe, and I didn’t want to be a part of it, although I was always publishing blogs and even had some very minor signs of success.

So now I am writing about why people should hire me, or that’s what I’m suppossed to be writing about, which is fair enough. But also the struggle every artist – how do you commercialize yourself? How do you boil yourself down to a product? And i don’t mean “what is the mechanical process” because any half-witted producer can figure out how to turn a person into a product.

On the far end of the “problem” is someone who simply doesn’t care to be commercialized. This is how I feel as a musician. I feel blessed to be a musician and I don’t care at all if I ever make money doing it or anything like that. I basically feel this way as well about being a computer programmer, a counselor, a leader, a writer, an artist, a tutor, or any of the other things that I’m very good at and could do or have done professionally.

I love being a professional. And I believe that the best professionals started as amateurs. I started as an amateur programmer, I never stopped doing it for the love of it, and I’ve been either the best programmer in every company and every peer group, or I quickly recognized who was way ahead of me, and they were all people who programmed for the love of it. I never met someone who learned to program in college and only writes code nine-to-five with skills even close to what I consider bare minimum for being a “good programmer”.

So I am a professional programmer, and along the way I’ve been a professional leader, and I’ve tapped into a deep toolchest of soft skills as I’ve learned more and more to find power with people, something that Marshall Rosenberg talked about, and it applies just as well in code reviews, standups, pair programming sessions, and especially in team decision-making.

Even as a professional programmer, I still face the dilemma of how to commoditize myself. The fact that I’m a fan of Ken Iverson or Edsger Dijkstra, and that I actually study their work and put many hours of my life into computer science and mathematics (among other things), and all of the other background information like that, any real-life perspective on who I actually am is enough for most people to want to hire me, I’m qualified to do anything, and I’m intelligent enough to point out right away anything that I’m not qualified to do. So what do I say? “AI Solutions Engineer?”, “Full-stack Developer?”, “Some baloney about React?”

If you want to make an excellent hiring decision

Setup a fifteen-minute meeting, so we can get to know each other.

Whether we fit or not, a lot of smart people will tell you that…

Not meeting me would be a terrible hiring mistake.

If you need a fucking coding commando who can drop into a legacy codebase and machete through the weeds to figure out why things are fubar, you might want a minute of my time.

In 2005, I was building custom bot harnesses written in Python and Perl using pixel recognition and X window automation, running in headless Linux servers. Since then I’ve been around a million blocks and if you need help with any mainstream technology stack,

money writing vanilla JS apps and fixing other people’s legacy projects written with tools like Backbone.

I was stoked when Django arrived, because GvR was my man and I didn’t want to learn Ruby. I served as principal engineer at a successful machine-learning startup and later on I used machine-learning techniques to re-imagine a user experience.

If you want to know more, you can check out: Work History and Resume