Mario Zechner

Super excited to be doing another one of my live interviews This time, with two legends in the space: @mitsuhiko and @badlogicgames You'll learn how the creators of Pi think code should be written in the AI age Monday, 4:20PM UTC youtube.com/live/ZBTegd8DUZM…

Amp now has a home for all the beautiful things you build. ampcode.com/news/boxes

We're still so small but I'm loving the team we've got at Superlogical. They're so talented and kind and love their craft. It's a different era of software development and our expectations and practices reflect that. I want to share a bit about how we work. First, everyone is trusted to push to main. We do machine-aided code review pre-push and human plus more machine-aided code review post-push. Limited to no PRs. Culturally, we've all agreed that if we ever hire someone who we DON'T trust to push directly to main, then they probably aren't the right fit for the team (so far, not an issue). Some common sense here: if someone is stepping outside their lane or comfort zone, we'll open PRs. For example, I'm pretty trash at macOS/iOS UI, so I'll open PRs for UI-affecting functionality and ask for eyeballs/help. But for business logic and internals, I push to main. Second, everyone can cut a release. Our release process is fully automated and when you start a release (for any platform) it triggers a Slack notification and a 15 minute countdown. The 15 minute warning is a final gate that allows people to review plus collaborate on a changelog. During that 15 minutes, anyone in the company can pause the release rollout. After 15 minutes, the train leaves the station. You can't override the 15 minutes (except to pause). It gives everyone a chance to step in. Third, we avoid synchronization through fast remediation rather than through planning. The server and clients on various platforms ship features as fast as they can. We use post-hoc human review and AI-assistance to identify feature mismatches across products ("Windows has support for X and Mac doesn't." or "Mac and Windows differ in their behaviors for Y in this way."). This avoids expensive "sync" meetings and coordination. We trust that producers of features are mindful of what they're producing and we trust that adjacent product lines will self-synchronize quickly. In practice, we see feature parity across platforms within 24 to 48 hours. All of this works on mutual trust. It ONLY works with mutual trust. Everyone at all times has to trust that they've got each others back: 1. Push to main only works if you fix your mess, or if you don't, that someone else will quickly but that you'd do the same (and generally in equal amounts). 2. Anyone can deploy only works if you trust everyone to cut at the right time, with the right changelog, and that people will respect the 15 minute timer. 3. Sync through fast remediation only works if you trust other teams will pick up and integrate your work quickly, which only works if you would too. It also only works if you are fairly producing mismatches (e.g. not constantly). We've got a great team. I know we're still small and that these practices will change in many ways as we scale. But this is already a markedly different practice than what I would've done 15 years ago. In general, we are building from day 1 on a foundation of mutual respect, excellence, and trust. And it's been awesome.