Website and Blog of Rob Galanakis: Tools Programmer, Technical Artist/Animator

When I was starting my job at CCP, I posted about some things I wanted to do as a lead. I’ve been through two releases with the Tech Art Group in Iceland (and for the past 6 months or so been the Tech Art Director here) and figured I’d measure my performance against my expectations.

Training sessions: I’m proud to say this is a definite success. I was the initial Coordinator for our Reykjavik Python Community of Practice (studio-wide volunteer group that discusses python in general and its use at CCP), where I started two initiatives I’m very proud of. One is the weekly ‘enrichment session’ where we watch a PyCon video, go through a demonstration or tutorial, etc. These have gone over great, the trick is to do them even if only 4 people show up :) The other is Python in the Pisser, a python version of Google’s Testing in the Toilet. I hope we can open source the newsletters and maybe share content with the outside world. More information on that coming in the future.

Collective vision/tasking: We run an XP-style team on tech art so I like to think my TAs feel ownership of what they are working on. In reality, that ownership and vision increases with seniority. We are actively improving this by doing more pairing and having more code reviews- the team is at a level now where they can review each other’s work and it isn’t all up to me to mentor/train them.

Evolving standards and practices: We started in Hansoft, moved to Outlook Tasks, and settled on Trello. We’ve discovered our own comfortable conventions and can discuss and evolve them without getting into arguments or ‘pulling rank’.

Community engagement: The CoP and mentoring has definitely done some work here. I try and give everyone 10%/10% time, where 10% is for ‘mandatory’ training or non-sprint tasks, and 10% is for their personal enrichment.

Move people around: We haven’t had much of an opportunity for this but we did change desk positions recently :) The art team is too small to have many opportunities and all graphics development is on one scrum team.

Code katas: We had one and it was mildly successful. We plan to do more but scheduling has been difficult- we do two releases a year, and DUST introduces complications in the middle of those releases, but we’ll be doing more things like it for sure.

I’ve also been doing very regular 1-on-1′s and, I hope, been getting honest feedback. Overall I am happy with my performance but can improve in all areas, even if that means doing more of the same (and becoming a better XP team).

Anyone want to share what successful cultural practices they have on their team/at their studio?

I’ve been a part of  and interviewed at companies where the interview process was not just long but also very wide- people from different teams and departments interview a candidate. (ie, a Microsoft-style interview process)

At my current company, our last two Art hires have had a much more abbreviated hiring process- the Art Manager, myself, and the Art Producer (and the Art Director if needed).

So I’ve been through and a part of interviews at both ends of the complexity spectrum. I’ve been thinking about it recently and I’ll share some thoughts (and I’d also love people’s own opinions and experiences).

• Only a few people are generally good interviewers. If this doesn’t correspond with your Leads/Directors/Managers, there’s a problem. So I am not sure the depth of the interview varies greatly between the two styles.
• On the other hand, interview experience is important for more junior members, and if they don’t get experience they’ll not turn into good interviewers.
• Only a few people are generally responsible for making the decision anyway, and I’ve never actually seen a contentious decision: if one or two people have a thumbs down opinion, it’s enough of a red flag for everyone else. What’s the point of six or twelve people sitting around and pretending to decide?
• How often are interviews really surprising? You know in the first couple minutes whether you’ll accept someone or not, or whether they’re in the middle (usually meaning you need to find a better candidate).

So given those experiences I’m going to try do the following for the interview process for Tech Artists:

• See who wants to be part of the interview. Cultivating this skill is vital, but it isn’t for everyone, and people who have no interest shouldn’t waste their time.
• Expand the interview to include those people- it should definitely extend past the manager/lead level.
• Be rigorous, and don’t bother hiring anyone that isn’t unanimously liked. When the candidate pool is thin or work is slipping, it’s tempting to take a chance. It’s not worth the risk (in my opinion, of course).

I’m curious how other studios handle it, and what people think of those processes?

*I feel obligated to mention that if your studio is a management-run people-churner, please gripe at your managers and not me for writing this post!

I’ve always heard that it was difficult to move from QA into development (game design/programming/art/production). I thought this was smart- QA people should be there to be QA people, not doing a job only because they hope it would lead to something else.

And at some companies, it works. My previous job was at a well-regarded studio, working on a huge game and IP, in a wonderful city, and lots of developers were looking for work (and we had the money to hire them, if not keep them after ship…). People really wanted to work there (I once interviewed someone as I was near the end of my tenure there, and told him pretty clearly, “you won’t like programming here.” And of course he took the job anyway). It didn’t make sense to spend effort training QA people when you could just hire the people you wanted directly.

However, I now work at a place that is much more difficult to hire for. Outside people respect the company and know the game, but the audience is smaller than one of the biggest IPs and most successful game studios of all time. And especially, it’s in Iceland. Iceland is a wonderful country, but we’ve had several people turn down offers or on-site interviews because their family said “no way” (myself almost included).

