All about Technical Directors - Part 2: Types of software developers in the VFX/Anim industry

Second part on the series about what is a Technical Director.

After understanding the problematic use of the term "Technical Director" in the animation and vfx industries, let's dive into a more personal perspective on the types of software developers, TDs and how to become a good one.

What types of software developer are there in the Animation / VFX industries?

I want to share with you my vision on the very important issue of distinguishing types of developers. Specially on the visual media industry, where people with mixed profiles and backgrounds are brought together to work on the same teams.

The quality of the work and market value of a software developer is directly related to his/her background summed up to his/her attitude and experience.

Be warned that this can sound a little bit harsh, specially to people who have not studied a career related to computer science but managed to get a job as an programmer or are willing to do it. I've known so many of these, some felt out of place, others had great egos and had difficulties to accept what they knew and what they didn't; some of them had too much confidence on themselves and thought they knew enough. And some that were amazing programmers and knew much more than anybody else. Don't be fooled and don't feel attacked. You can be great, but if you didn't have the chance or interest of studying computer science before, it is up to you to learn those things that we had to learn to graduate. In fact, you can do it faster and better than we did, because we learned about everything, way too fast and badly... instead you can choose and learn what you need.

Here is a little progression of the level of programming and software architecture knowledge needed for each position, in my opinion:

Artist who knows scripting > TD > Pipeline TD > Software Developer > Software Engineer / R&D

First level: Types of software developers depending on their background

Note here that I'm talking about "vanilla" profiles. I mean, people who did just enough to become a programmer, average interest. Another level of detail is added with attitude, which can make you a terrible develooper or an absolute guru.

A) The artist or technical artist who knows some scripting

What is a Technical Artist? Well that's another story. There are many levels of TAs, specially in game development, from people who create FXs for games to people writing shaders using code. What I mean here is somebody who is an artist but works with more technical features of the software like nodes, maths or some physics (rigger, Houdini'er, nuke compositor).

To advance in their careers, most of the artists I know should learn scripting if they want to automate their own work or build more complicated things, and a big plus in their CV for sure, specially for TAs.

Most of them learn Python, which is natively used by Maya, Blender, Nuke, Houdini, and such. Python is, if not one of the... the easiest language of all popular languages available. It is also a very dangerous tool in hands of somebody working on scripts or code inside nodes that need to be optimal mainly because it is executed many times. But for what artists need, it is generally ok to learn the basics and apply them without worrying too much.

If you work with rigs, that's another story. That's probably the reason why many rigs are terribly slow. (Probably because you added nodes with MEL code on them. Shame on you)

Pros:

They are normally people who have interest in working faster and will work fast if they can.
They started on animation / vfx production before starting to write code
They know what they need and do exactly what they want to automate stuff without anybody else having to make a tool for them. They don't need to do any research before hand
If they keep their scripts for themselves, it will all be fine.
They help around them, reducing the workload of the TDs, which is always appreciated.

Cons:

They don't know what they are doing exactly.
Their code looks terrible and hard to understand.
If something doesn't work, they take a lot of time to fix it... sometimes asking help from TDs.
If their code is used by the team or needs to be optimized, whatever they did should probably be rewritten from the ground up once again by somebody else.
If they contribute to production code for a company without the review of a professional developer, it will become a problem and a waste of money in the future.

B) The artist or technical-artist who transitioned to TD

The same as before, these are artists who were interested more seriously on scripting and started spending more hours on that. Subsequently, they are offered TD jobs and evolve to a more technical position. I've seen this many times in my career and it is very common. There are not many TDs available and people see oportunities on that.

These are required to work on code a longer time, sometimes fulltime. That means they are surrounded by people who know more about it, hopefully take the time to learn more advanced stuff from more experienced colleagues and in several months they start doing more complicated things, building UIs for artists and automating more advanced stuff.

Sometimes they even learning some C++ and work with the Maya or Nuke API. That takes a lot more interest and a lot more time, so we will consider this out of the conversation for now and stay with the vanilla profile.

Pros

They are a very valuable mix of artist and developer.
They know what they are doing just enough, but they don't know how it works inside.
They have the unique capacity of knowing exactly what artists need.
They work fast, know what is needed and do it pretty well.
Their code becomes better after a while.

Cons

Their code is not standarized, sometimes is weird looking and very creative.
It is hard for other developers to understand their code, so a team of TDs with little programming experience and artistic background can be a minefield.
Their code is not optimal, in memory management or execution, those are things in which they don't generally spend time on or don't find necessary... until it is necessary, and all has to be rewritten by somebody with more experience.
They are sometimes considered computer engineers and are asked for key architecture decisions. That happens when they are managed by somebody who can't distinguish between developer types and certainly hasn't read this article.

