Procedural Instinct

Today, our team fought together to try and nip some logic errors out. It wasn’t necessarily a syntax thing, though, if we had the language down better

and…

again…

especially…

…the rules of Unity down better, we could have nailed it. We could definitely describe what we wanted, and in general what the problem was, as well as what could fix it. At least in English. But translating that to Unity and especially understanding why a plain reading of the situation was not having the predicted results was daunting.

We had an experienced programmer have a look at it and the whole approach he took was different than ours. First of all, there was a sort of procedure to it. Not so much going thru some code from top to bottom but seeming to work from the zoomed out picture and zooming in as well as from the specific detail zooming out at the same time, and where those two hit, he stopped and figured out what was happening and what to do about it.

This really seems like it was something instinctual. I need to get there. I can fly through drum edits and know when and where to cut and how much to move it, even if I can’t see it. I know instinctively how to move through a mix to get what I hear in my head to come out of the speakers. I have no idea how to think like these guys and just go right to where the problems are, or how to set up testing conditions to find them quickly.

So far, my continuity checker (people ask “what’s the most important piece of gear in the studio?” expecting a microphone name or a boutique mic preamp, but I always either say “soldering iron” or more often “continuity checker/ DMM”) has been Debug.Log. I can get a lot done with it, but in this case the grouping was happening among so many seemingly unrelated parameters that I couldn’t keep my head on straight.

In the end, something else ended up breaking but we could actually find it ourselves this time. Still not from feeling our way there, but from a bit of trying to mimic that procedure.