In my opinion, it makes more sense to hire QA people (often out of the EVE or local Icelandic community), and set them up on a career path that leads outside of QA. There will never be a serious shortage of applications for a QA job, but it can take a year to hire and relocate a senior person (and you are taking a big risk on that time and expense!). And to a large extent, this is what we do (and while we have sometimes failed at providing career paths, I still think it remains the goal).

I quite like this new strategy- not only does it produce good results over time, it also seems to have more integrity- QA people are too often treated like second class citizens, rather than devs-to-be. I’m not sure if my mind will change if I move on to another studio, but it’s at least how I feel now. I wonder how other studios approach this issue?

(Side note- I am not saying there isn’t a need for senior and permanent QA people, I’m just saying, there are lots of people in QA that don’t want a career in QA. There should also be career development inside of QA, but that shouldn’t be the only career development)

There was a recent AltDevBlogADay post about Negative Developers and Team Stability that hit home. It’s not that I think the advice was particularly interesting (good, standard stuff), it’s that it reminded be that I’ve been a negative developer.

I don’t know what I could have done differently. I just wasn’t happy at work, and there was little I could do to change it. The quality of my work was apparently very good, I was just terrible for morale, because I was either 1) pissing people off or 2) encouraging people to be pissed off at the problems I/we saw. Eventually I got the best advice I’ve ever gotten (which deserves its own blog post), and left the company. I went to the right place and became a positive developer.

And that’s sort of what struck me about the article and about how we typically deal with negative developers. Some developers are just not a good fit, regardless of how amazing their work is. If someone is negative because she is “culturally incompatible”, because there’s nothing you or your manager can do to fix it. And it is worth it to have a frank discussion about whether that person can ever be happy without changes to the studio, and if that person says ‘no’, you should discuss plans to part with mutual respect at a mutually agreed date.

I had to put in my two weeks at my last job to have this advice given to me by the President (GM? Can’t remember) at the time. It convinced me to un-quit, and to stay on another year. It ended up being a miserable year in many ways, but it was the right thing to do and worked out for the best. As managers- and friends and team members of negative developers- we need to keep this advice in mind when dealing with negative developers (and ourselves).

The 80/20 rule is generally a good one to understand. 80% of the effects come from 20% of the causes. So how does it apply to software, and to product development in general?

• 80% test coverage. Higher coverage is notoriously difficult to achieve.
• Fix the top 20% of your bugs as 80% of the problems come from them.
• Make 80% of your code side-effect free.
• 20% of your features are used 80% of the time, focus on those.

The list goes on. The 80/20 rule is a good one to keep in your head when you find yourself spending too much time on something.

But if you apply the 80/20 rule to everything, you will only end up with a product or code that is ‘good enough.’

I was looking at some trailers for a game I hadn’t looked at in a while, and the in-game cinematics were awful. Why? Because everything was good enough. The animation system is good enough. The combat is good enough. The tools were good enough. The character customization was good enough. It all amounted to a mediocre result (not the game, but the cinematics).

The 80/20 rule only works when you strive to hit 100%. If you aim for 80% test coverage, you’re going to be happy with 60. If you only care about 20% of your bugs, you’re going to become distant from your users. If you aim to keep 80% of your code side-effect free, you’re going to litter it with ‘one off’ side effects. If you only care about 20% of your features, you’ll probably only take each one to 80%.

It is obviously dangerous to demand 100% in everything, but 80/20 works as a way to balance priorities. 80/20 does not work as a goal. If you are phrasing your objectives in terms of 80/20, you’re never going to excel.

I had this post written up for a long time, and it was much more ranty. But now I’ll just give you some facts (all of which are public) and let you fill in the blanks:

Your bonus is based on “Target Bonus %” x (“Your Performance” + “Company Performance” + “Studio Performance”) x “$ Your Salary”

So if company performance is crap, your bonus can be hurt substantially. I won’t say what a normal target is but it isn’t that high- the CEO’s is only about 100% so you can imagine a normal dev’s is only a small, small fraction of that.

Company sales up from previous year, but a net loss because it pays $682 million+ to buy the studio you just started working for, so your bonus gets hosed. CEO owned lots of money in the company that was bought out so he makes out like a bandit.

I don’t know how that shit is legal.

World financial crisis is in full swing and company clearly will not be profitable. So he cancels merit increases but keeps bonuses.

Well no duh- if your max bonus is 10% of your salary, a modest 2% merit increase is 1/5 the size. If your max bonus is 100% of your salary, it is 1/50 of the size. Manipulating to line his pockets.

After a failed acquisition that cost the company $22 million, the expenses were ignored for performance considerations of the executive team, who set the rules for bonuses and have a clause that they can ignore “non-recurring” expenses such as acquisitions (as if acquisitions were “non-recurring” there!).

