Hi my name is Tom. I love formal methods. I hate traveling. 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.

Fortunately, I’ve gotten to do this over and over again, through many years of freelancing where 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.