C) The computer engineer who chose the path of visual media

People who dedicated from 5 to 7 years of their lives, plus optional a master's degree to specialize or more and after finishing all that, decide to work on visual media. That means at least having to learn yet another programming language (python) for a specific software plus more about animation/vfx production and pipeline.

These are very very few. Among the hundreds of thousands of graduates each year on every country, most of them decide to travel the very profitable path of application development or web development. A lot of them started studying computer engineering because they played games and wanted to work on that... after discovering other more profitable jobs and left their dreams in the University.

One of the main reasons why there are very little engineers working on 3d is that... unless you already had an interest on the 3D world, nobody will tell you there are oportunities in this field. After several years you maybe discover graphics programming, only if you are studying among the very few universities that teach that as an optional subject in the last year. Most of them drop their other related subjects due to lack of interest in their alumni. After all that, they become very valuable assets. It is currently one of the most valued type of developer, specially in big studios, where the requirement of being an engineer of some type (specially computer engineer or similar) is normally preferred (but not mandatory, see the "attitude" section).

Pros:

They can apply knowledge from many experiences from the past, and many subjects. That way they can think in a more objetive way and create very advanced architectures for huge projects.
They are good reviewing all the code from artists who became TDs and artists who write scripts for themselves.
Their mandatory knowledge about databases, several programming languages, hardware, optimization, artificial intelligence and the very important subjects of software engineering and software architecture / design, makes them decent thinkers on many of the subjects in advance.
After they are graduated, they have been "working" under a boss supervision, having deadlines and learning new stuff for several years already.
They have been trained to be disciplined (like any other university students for other technical careers)

Cons:

They have no idea of the 3d pipeline if they didn't like movies beforehand.
They don't understand artists if they are not artists as a hobby themselves.
They tend to be slower working and apparently think in advance way too much.
They normally end up leaving the industry or working on huge studios where they are more valued due to the lack of understanding of their capabilities or lack of jobs for them in smaller studios who think they don't need a programmer (there is always a programmer needed on a studio, but that's a very personal opinion).
Engineers are more thinkers than doers and people never understand them very much.

Types of TDs depending on their attitude

The guru

Finds interest in everything. A person who learns everything that falls in their hands that could improve their knowledge. Those people spend years of their lives learning stuff and the best ones are the ones that specialize on just one thing and one thing only.

I've known very few of these. They are absolute geniouses that generally have zero social skills or no interest on any social activities, maybe have their own personal projects, write blog, made courses and did experiments or spent nights working on a cool project with any goal on their minds.

They are generally not goot at managing teams because they only care about learning and have no social skills, but if they like to teach others, they are a huge asset for the company.

A guru can be an artist who became a better developer than a computer engineer. I knew somebody who had less than 23 years old and knew more than most of the people around, read all books available and took the time to write summaries for the rest. So an artist who became a guru on programming are as good as computer engineers and probably better.

The entusiast

Not a guru, just because they want to have a life. But they learn whatever they can to be a better programmer. These are the best profiles in my opinion. People who are interested on everything, and if you know something they don't know, they'll listen and learn about it and apply it to their work. They are fast enough and they also spend time thinking.

Those are people who have personal projects, wrote a blog, enjoy teaching others and spend time listening to others. They are awesome and easily become experts and if they are good at social skills, are promoted to higher levels.

The can be as good as engineers if they were artists before.

The fire extinguisher

People who know just what they need and work fast. They fix stuff faster than anybody but thinks very little about how to do it well. Most of the time they don't have the patience to come back to their fixed code and clean it up. It is difficult to spend time with them and teach them anything, they are too worried about fixing the next bug.

Their code is problematic, ugly, not documented and needs to be reviewed and fixed after the fire is gone. If they leave the company their code is a minefield that needs to be rewritten in the long term.

Perfect for crunch times. Terrible at working on long term quality code and can bring huge loses of money in future productions if changes need to be made.

The thinker

People who overthink how to fix stuff, do it perfectly, but slowly. Sometimes they fix thinks very fast as well, but looks like they are not making any progress at all for hours. I trust these more in terms of code quality.

Not good for crunch times unless well origented, but good for long term quality code. They normally clean code from the fire extinguishers and have conflicts with them. Their code is magically perfect or way too complicated.