I will tell you right now. If our CEO did some shit like this he’d be tarred and feathered. It is a great feeling to work in the same building as your CEO. To know that the only reason he doesn’t know your name is because you haven’t figured out a reason to talk to him at the bar. To know his sweat and blood helped build your company and he didn’t hop over as an executive from some multinational baked goods giant.

Taking pride in your work is a great thing, being able to take pride in the place you work feels even greater (at least for me, since I feel like it adds value to my work). I can’t say I’d categorically not work for another large company, but, not one with a CEO like that.

As I’m coming up on my 5-month mark at my new job, I was thinking about how happy I am here at CCP.  I’ve been waking up at 7:30 for weeks, braving the frigid Icelandic mornings, because I have been so excited to get into work.

My happiness caused me to reflect upon the utter boredom and frustration I felt at my previous job my last six months or so there.  But then I started remembering further back and wondering, when was the last time I felt like this?  Developing something I felt passionate about, something that people saw value in without me having to spend months convincing them, something I didn’t have to beg to get resources to work on.  In a place where people are overwhelmingly positive and non-hostile, with just enough aggression to make sure we can have lively discussions.

I know CCP has its problems and I’ve come in at, in many ways, a good time.  I know there are people unhappy where I am happy.  I know there are people who can work in the same type of environment I was unhappy in and love work every day.  Different strokes for different folks.

What I’m saying is, I spent a long time working, thinking I was happy, but it was because I forgot what happy was.  Or maybe I wasn’t thinking I was happy, maybe I just forgot to consider it entirely.  I forgot what a healthy work environment was, because I came so invested with the people, and stuff I had made, I lost perspective.  (Perhaps this was why I became so unhappy when I switched teams- I lost my already strained sense of ownership and commitment).

No rant or advice or recommendations or even new or good ideas.  Just wanted to share.

-Rob

Repost of my most recent from altdevblogaday: http://altdevblogaday.com/2011/08/26/the-tech-artists-creed

Last month we started a thread on tech-artists.org about creating a tech artist’s creed.  After several weeks of back and forth, we finally came up with something we could all agree upon.  Here it is:

I am a Tech Artist,
Every day I will teach, learn, and assist,
And build bridges between teams, people, and ideas.
I will observe without interrupting and mediate without judging.
I may not give exactly what you ask for,
But I will provide what you need.

I am a Tech Artist,
I will approach every problem with mind and ears open
To my colleagues and peers across the industry.
I will solve the problems of today,
Improve the solutions of yesterday,
And design the answers of tomorrow.

I am a Tech Artist,
I am a leader for my team,
And a standard-bearer for my community.
I will do what needs to be done,
I will advocate for what should be done,
And my decisions will be in the best interest of the production.

My goal for the creed was to have the community come up with a code of ethics and standards for tech art in general.  We are a diverse group and there are as many specialties as there are TA’s.  So it was necessary to create something widely applicable, but still meaningful.

My hope is that we can hold ourselves to, and judge our actions against, this creed.  I think it says everything vital about what a tech artist should strive for.  I know I have not always lived up to it, and I want my fellow TA’s to call me out when I do not.  I expect that other tech artists will share that sentiment.  I want to keep pushing our craft forward, bettering ourselves and our community, and I think this creed embodies that.

So, a short post today because so much brain power and effort went into those words above.  They are not mine alone (or even primarily), they are those of the tech-artists.org community which represents and advocates for the tech art community at large.  I am just fortunate enough to have the honor and privilege of posting the creed here, on behalf of an amazing and incredibly creative group of people.

So read it over, tell me what you think, and if you have something to suggest, suggest away- the creed should continually grow and evolve just as our role does.

Earlier today I left Austin for Atlanta, to start at CCP Atlanta while my immigration goes through.  I’ll definitely miss Austin- Atlanta is not my first choice of cities to live in (especially Hotlanta during the summer!), but I hope I enjoy it while I’m there.  If you want to meet up while I’m in town, send me an email: rob.galanakis@gmail.com .

I hope to continue my blogging frequency and am looking forward to writing more code again.

At BioWare, I pretty exclusively used C#/.NET.  I consider myself a talented .NET developer and have spent a lot of time reading books, blogs, and exploring new technology and techniques.  I’ve dabbled with other languages (and used them where necessary), but I’ve always fallen back to C#.

CCP, though, is a python/C++ house, and I have no desire to try to push .NET there (even if I could).  So I’m entirely leaving .NET behind now and moving forward with python.  I have a lot to learn- fortunately, I think I’m a good enough developer that I no longer need C# to hold my hand.  I think C#/.NET is an excellent platform, especially for learning- the framework helps speed up development by including a great library and it manages memory for you, and the language forces some degree of structure on your programs.  Python has the same benefits but forces less structure on your programs.  This is, in my opinion, bad when you are learning but great when you are done dealing with the clutter and boilerplate those languages impose.

So, after being a diehard C# developer for the last few years, I’m ready to leave it all behind and jump headfirst into python.  I’ve already been updating my blog rolls and going through some great books for months, but I know I have a long ways to go.