To give myself a slightly-bigger project, I came up with the idea of writing an simulator game where you’re the CTO of a small startup with a goal of helping your company get to an IPO.
I just started it around dinnertime last night, writing up a few paragraphs with how things like projects, budgets, hiring, incidents, and so on work. I let Claude and Codex rip on a planning (“here’s some words. now ask me questions.”) and implementation loop. After every loop, I’d play around with it, think of a thing that’d make it better, and repeat.
This post isn’t about writing software with agents (though I am amazed and am learning a lot about what they are good at and not so capable of) but a more general thing I’m learning when you’re writing a simulator.
Writing this simulator is as much encoding how I think the job of engineering manager works than anything else. If someone said, “How would you do the mechanics of the job?,” this would be an interactive answer to that question which is neat in a meta way.
When thinking through the elements of the game and how they work and interact, I started to use (my many) years of seeing these things up close to model how I think they should behave.
The first part of writing the simulator was mostly coming up with the nouns, the physical objects: projects, engineers, budgets, incidents and then, what sort of attributes they’d have. Projects have a timeline, whether or not they are started or not, which team they are assigned to and other things that seemed relevant to the flow of the game.
But, thinking harder, I started to think of things that “real” projects have. They have a distribution curve of when they’ll actually finish. The individuals that start on a project might not be the same set throughout. And, when you assign a project to an already busy team, each of project takes a little longer (though you as the CTO/manager might not know that until too late).
I realized that writing a simulator about something you know well, you quickly see where the simulator isn’t correct and you add that in. And, before long, I realized I haven’t written a generic “you’re the CTO” game but instead an interactive way to explore how I specifically see the job. I believe someone else given this prompt would pick different things to emphasize, objects interacting differently, and likely even different success criteria.
(Also, I don’t think the game is “fun” yet but I’m not sure a simulation of a fairly bureaucratic job would be fun? If it does up being fun, or at least interesting in my eyes, I’ll likely open source it but I’m not there yet.)
The other part of this exercise that is interesting is that the game does have some emergent properties. For example, new engineers have some amount of ramp before they are fully productive. New engineers on a project might take longer or make more mistakes (which is natural!). Newer engineers add some risk to projects and missed projects hurt the CTO’s standing and lowers the morale of the team. Each of these consequences follow naturally based on some simple rules, but when interacting together, every game is slightly different and somewhat surprising.