The easily satisfied guy

Somebody who thinks that learned just enough. They don't care about patterns or anything that they are not asked for. They work well, but have difficulties at getting better and getting to more high level roles. And if they do, it's because there was nobody else who had more production experience or they stayed longer in the company. They do the same things on and on, never spend time on getting any better. Sometimes they are just fine with that and have no ambition.

These are the ones who don't generally spend time reading any book or asks for help or advice from others.

The toxic static

People who get stressed or get pissed off when asked to learn anything new or to change their way of doing things. These are the programmers who don't want to understand how to make code for others, deny new standards and rules established. It is hard to make them listen when it is needed. Maybe works well and knows a lot, but he/she will never get better and will never be easy to work with. Sometimes these are kept because of their knowledge.

Advice for Human Resources and people who have the task to hire a programmer

When hiring a computer engineer, around 5 years of experience in their field should be considered. So an artist who became a TD is absolutely different form a software engineer becoming a TD. The former are junior on programming, the latter are junior in anim/vfx production, and it should be seriously considered by Human Resources when hiring each.

In my opinion, a software engineer who works as a TD needs to learn very little and can do it pretty fast in a couple of months, just because they did an engineering career, they are used to learn hard stuff. For example, an Animation TD should know about animation and how animators work.

Instead, an artist / semi-artist who became an TD would need years of experience to develop high quality code, even though they can learn how to code very fast, their code will not be good, unless they are the "guru" or "enthusiast" type, who very fast will succeed in becoming great developers. The others, well, it will take a while. If they are regular developers with no personal projects or many years of experience, they will probably be writing code that will be problematic in the future, specially if it is used in production unless a software engineer reviews their code.

It is important to find out how much interest on learning new stuff this profile has. Find out if they are interested in documentation, software patterns and more advanced subjects, if they have a blogsite where they talk about their interests. That is easily tested (and should be) with just three or four easy questions. Otherwise, take for granted that their code will have low quality and should have a more advanced developer review their code before this person is classified.

Code review and documentation is key for the future of the pipeline and code. Software engineers are trained for that, but even some of them ignore it. Takes years to finally understand how destructive that could be. But it is easily checked by reading a piece of code they wrote. So always have somebody with interest in documentation check the quality of their code. And after that, let them review their code at the beginning. Some people need permanent reviewing, some not. And let them be a fence for the rest, so that any code created by a unknown/new TDs or somebody who obviously has no interest on those things doesn't add their code to production code.

And something important: It's not a good idea to hire a computer engineer who just became a TD and make them work on just junior TD stuff. They have more to offer, they are generally more suited for bigger projects, pipelines, architecture and such. Take advantage of them and let them teach others how to become better programmers.

Advice to future and current Technical Directors

Who of these are you? Who would you like to be?

My advice for you to become a better developer:

Learn as much as you can and never stop.
Ask that programmer who knows more than you. And always be open to criticism from colleagues as a form of improvement, don't take criticism personal. (That's for everybody, in fact)
If you have no career on computer engineering you are not a worse developer. Don't let your ego create a barrier between you and knowledge. Just learn by yourself what is needed. Start with code paterrns, optimization, memory management, big O notation, and consider asking any engineer who knows about those things how to start.
Read books on these subjects after you think you already know everything about it.
If you only knew Python, try to learn at least another harder language like C++ (probably the hardest, in fact) and you will understand how inexperienced you were before that. You will have doubts of whatever you've been doing until now.

And always remember the famous Dunning-Kruger Effect. If you have no experience and you just started developing code, you probably have too much confidence after having worked on some tools. But let me tell you: You have no idea. Just see this famous curve:

You think you are the best programmer, but you are not if you just started. There's so much to learn, and you will see after a while, that you have less and less idea than you thought... When you stop feeling stupid, just there... you start the path of being a real expert.

I'm a computer engineer who specialized on graphics and I think I'm an enthusiast. Not a guru for sure. But I take learning very seriously and I gave up many things along the way. It took me around 10 years to finish my studies, plus some more years of working on different types of jobs. Now in 2020, I feel that I'm still around the average curve and a little bit going up to expert... But still a long way to go.

Do you still think you are an awesome programmer or that you still have a lot to learn? :)

Hope you liked this long article, it took a while to write. Please, recommend to others and share. I'd love to see this information moved around. Thanks a lot!

I'll write another separate blog post on how to become a TD. Stay tuned, follow with an RSS Reader of any my social media accounts.

Homepage

About me

Courses

Libros Recomendados