Earlier this month, I spent a week in beautiful Copenhagen at what’s called a R&D Training week. The goal is that every new Unity engineer spends a week at the Copenhagen office, learning about the systems we use, and about engineering at Unity. Granted, since I’m on the services side, a big chunk of the stuff wasn’t directly relevant, but I did learn a lot, and had a really nice time getting to know people and working on the project.
We had presentations every morning about some aspect of Unity engineering, and in the afternoon (and typically, late into the evening) we worked on a project. I won’t give away details, but in general, we needed to write a Unity engine component, and then tune it for performance using Unity’s job system.
I haven’t written C++ in over a decade (angryweasel pauses to think here if he ever wrote anything but straight C in XBox One…maybe, but nothing other than maintenance). Enough of it came back, however to make progress and figure things out. In fact, in the end, I had a solution that ran correctly, and ran quickly. So I guess I succeeded.
A few thoughts and insights came out while I reflected on the week and the exercise. I had to grep through a ton of source code to learn how things worked, and during that process, I learned how a lot of other things worked. I know more about how the engine and editor work than I ever would have figured out on my own. And, as I mentioned above, I completed the exercise, but that was, I think, a false victory, and one that reflects a real world problem – and a missed lesson learned.
I wrote code that solved the problem. It was fast. It was mult-threaded. It worked. But it was shitty code. In my effort to hit a deadline, I wrote crappy code. It was overly complex. It was filled with dead code and unused variables. I wrote so much crap in such a relatively short amount of time, that I literally forgot what some of my code did. And no, I didn’t write any comments (nor write many tests) for my shitty code. To my credit, you could say what I wrote was a prototype. And like most prototypes, I should rewrite it before shipping it.
It made me realize how easy it is in the real world for us (software teams) to focus on getting our work out to our customers quickly (by a deadline) vs. getting them great work that we can be proud of (and trust). The exercise, of course, wasn’t about getting something out quickly, but I was surprised (and a bit embarrassed) that I lost sight of code craftsmanship over the goal of a deadline (and keeping up with my better coding classmates).
All in all, a fun and interesting week, with some great learning points that I’ll continue to ponder.