blzt1tools

We certainly can't speak for the entire industry but we can try to give you a good idea of what it's like to work at Blizzard.

Paulo: My wife calls it "work" (in quotes) as she doesn't actually believe I do any. This is because she thinks I have way too much fun at work and therefore I'm not allowed to call it work.

Anecdotes aside, we have a lot of people that have been at Blizzard for many years. Brett has been with the company for some 14 years and he is not even the most tenured employee within the StarCraft/Heroes team. We have several people with 15+ years at Blizzard.

Replying to your specific questions:

Why do we stay in it?

Working on products that you actually believe in has to be one of the most rewarding things you can do. Doing it in an environment where everyone else is as passionate as you, makes it even better.

What's true?

• Phat Loot! (have you seen our employee rewards?)
• Awesome parties! (Vegas baby)
• Get treated like a rock star when you wear a Blizzard shirt. (how's that for recognition?) At Blizzard everyone works on the game. We all have a say on how we make our games.

What's not true?

• Unrealistic hours - most of us have growing families, so unrealistic hours wouldn't work at all.
• Constant stress and pressure - we certainly have stressful moments, especially when a big release is looming but we're not under constant stress and pressure. This would go against us having fun at work and we can't have that.
• Ramp up, Ramp down - Blizzard does not follow this pattern of ramping up projects and then ramping them down. We don't live and die by each game. We're in it for the long term success of our games and we plan accordingly.

Brett: First and foremost - Rampart. Secondly, definitely the editor. This tool has evolved with the game for over ten years now, and the biggest challenge is always keeping a balance between power and flexibility on one hand, and usability on the other.

Yuval:
C++: We have a 30page, 7500 word coding standard for C++. Obviously that's hard to learn and follow. That's why I'm a big believer in automated-only coding standards moving forward. We're on VS2010 and can't use all of the new C++11 stuff but if it works, and makes sense, we do.

C#: No. It's only internal tools that will run on Windows right now.

Perl: Simple scripts and no actual apps, some of them have grown out of hand though.

Python: Most of our code is Python2 and 3DS Max Tools only work with 2.7.3 so we're pretty much locked for a bit. Though we try to write all our new code in a Python 2 and 3 compatible way.

node.js: This answer's already too long so I'll just mention in node we have a dashboard that monitors all of our other tools are working well and another SPA that inspects the contents of builds which is mostly client side code to make a usable UI and some translation of data on our network server-side. It has proven extremely useful in many cases.

Mac: We use Clang, but that's the mac team's thing. Most of our workstations are windows based and we love MSVS so we're not in a rush to change that at all.

3DSMax: We love it and we don't develop tools when there are such great tools on the market.

MySQL: As we don't modify MySQL code, I believe this doesn't affect us. If anything dramatic ever happens we have a backup plan as you said.

Paul Haban: Software Engineer career levels at Blizzard:

Assistant Software Engineer
Assistant engineers are expected to be passionate about their work. They should be model employees by showing up on time, and generally being reliable. They should remember their commitments and own up to mistakes. They should try to learn from those mistakes, and to grow their individual skills. They should be willing and able to learn the ways of the team if those ways are different from how the engineer may have been taught. Actual code needs to meet the requirements presented by the Lead, and should be compiled and at least quickly tested before checking into the code repository. Assistant Engineers should actively and enthusiastically seek out help, reviews, and advice from their peers, lead, and mentor.

Associate Software Engineer
Associate Engineers exhibit all the traits of an Assistant, but also have a greater understanding of the work they need to do, and the work being done by their team. They better understand the quality standards, and attempt to meet or exceed those standards regularly. An Associate should know when to approach their Lead for training and direction, and when to try working alone. They should be finding the line between too little and too much information, and delivering the most important details about tasks to their team and Lead. An Associate will be asked to do a variety of new tasks and needs to show flexibility to change, as well as focus and determination when trying to power through previously uncharted waters. An Associate should care about the project and getting the job done right, and not about who caused a bug.

Software Engineer
Mid-level Engineers should be well rounded engineers, albeit possibly still relatively inexperienced when considering the number of major projects they have participated in. They are growing as engineers and more often than not seek to discover the solution to their problems before escalating. At the same time, they have enough experience to recognize the point of diminishing returns as well as issues that encompass more risk. Software Engineers are gaining mastery of their primary language and environment while always being open to learning about other technologies. In some cases, they should be expected to provide mentoring to Associates and Assistants as well as architecting parts of projects while under the watchful eye of their Lead. They are in a phase of extreme growth and should be learning what aspects of development they are good/bad at as well as determining what increases their job satisfaction. This will help in the decision on what career path to focus on in the future.

Senior I Software Engineer
Senior Engineers are completely capable of working alone and require little oversight. They have enough experience to be able to anticipate problem in design, implementation and deployment. A Senior Engineer is expected to be knowledgeable in all areas within their field. In addition, a Senior Engineer should be vocal member of the team ensuring that everyone around them is aware of potential problems, the current state of projects/APIs and emerging technologies and methodologies that could be useful to the team. Some Senior Engineers may decide to pursue a more non-technical path in Engineering Management or a technical path toward Lead/Principal by seeking eventual promotion to Senior II.

Senior II Software Engineer
Senior IIs are veteran developers and often have a wide range of experience. They can be trusted to architect and own large systems with minimal oversight, and are able to deliver high quality features with maintainable and understandable code. In addition, a Senior II, especially those on the track to become a Lead, are often capable of leading development on an entire project including overseeing other engineers on the project. A Senior II who wishes to increase their impact and influence at Blizzard can either work towards becoming a Lead, or leading the company's technical advancement as a Principal.

Lead Software Engineer
A lead should be able to build consensus, and be an effective decision-maker while leading a team of engineers to accomplish great things. Lead engineers are expected to be part diplomat, part architect and part coder. They must be excellent communicators and cultivate healthy relationships all around them. Leads implement the Technical Director's vision while also providing critical input on risks, technologies and areas for improved efficiency. In addition, a Lead should act as an example to lower level engineers and provide mentoring to engineers, as they progress through their careers.

Principal Software Engineer
Principal engineers are the technical visionaries of the organization. A principal is a master coder with the ability to influence others via documentation and presentation. Principals are expected to always be thinking in terms of load, scale, maintenance and support. In addition, a Principal should be following the latest industry trends as well as experimenting with different technologies that may help the organization advance. It is expected that roughly 20% of a Principal’s time be dedicated towards helping Blizzard's technology, as opposed to just the technology on the team they’re embedded on. The activities Principals are expected to do during this "20% time" are defined at the time of their promotion, with input from their Lead, their Technical Director and the Engineering Council. Examples of Blizzard-wide responsibilities may include things like contributing to shared code, giving talks at GDC, mentoring engineers across the company and/or representing Blizzard on standards committees.

Yes!