User-Oriented Software Development: A Case Study

This is a (heavily) abridged version of an internal talk I gave at Unity in Copenhagen in December 2018 about User-Oriented Development.  I’m sharing it here because I believe the learnings are useful outside of internal tools and outside of Unity. Hello.  Long time no . . . . write?  ¯\_(ツ)_/¯ I’ve spent the last year working on a new internal project at Unity called Flight Control. For the purpose

New Site

Hello, everyone!  I’ve been missing in action, I know.  There are a lot of great things I have been meaning to write about and I’ve been struggling to find the time.  I’ve especially been doing some really cool work at Unity this past year in the area of data-driven development and I’m itching to write about – so this is me attempting to get my act together and start writing

5 Lessons I’ve Learned from Having a Baby

Hello, World!  Well, not exactly.  I’ve been around, just quiet.  The better part of the last year has been spent on this project: In early April of this year, Levi and I welcomed Player 3 into our family.  Baby Bard is a silly, happy, loud, messy, clever little boy who quickly turned our lives upside down, despite whatever efforts we made to plan and prepare for his arrival.  I’m lucky

The Pros and Cons of Lumping Your Builds

At Unity, we’ve been spending a lot of effort recently looking at our build times.  One of the topics that came up is lumped builds.  I realized during all of this (and while doing my own research of course) that many people are lacking a clear understanding of what lumped builds gain you, and what they cost in return. What are lumped builds? Lumped builds are known by a few

Don’t Ask for Permission

Last year, I gave a keynote at ACT-W titled “Don’t Ask for Permission”.  The video of this talk was made available, but I’ve been meaning to make a blog post with the transcript of the talk for awhile.  Since ACT-W 2016 just released their call for proposals, I thought it would be good to finally get around to doing so.  Keep in mind that this talk was given in May of 2015, so some

GDC 2016

Whew!  It’s a week later, and I’m almost recovered from the non-stop whirlwind that was GDC 2016!  I thought I’d do a little write-up of how my week went while it’s still fresh in my mind. (I also got a lot of good inspiration for blog content from GDC, so stay tuned over the next days and weeks.) Going into the week, I was primarily interested in a few different

How to Make Speakers Want to Return to Your Conference

In 2015, I gave a few different talks.  In the past, I’ve talked at large conferences, like the Grace Hopper Celebration of Computing (which is so well put on, it’s mind-blowing), I’ve talked at tiny conferences held in hotel ballrooms and I’ve talked at conferences at various sizes in-between.  Throughout all of this I’ve had both good and bad experiences in terms of the logistics of speaking at conferences.  So today, I’ll share

The 8 Fallacies of Distributed Computing (Something Every Build Engineer Should Read)

Yesterday I was attempting to relax by browsing random things on the internet (usually a mistake, I know), and I stumbled upon an awesome white paper by Arnon Rotem-Gal-Oz about the 8 Fallacies of Distributed Computing.  These are so obvious yet so profound I couldn’t help but write up a quick blog post about them.  They’re especially relevant for modern day build engineers and tools developers — certainly relevant to the Build Automation

Why We Do Code Reviews — And You Should, Too!

A couple of weeks ago at Unite Boston, I had the pleasure of giving a talk entitled How We Make Unity: A Look into How Development in Unity’s R&D Organization Works.  If you missed it and would like to view the slides, they’re available online over here. Unity’s development mainline is managed with a gatekeeper workflow.  A gatekeeper workflow means that developers do not push their own changes to the development mainline,

Engineering: It’s Actually About Problems, Not Solutions

OK, let me clarify.  Engineering is not 100% about problems.  It’s more like the first 70% or so.  The last 30% is about the solution. In all of the engineering teams I’ve worked in, I’m convinced that one of the biggest productivity killers is lost time due to engineers not fully understanding the problem they are trying to solve.  Conflicting advice, not understanding all of the constraints, unclear expectations leading