Meeting Joe Barnes

Meeting someone so technologically focused like Joe was a great experience. Joe was, at the time, working as a Technical Director for Disney. He's been in the industry for 16 years, so Joe is a man with experience. He explained all of the various technical challenges he faced and gave us an important insight into what we might face if we're placed into a tech-oriented position.

He talked over what his forte or niche was, which to him was making the engine itself work. Joe liked to get down into the nitty-gritty parts of the engine and make all of the pieces fit together and work correctly. It was also a very big point to him that whenever code get's committed to a codebase it MUST be of the highest quality coding. That codebase is something that various other people may use and if it is not clean and concise in what it is doing, or if it is hard to use and easily confuses people, then it shouldn't be committed to the base.

Over his interview he also provided us with a few nifty tips that we should keep in mind when getting hired and working. So a few of the main points that Technical Directors look for when hiring is: strong proficiency in the language of that company's choice, an interest in the language so you're committed to it, knowing the ramifications of each line of code, being an excellent problem solver, and of course being a good team player. Being cocky and a know-it-all isn't going to help you impress the person hiring you. Also he explained how development kits are tricky to work with. Since development kits have extra memory built into them for debugging tools the line between how much memory a real system has vs how much memory a dev kit has is kind of hard to notice. Often times games leek over into that extra memory and when they start preparing to ship for launch the team will realize that the normal consoles now don't have enough memory. Joe also remarked how he doesn't actually find comments helpful in industry. While comments are usually a good idea in practice, it becomes inefficient in the actual workplace. Often comments are poorly done and even if they are well done they can quickly become obsolete the useless. Instead of documenting the entire process in comments, one should code their project in a simple and straightforward enough manner that anyone looking though it could piece together how it works.