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 always try to remember how easy developing internal tools is. We have a captured audience. We can quickly deploy fixes. We are largely independent of rigid processes in place to support the customer base.

Our job, as Tech Artists and tools programmers, is easy. Well, easier, at least.

I think it comes down to this: Dev tools only require the critical path to work. We don’t have to worry about security. We don’t have to worry about cheating. We don’t have to worry about billing. We don’t have to worry about making optimizations that make our code more confusing. We don’t have to worry about the one thousand little things you should if you are developing an external product.

Remember this, and you will be a more effective Tech Artist and Tools Programmer, because you will spend your time where it matters. Forget this, and you will waste your time working on and worrying about things that provide no values, manufacturing theoretical problems.

Ensure the critical path works at all times. At all times. Ensure people are directed down the critical path through intuitive design and documentation. Restrict them from veering off the critical path where you must. Ensure if they veer off your tool’s critical path, it does not cause havoc and they can pick the path back up.

On the flip side, make sure you are being ambitious. Experiment. Have fun. Don’t be afraid to try new things. You are developing internal tools, you have that freedom. Try a new framework. Use a different issue tracker. Introduce a new coding or development style. Install a new tool. Your life is easy because you are working on non-critical software (that’s the truth of the matter, sorry folks, that’s why so many of us have shitty tools). Make up for that lack of prestige by having more fun at work.

Just keep the critical path in mind.

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 know a managers that use ‘make it work’ as an implicit demand, knowing they’re asking you to do the impossible with inadequate resources and forcing you to deal with it- as if it isn’t they’re responsibility. I know developers that are all too eager to say they’ll ‘make it work’, as a way to justify delivering mediocre result- it is a way to ignore the real problems they don’t have the will to deal with.

I know managers who refuse to ‘make it work’, holding back progress because it isn’t perfect, but being forced to release something far under expectations in the end. I know developers who refuse to ‘make it work’, and don’t realize how their selfish whining hurts the team.

Telling someone to ‘make it work’ is not an acceptable course of action. Find out what they need and reconcile what they can deliver with what resources are available. You should be deciding on something clearly achievable, and executing.

‘Making it work’ is not an aspiration. If you are the ‘make it work’ guy, you are, by definition, delivering consistently mediocre work, and short changing your teammates who need to deal with your shortcomings and are perceived as less productive.

Recently edited it, I’m sure I’ll fix it up and change it some more:

The traditional role of Tech Art has been art support, integration, and tools. As the scope of pipelines have grown and matured, Tech Artists find themselves thrust into roles that require a large amount of programming and systems design- roles which their traditional skills have left them ill suited. To deal with today’s problems, every Tech Artist also must be able to “work like a programmer,” as it is the only way to build systems with the size and scope Tech Art now needs to.

We must first understand how Tech Art teams are generally composed and function. This is especially important because even though teams may perform at a fraction of their potential, they are perceived as productive. We will look at the real problems Tech Artists face and at models of solutions- namely, the composition and function of Programming teams.

Next we will explore how to apply those solutions to Tech Art teams. Strategies for controlling and formalizing support tasks, for introducing code guidelines and review, and continuous skills growth will be explained.

Finally, we will look at the pitfalls involved in taking this approach. We do not want to turn Tech Art teams into Programming teams, even if we model them after Programming teams. Just as importantly, and because each studio is different, we will explore how to preserve all of the good things about how a team works while reforming it so it can become more productive and take on vital tasks.

By the end of the session, attendees will have a roadmap to transform themselves and their teams into a cohesive programming unit that can successfully build the complex systems modern development requires.

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.

Ian Cooper, one of the contributing authors at CodeBetter.com, recently wrote an article called ‘Why CRUD might be what they want, but may not be what they need‘.  While this applies mostly to the world of applications, I’ve been saying the same things about tools and pipeline for a while now.  The basic argument goes, the people designing/requesting our apps have a history and understanding of the process, and when we build new systems, they ask for optimized versions of that same process.  But there are very likely ways we can rethink that legacy process in the context of much better technology and software, and change the experience profoundly for the better.  It is our job, as the people who sit between technology and content development, to do that.

