Russell Miner is a Senior UI Engineer at Turbine, Inc. in Westwood, MA. He graduated from URI in 1999 with a B.S. degree in computer science. (Here he is in front of a trebuchet while visiting France!)
FMC: Tell us about your present position. What does Turbine do, and what do you do? Just what is a Senior UI Engineer?
RM: Turbine is a video game studio (recently acquired by Warner Brothers). They have made such games as The Lord of the Rings Online, Dungeons and Dragons Online, and the Asheron's Call series. These are all MMORPGs or (Massively Multiplayer Online Role Playing Games). It is one of, if not the, biggest game studio in the Boston Area.
Before I detail what a Senior UI Engineer at Turbine is, let me clarify one thing that may be confusing to students. In the working world, the terms Software Engineer and Software Developer can be used pretty much interchangeably. I know that back in school, Computer Engineering was a very different course of study focusing much more on the hardware and physical side of computing, while Computer Science had a greater focus on the Software side. In the software industry, the two terms are intermingled, but they usually refer to software only. I personally prefer the Engineer title, as I find it lends a little more weight and authority to the role, though I have certainly used both kinds of titles.
Here at Turbine, an "engineer" is someone who has been trained in software development and likely has a CSC degree, though also possibly a computer engineering degree, or even a "less traditional" degree like MIS, but who can perform the "engineering" tasks that are required. Those tasks are things like reading and writing code, architecting software systems, and understanding how that impacts the hardware that the code is running on.
Having said that, there are many here who are not in an 'engineering' role, but who have CSC degrees. Many of our game designers, who are actually doing things more akin to scripting work, do have CSC degrees. They are now just working farther away from the "engineering systems" of the product.
While this may seem a little confusing, it is the nature of a highly technical product such as a video game. And given that we are making this product essentially FOR computers, nearly every role here at Turbine will likely have some computer science related aspect to it. Even the people who do 3D art end up writing some software of their own, as the tools used to do 3D modeling and animating are even using scripting languages to do things.
Back to my role specifically here at Turbine, a Senior UI Engineer works on the UI (User Interface) team and works closely with other teams (such as game designers, game systems engineers, and core game engine engineers) to imagine, document, and implement our game interfaces. In the end, my job is to produce working interfaces for our games, though much of my time is spent being the technical muscle of the mostly graphic-design-heavy UI team.
To give you a more complete understanding of what that actually entails, I can give you an example of a Day In The Life:
- A game designer has an idea for some new mechanic in a game we are developing. They decide they want monsters who have floating damage numbers above their heads to indicate how much damage they take from the player. I would sit with them and talk more about precisely how they want / expect it to behave. Do the numbers animate? Do they fade off? Are they in a static position even if the monster moves off, etc.?
- Once I have a good understanding, I will typically work with a UI Designer to help make a static Photoshop mock up of how we think this might look.
- Mock up in hand, I begin the work of ACTUALLY making this thing work.
- The UI Technology we use (Scaleform) is one that takes Flash animations and integrates them into our in-house 3D graphics engine, which is written in C++. This means I actually spend most of my time working with Adobe Flash. I am manipulating or creating art assets, as well as writing Flash's Actionscript language. The version of Scaleform we use currently supports Actionscript 2.0, which is an object-oriented ECMAscript language, so that is my language du jour.
- I now plan out how I intend to structure this component, including everything from the art assets I need, their layout and animations, and the classes (objects) in Actionscript that drive them. This means I will be doing the things we did way back in our good old early CSC classes: designing objects and their hierarchy, and then associating those objects to the art assets laid out in the Flash IDE.
- Once I get the widget to behave the way I like in Flash, using local data representations, and internal events, it's time to integrate it with the game engine.
- I now have a chat with my friendly local game systems engineer who is writing largely C++ and who understands all our internal game systems. He has been working on the "back end" of our widget, accessing the data that represents the ACTUAL damage values, the IDs of the entities (monsters) involved, and so on. Together we have defined the events and properties that will be exposed to the UI. This is a key step as game development is a constant balance of precious computer or console resources. We are always trying to make smart decisions about just how much memory and processing we are going to use for any given component.
- I now "wire up" those events and property inquiries into my actionscript, and then compile it to run in our game engine. Now I test away in game! I spawn monsters, attack them, and watch damage numbers fly.
- I now might show this to a game designer, get feedback on what needs to be adjusted, and make changes to the code or the art accordingly.
- Finally, I check in my work, and off it goes to QA (Quality Assurance)!
- The QA department will take my work and perform what is called integration testing on it. This means, that my work is now integrated with the game, and using a combination of automated test framework, and manual scripts, they will test the whole product to ensure that my feature works and didn't break anything. If there are problems—anything from crashing the game to just the usability of the feature—a bug [report] will be filed, I will be notified, and it will be my responsibility to fix it. Once QA has approved my feature, we're done!
FMC: I remember that you began HumanSearch, Inc. while at URI. What was that about?
RM: When I was in school, the Internet as we know it today (i.e. the Web) was just starting to take off. It was the heart of the Boom, and there were lots of opportunities for folks who had the will and the aptitude to learn some Internet technologies to try to do something neat. HumanSearch was a company (and product) that was the brainchild of my roommate Clay Johnson. If you can believe it, Google did not always exist. Back in the day, there were a handful of search engines—AltaVista, Yahoo, Lycos, etc.—and they all had a different approach to the problem of searching the exponentially growing content on the Web. Yahoo, for example, used manual labor to put sites into an organized directory, sort of like the Yellow Pages. Alta Vista used complex algorithms to keyword index pages. You get the idea.
The thing was, finding something you wanted on the Web was actually very difficult. You really had to know these engines, know what they were good at and bad at, and know how to use them properly to get decent results. HumanSearch was a website where you could enter a query, which would then be processed, organized, and eventually submitted to a team of volunteer people, who would then perform the search manually and compile a list of results. This was then returned to the searcher within about 48 hours. The neat thing about it was that, from our Junior Year dorm room, we were managing over a hundred volunteers and handling thousands of searches a day. It was quite a time.
This caught the attention of some entrepreneurs in the Boston area, as well as a bit of press. Eventually HumanSearch became a real corporation, with a modest amount of funding, revenue, offices, and several employees.
FMC: Did that help you get your first position outside of URI?
RM: Undoubtedly. While working with HumanSearch, a company in Cambridge, MA called Abuzz was working along similar lines. They envisioned a knowledge exchange that was powered at its heart by the knowledge of people, but enabled by technology to perform routing, i.e., matching the person with the question to the people who likely had the answer.
Abuzz was in its very early stages as well, and as they did their market evaluations, they discovered HumanSearch. We met with them several times, and while what they were doing was a little different (they were aiming at a corporate market at the time), we hit it off with those guys, shared some ideas, and if memory serves, they may have even given us a token investment.
Well, as senior year came to a close, I had decided that I needed to gain more experience under some senior engineers, and HumanSearch was likely not going to provide that environment for me. I parted ways with HumanSearch and started my search for a job. I knew I wanted to head to the Boston / Cambridge area, and using some job hunting website, wouldn't you know that the first position to come up was for Abuzz (starts with A!). I interviewed there, and with our previous relationship, plus the experience I had gained by working on HumanSearch, I was a shoe in.
Interestingly, I was recently thinking back and noting that the experience, and more importantly, the relationships I made at Abuzz, have in one way or another directly led to every job I have had since. And I found Abuzz thanks to HumanSearch. So without a doubt, all that extra effort, all that free time I spent on HumanSearch, was one of the best decisions I have made in my life thus far.
FMC: You've held several positions during the decade since you graduated. Give us an overview of your career path so far.
RM: HumanSearch was my first real programming gig. It was also critical in that it was an Internet startup. I began to learn the technologies and languages of the Internet, and more importantly, I learned how to evaluate technology, and how to basically build something from nothing with little guidance. Abuzz came next, and while they were bigger in scope (and in checkbook!) it was the same game. Learn new languages and techniques fast, and do it in a startup environment. I had more senior engineers to guide and shape me, but I also had direct input into everything we were doing. I recall spending hours in meetings looking at page flows and layouts and determining what a user experience would be with our product and just how we would implement them. This is the startup environment. You have to be a commando, land on a beach with little support, learn what you can, and make results. The risks are high, but the rewards, the lifestyle, and honestly the satisfaction are fantastic. For me, it was clear that the startup game was the place for me, as opposed to working as some cog in the wheel of a big company making boring bank software :)
Abuzz was a success in that it was eventually acquired by the New York Times. This was also key for me, as through this I learned what a startup company does. I learned about due diligence and acquisitions first hand, as I helped to deliver products that would decide the fate of the deal. All of this was happening within the peak of the Internet bubble, and while the acquisition was a success, eventually the New York Times could never quite figure out what to do with Abuzz, and after a year or so, the bubble popped and, along with a zillion other Internet companies, Abuzz was shut down. Thus the second lesson of the startup game was taught to me: Startups fail—a lot.
While at Abuzz I worked on the UI team. I was writing Java, in our own web architecture, and I worked closely with the UI Design team to make our UIs. The skills gained by being able to communicate with both the design and the engineering teams also turned out to be the foundation of my career. I have always leveraged the fact that I am unique in my ability to be fluent in both the language of design and the language of engineering. After Abuzz, I spent six months or so in a contracting gig at a company called Classwell doing precisely that job. I implemented a new UI for their classroom products, delivered code, as well as helped to bridge their design team and their engineering team.
Contracting was nice in that it paid very well, but it was always known that it would be a short term thing. So I used that time to plan my next move. A colleague at Abuzz, Jay Brewer, who had led the UI Design team at Abuzz, had since moved on to a new startup called Affinnova. They had a novel technology that used genetic algorithms to evolve product design. They had a plan to make a web-based product that would serve surveys to consumers, and then—at its heart—display variations of product designs, and have the consumers evolve those products in real-time simply by choosing the ones they liked the most. With my gig up at Classwell, I joined Affinnova, and worked there for 4 years.
At Affinnova, I helped build an entire survey framework in Java. I did everything from database architecture all the way to UI implementation. This was certainly the majority of my job at Affinnova, but it was not to be the most important part of my work.
It was at Affinnova that I was also exposed for the first time to Flash. We were using Flash as the technology to render the product images to consumers as they took the survey. What was unique here was that Flash was typically being used in other companies in a very design centric way. Show an image, play a movie, etc. What we did was to approach it as a piece of software. We would make it extremely dynamic and leverage the Actionscript language as far as it could go. I helped us use Flash in an object-oriented way, organizing the code AND the artwork in modular ways. This was how we could actually present photo-quality images of countless variations of a product in a realtime manner.
As time at Affinnova continued, my passion for video games also found its first real outlet. In our spare time during the course of a year, Jay and I truly mastered Flash, and learned just what it takes to make a small video game. We created and released a silly flash game called Hillbilly Whack, under the name of Smallfry Studios. We released it for free, so it was not a financial endeavor, but what I learned while making this game was just how complex these things can be. We also would frequently meet up with the Boston-area game-development community for feedback and encouragement.
Eventually I had tired of Affinnova, and I wanted to spend some more time trying to lean in the game-development direction. I wasn't able to get a job in games (this is notoriously hard to do), but I did land a job at a company called Custom Learning Designs. While the name is forgettable, this company was a great place for me to have a change of pace. For the first time I was NOT at a startup. I got a taste of a more laid back atmosphere: you know, working 8 hours a day instead of 12—the little things. I also was able to work pretty much exclusively in Flash, as we created interactive e-tutorials for the Pharmaceutical industry. Again I was working very closely with design teams, and leveraging that skill. Also, as usual, I was the most technically savvy of the team. My experience with everything from the database to the front end, and my schooling in the basics of computer science, were used to help the company deliver ever more technically complex products for their happy clients.
While I was enjoying a pretty great job at CLD, I was contacted by a man named Jon Radoff. He had seen my info on LinkedIn, and I was precisely the person he was looking for to start a new internet company that was closely related to the Gaming industry. They weren't going to make games, but they were creating a site that was serving the gaming community doing everything from guild hosting, to creating a unified gaming history and profile. And so, without even looking for it, my next gig found me. The place was such a perfect fit for my skills, I had to join them. I also would end up being employee number 4 at a new startup, and I would be their lead engineer. Thus I joined GamerDNA.
GamerDNA was a great time. It was probably my most productive job, one where we were delivering new products and features every week like clockwork. I helped form the team, bringing on board an old Abuzz colleague as the Creative Director, and I helped to shape the engineering culture and, of course, the product. I definitely poured a lot of my soul into GamerDNA, and while we received many accolades, we were in fact generating some great revenue. Unfortunately, the "Great Recession" dried up the investment community, and as a result, GamerDNA was not able to secure the additional funding it needed to make it profitable. Yet another startup was to close. This one was particularly hard, as I had put so much into it, but it was also such a great experience that, like Abuzz, it will remain a very special place to have been a part of.
When I found out that GamerDNA was weeks from closing, as chance had it, my old friend Jay Brewer had since been enjoying a career at Turbine. He had joined around the time I started at GamerDNA, and it turned out they needed to hire someone just like me. The timing was incredible. I, along with the rest of the staff, was laid off, and a week later I was working at Turbine.
Turbine, it turns out, was in many ways the fulfillment of a long-term aspiration I had, which was to build video games. This notoriously fickle industry had finally shown an opportunity, and I jumped at it. Best of all, because I had such experience, and because I had a friend inside who knew exactly what he needed, I was able to join the company on my terms, and not have to claw my way up from a low-level position, the typical route of entry.
I have been at Turbine for just over a year now, and I have been loving every minute of it.
That was a long winded answer, but what's interesting to me is how the story plays out. I start by trying out some crazy startup as a couple of kids in a dorm room. By proving that I can do that, and making relationships, I leverage that into a successful career doing internet startups. When I find that creatively I was getting a bit bored, [I move to] another passion project in the form of a flash video game. This leads to more firming up of my skills, and then entry into yet another startup that ties together my love of gaming and my internet skills. Finally, the window opens, and I am able to slide into a role I have always wanted, making games. Now that I have achieved this large goal, I find myself wondering what I should set my eyes on next :)
FMC: Why did you change positions so frequently?
RM: I think there are a couple of answers. I think it's the nature of engineering, the nature of startups, and finally the nature of opportunities.
On the engineering side, I have noted that most of my engineer friends (and myself) find that jobs tend to get boring after about 4 years. This seems to be the magic number where the problems have all been seen before, and the part of your mind that gets tickled by solving engineering problems starts to get bored. There are certainly exceptions to this, such as when you take on drastically different projects regularly (consulting companies, for example). Also, and possibly more importantly, your skills and your marketability as an engineer begins to atrophy. If you spend too long in one place, with one technology or architecture, I feel you run the real risk of becoming irrelevant. As we all know, languages and architectures come and go very quickly, and the new hotness is only hot for so long before its dead. If you want to keep working, you HAVE to be brave enough to try new things. You become a better engineer, and you prove that no matter what comes along, you can adapt to it and be valuable to an employer.
On the startup side, I think it boils down to being a "commando." Some book I read along the way likened the folks at startups to being commandos. They show up with little resources and direction, and they get to make things happen. They create beachheads, and they solve problems. This is really heady stuff. You get power, self determination, recognition, and (potentially at least) big compensation.
But in the life of a company, it cannot remain a startup forever. Eventually the problems have been worked out, the foundation is laid, and the initial funding dries up. It is either going to sink or swim. If it sinks, well, you're moving on :) But interestingly, even if it swims, those "commandos" find that there is no longer a place for them. The next wave of employees comes in (the regular army), and they are able to do things in a different way and on a different scale. The commandos meanwhile slowly start to leave the company to pursue new beachheads to conquer. I am a commando. Once the problems are solved, I find that I really have little interest in the mass-production side. Instead, my talents are best suited to finding new problems to tackle and new exciting challenges to overcome.
Finally, there is the notion of opportunities. GamerDNA is the best example of that one. I wasn't looking for a new gig. In fact, I was quite happy at CLD. But when something comes along, you have to be smart enough to recognize it and brave enough to jump at it. Nobody knows how often they will come along, and so I believe its best to take a chance when one presents itself.
With the combination of new challenges to overcome, and new technologies and architectures to master, and opportunities that present themselves, I have found that after 2 to 4 years, I tend to move on and try new things.
FMC: In your experience, do software engineers typically follow a path like the one you've taken? Should our new graduates expect to change jobs as often?
RM: My observation has been that there are two types of engineers. There are those who find a gig with a nice big "stable" company (e.g. IBM, Microsoft, etc.), and they settle in for the long haul. Others are out there sort of like guns for hire. They follow the work, or the challenges that interest them. My personal belief is that the wise tact is to keep moving. Technology changes so fast that you don't want to risk being caught in one place for so long that your skills atrophy. You may not get the chance to build them up again, as there is always a new crop of students who know the new hotness and have nothing but time to devote to a new company. Some out there may find a place where they can be comfortable for a while, but if anything happens to that "stable" place, like layoffs or a canceled project, they run the risk of being trapped without the skills to be relevant.
FMC: Is there a downside changing jobs as often as you did?
RM: There are certainly the downsides to not having stability. One great example is your retirement or your benefits. Changing companies can mean changing benefits pretty significantly. This is less of an issue when you are young and have no family, but once you add a few kids into the mix, and you realize that your retirement is going to be YOUR responsibility, a change to worse benefits can be pretty painful. Switching companies also means building up that trust and responsibility between you and your company all over again. You may be the GO TO person or some rockstar at one company, but when you switch, you have to build up that relationship all over again. This can take a long time. (I find it takes about a year to build that intrinsic trust.) Having said that, I have found that these downsides can be overcome, and for me personally, they are far outweighed by the benefits of taking on new challenges and learning new skills.
One other BIG benefit to moving to a new job is salary and title increases. I have found it is very true that, while you may be able to raise your position and salary within a company, doing so is slower and harder than joining a new company at a higher level. I think that in many ways, this can be because you, as a new potential employee, are in a greater position of power than when you are a current employee. That new company NEEDS you, and they have some range they are willing to pay to get you. Getting an extra 5 or 10k may be very possible in your negotiations. You may also be able to get a position higher than where you left. But if you are already an employee, you are less likely to up and leave, so they have a bit more power to try to play a little lower. I don't want to sound cynical, but a company has an interest in giving you as little as it can to still keep you happy, and that means many times adjustments and promotions within a company come slower.
FMC: How hard do you work? Does your career leave you with enough time to enjoy life?
RM: In the startup world, hours can be very hard. At GamerDNA for example, every Monday night was "build night" and we would stay until the job was done. This would typically be until 9 pm.. and often until 2am :). Internet Startups also mean you are pretty much always on call. If the website goes down, you are going to get a call. This is the nature of Internet development, and honestly, I think we are compensated at a higher rate because of this.
Happily, I have also had some non-Internet Startup jobs, and as chance has had it, it is during these more typical-hours jobs (9-5) that I have had both my children. Believe me, it's easier to deal with all those infant related things when you don't have to work all night. Even when I have had higher pressure jobs, I have found that everywhere I have worked, the feeling has been that if family issues need dealing with, you can deal with them. You are given the time you need to do what you have to do.
FMC: Any advice you would like to give our current students?
RM: As with all things, do something you love. If you don't get fulfillment because you can't land a job doing the kind of engineering you want, then do it in your spare time. That is the kind of effort that will end up landing you the job you want anyway, and in the meantime, you will get fulfillment from doing it. There are a million excuses to talk yourself out of doing something, but if you just push through and do it anyway, you will find it's very rewarding.
Definitely don't be afraid to try new technologies / languages / platforms. This industry changes faster than most any other, and if you don't change with it, you will be out of a job. Do it on your own, and find ways to do it in your job. When you are the person who steps up to learn something new for the team, or evaluate it, you learn more, and your employer will value you higher; it's a win win.