And the good news, as always, is that if we fuck up, no one dies.

Go ahead and read the article and see what I mean.

As a small break while I finish my vacation, I’m going to publish my recent post at AltDevBlogADay in three parts.  View it there in its entirety.

Not every studio has these problems (I know because I’ve argued with you about this). And I dare say that studios that don’t have these problems are simply lucky. I suspect that such people are in a fragile situation, and taking away a key player or two would destroy the precarious dynamic that doesn’t birth these problems. If you are at a studio without these problems, ask yourself this: is your setup one that you can describe, export, advocate for, reproduce? How would you do it, without saying “just hire better people?” It is this “coincidence as a solution” that propogates the problems at less lucky studios.

Let’s create real solutions.

We need to create roles and departments that can provide studios with a cohesive tools vision. We need to fill these director-level roles with uniquely qualified individuals who are experienced in art and design, and are excellent programmers. We need to mature our views on tools as an industry, and start looking for concrete solutions for our endemic tools issues rather than relying on chance.
We’re not going to find these people or do these things overnight. We need to, first, decide on this path as our goal. Not just you, but your studio’s management, and there’s no formula helpful formula I can give to convince them. Just nonstop advocacy, education, and reflection.

Then, start discussing what the application of these ideas would mean at your studio. And who is going to fill these key roles? There are people you already have at your studio who just need a little bit of training. Put your tech artists on your programming teams for a bit, or your programmers working on game design or art. See how quickly you’ll find someone with the unique set of skills for a Tools Director position.

We need people who understand how people work and content flows across a project.  We need people who are able to guide its formulation/improvement/reconsideration.  This is vision.  And the lack of vision in tools development is a deadly disease we must remedy if we are to improve the state of our tools across the industry.

As a small break while I finish my vacation, I’m going to publish my recent post at AltDevBlogADay in three parts.  View it there in its entirety.

So how come with Tools and Pipeline we don’t think the same way? There is no Tools Director, so we end up with disparate tools and workflows that fail to leverage each other or provide a cohesive experience. The norm for the tools situation is to look like the type of situation we find in studios with weak leadership at the Director level. A mess.  We need a person who understands how everyone at the studio works, and to take ownership of it and provide a vision for improving it.

No longer can this vital role be left to a hodepodge of other people. Your Art/Technical/Creative Directors, your Lead Programmers/Artists/Designers, can no longer be the people expected to provide the vision for studio’s Tools and Pipeline.

The person who fills this role needs to be someone with enough experience creating art that they can embed with Artists. Someone who can program well enough to have the title of Programmer. Someone flexible enough that they can deal with the needs of Designers. Someone charismatic enough that they can fight and win the battle against the inevitable skepticism, fear, and opposition a change like this would bring.

These people are few and far between, and every one of them I know is happily employed. We’re asking for a unique set of passions and skills, a set that isn’t common in the games industry especially (who gets into games to write tools?!). We need to start training our tools developers (tech artists, tools programmers) to aspire to have these passions and skills.

This won’t happen magically. Unless our studios can promise that these aspirations will be fulfilled, few people will bother, and I cannot blame them. Many studios have made the commitment to having killer tools. Almost as many have failed. And almost as many as that have failed to realize lack of a cohesive vision as a primary factor.

It isn’t surprising that resources get moved from tools dev, that schedules cannot be stuck to, that they cannot attract senior developers. Without a cohesive tools vision, how are resources supposed to be properly allocated? Resources become a fragile compromise between competing departments, rather than brokered by a separate party without allegiances. How is a schedule supposed to be followed, when the people doing the work are not the ones who feel the repercussions? And it is no surprise that it is difficult to attract senior talent with strong programming skills necessary to develop great tools to these positions. If there is no career path- and, let’s face it, most studios have no career path for tools developers- they’re going to go into game programming, or the general software industry (which is, for the most part, some form of tools development in a different environment).