INTERVIEW: Simon Jokuschies // Pipeline TD

Categories Interviews

“Since I was a child, I have always been fascinated by photography, film and the magic of combining and manipulating images. Having decided early to live my passion and what I love, I studied a media degree at the University of Applied Sciences Lübeck, Germany and did a study abroad at the Auckland University of Technology in New Zealand where I gained a broad knowledge about media production.

In 2012 I obtained a Bachelor of Science in Information Technology and Design. I worked as a Nuke and Flame Compositor for 5 years and then switched to the technical side. Currently, I am employed as Pipeline TD at Pixomondo where I concentrate on the 2d pipeline.

In my spare time, I created my own software brand Cragl VFX Tools where I develop commercial and free plugins for Nuke. I have taught several Pluralsight courses and have written multiple technical papers about Python programming.”


Why did you decide to learn to program, and how did you go about learning it?

This may sound weird, but actually what brought my attention to programming was the way code looks, haha. The first time I saw some source code, all the colors and the indentation looked pretty cool and magical to me and I was fascinated from the very beginning. It looked amazing, but on the other hand also really complicated and I wanted to know more about it.

In the early 2000s, I read a few books about game programming and started programming my first games in a programming language called “Blitz Basic”. Later, I picked up web programming and started to develop my own websites, something I still enjoy pretty much nowadays. The first time I got in touch with Nuke was in 2012 and when I found out that you can actually do programming inside it I was amazed.


What piece of knowledge or advice would you give a Compositor who wants to start programming for Nuke?

I suggest the first thing to read is Nuke’s official in-depth Python documentation. Next, there are some great Nuke Python courses on Pluralsight and fxphd. Having an eye on publications on Nukepedia is also a great resource to get some inspiration. And there are lots of great websites out there that contain useful resources. For example, your website, Ben and others like Erwan’s, Mads’ and a lot of other people’s portfolios contain lots of great and inspirational stuff.

Besides programming for Nuke I recommend to be open-minded and have a broader look. You should be familiar with Python itself and not only with the nuke module for Python. You should definitely have a look at the Python documentation and a few good Python books and tutorials. Programming itself is such a wide field and I think it would definitely help to research a bit to see what interests you and what you can do with different programming languages. I think reading a few good books with high recommendations and doing some tutorials are always great ways to get your feet wet. Also, try to get in contact with people who have been programming for some time and see how they approach issues and develop software. Try to accomplish something small and don’t go too big in the beginning. That will automatically come after some time.

At the very beginning, I would not be too concerned about efficiency and elegant code. That topic will be very important at a later stage, though. There are worlds between a program that simply does the job and a program that flows well and does a great job. But I think in the beginning it is pretty much all about getting something done and getting a positive feeling about having something that works, no matter how badly it is engineered under the hood. I always have quite fun reading some old source code of mine from a few years back. We all get better after some time.


Why is Python so heavily used in VFX pipelines vs. other programming languages?

In the past, there existed a few application-specific programming or scripting languages, for instance, MEL and MAXScript. They are actually still embedded into the applications due to backwards compatibility reasons. But they lost their relevance. Python has been integrated into a lot of applications so you can further customize these to your needs. By using just one programming language across several applications things got a bit easier to handle. Python has a worldwide massive user base, keeping in mind that it is used in a lot of areas, not only VFX! But Python has a lot more advantages over other programming languages.

What I like about Python is that it is very flexible and you can do very much with it. It offers a large standard library so you can already accomplish a lot out of the box without the need to install any third party package. There are also thousands of good third party packages out there. As mentioned, Python has a huge community so help is always near. Creating plugins for the VFX industry is just a small section and there is a lot more you can do with Python which is quite exciting, so things will definitely not get boring.

Python is great for creating clean software because it was build from the very beginning to be an easy to understand programming language with a clear syntax. When writing Python code, we should aim to stick to the zen of Python. If you haven’t heard of it, launch Nuke, open the script editor and execute “import this” without quotation marks.

What is great about Python is the fact that the community sticks to a set of rules that are written down in the Python Enhancement Proposal (PEP8). If everybody sticks to it you can read other people’s code and it feels as if it was written by yourself. So, all in all, there are a lot of advantages over other programming languages and the community sticks to certain rules to have one coding style. That is a great convention that I miss in other programming languages.


Tell us about your most productive failure something that didn’t quite go to plan, perhaps in a negative way, that you ultimately learned from.

I think my biggest productive failure was my bachelor thesis back in 2012, haha. I did get a great mark out of it – The failure itself was based on something else which needs a little bit of explanation.

My bachelor thesis was about designing and developing a social media network for media students. It is called Pixiliti and it is actually still online – you can visit it at You can create a user account and upload media projects like photos, videos, illustrations, etc. that you created during your studies and spare time. Others could then comment and rate these and connect with you. The rating results then in a ranking between different projects. So if you upload interesting projects, you will gain more attention. So a little bit like Behance but exclusively for media students. I still really like the idea nowadays. I had this idea in mind through half of my study time so I decided to write my bachelor thesis about it. So I created this website and I really enjoyed developing it. Functionality wise it contained pretty much everything you will find in other social media websites like user account, messaging, privacy settings, notifications and so on.

All in all, this was a massive web project. Even after having graduated I kept adding functionality to it and in the end I had created over 30.000 lines of code. I got quite obsessed with it and ultimately wanted to create the next big social media website. The only problem with that is that a social media community is nothing without its users, and that was, unfortunately, the case. This website never reached a high user base. I quickly learned that this is a key point for a social media website to survive. If there is not enough new content, people will not show up anymore after some time. I would have needed lots of money for advertising to make this website announce worldwide. Although I enjoy developing things, marketing is not really something I am interested in. So, all in all, I spent a great amount of time developing this website, learned a lot about the technical things when creating a social media community and had a lot of fun developing this website. But unfortunately, this website did not really grow enough and a lot of implemented features were not really used.

I think I should have released it maybe a bit earlier with less features and I should have added features on the fly once released. It was not really worth developing that many features when it was not used anyways. I learned from that. Nowadays, I tend to follow a so-called agile development process which follows an early delivery and continual improvement. I should have followed this back then as well. But in the end all is fine, haha. I still had a great time during my bachelor thesis and enjoy looking back at it.


Are there any snippets of knowledge or wisdom you wish you knew earlier in your career?

Time management is something that I wish somebody would have told me is crucial. I think it takes a bit of time and experience to get a feeling for it. If you can predict how much time a shot or a piece of software will take to create then you can much better predict the current status and when you will be done. Getting a sense for it will come after some time, in the beginning, these things are quite hard to judge, I think.


When you get stuck on a problem, what does your thought process or inner-talk sound like? What’s your process for starting to solve the problem?

As a TD, there are basically two different sources of problems I have to deal with in my job: Problems that I myself come across while developing new software and problems that other users come across when using our tools.

For the first one, there are different possible ways to approach. First, having a look at official documentations, be it Python or the documentation of a third party package that I am using is often helpful. Quickly researching on the web and see if anyone came across the same or a similar issue and see if there are any solutions might also help. Furthermore, asking the team and see if anyone can help. Also, taking a break and coming back to the issue helps getting a fresh view and then often times the issue can be quickly resolved.

For the issues other users come across, there are several steps to keep in mind otherwise one might end up wasting lots of valuable time on an issue. I would say it is key to be able to reproduce a bug on your side. Some artists have a good understanding of how to report technical issues while others don’t. So you will usually get a varying amount of information about an issue a user came across. It is crucial first gathering enough information so that you can fully reproduce the error. Often times you should only start having a look at an issue when you have enough information. If crucial information is missing then this can quickly result in looking at the wrong spot or even worse, guessing.

Once all needed information has been gathered, from there on, I would make sure to read and make sure I fully understand provided error logs. I would then make sure it is not just a simple user error which happens when the user did something that they weren’t supposed to do that way. If that’s not the case, there might be some unforeseen bug in the software or simply something that hasn’t been thought of before. If that’s the case I will communicate with the user and the team and see if we need to fix a bug or implement a feature in order to solve the issue.


When making a new tool, what do you consider to make it as user-friendly as possible?

From a users perspective, having a simple and intuitive user interface is key. If a tool is too complicated, users tend to use other tools even if they contain less features. A tool should handle one specific task very well. Having a tool that handles too many things and offers too many features will quickly get too complicated for the user and will probably be harder to maintain from a technical point of view as it might probably contain lots of code to handle. Following a stricter design is sometimes better instead of implementing each and every user request. Steve Jobs said once:

I’m as proud of many of the things we haven’t done as the things we have done.”

There is quite a deep meaning in this sentence if you think about it. There are several other things to keep in mind to increase the user experience. For instance, having in-depth and well-written documentation is quite important, too. I would say the best documentation offers both video documentation and written documentation. I know, this means a lot of extra work. But it is worth it. If you offer only written documentation or only video documentation, that’s still fine but keep in mind that there are many users out there who prefer a video tutorial over written documentation and vice versa. So both are quite important. Offering at least one should be a no-brainer. Also, having tooltips in your user interface will make a tool easier to use.

From a developers perspective there are also a few things to keep in mind. Tools should be stable. The same concept applies here, if a tool crashes too often, users tend to use other tools even if they contain less features and are less user-friendly. Having a clean code base is also quite important even if this point is not that visible for a user. Having a clean code base means that code is easier to maintain and better extendable which enables the developer to add additional elements and fix bugs quicker. If a tool has been created in an unclean way it is harder to extend it. The developer might also quicker run into the situation of creating new issues while implementing new features or fixing existing bugs.

There are additional technical things to consider for enhancing the user experience. For example, exiting functions very early with a clear and easy to understand error message in case the user performs something that is not intended. It is quite frustrating for a user if they get confronted with a cryptic error message. Even better, prevent the user from being able to insert wrong values in the first place will prevent from things going wrong. You should also make sure users will know how to contact you to report issues.

Finally, one word of caution when creating gizmos as I have seen this issue so many times in the past. It is not very user-friendly if a gizmo crashes a whole working file. When creating any gizmo, please only use ASCII characters in your delivered gizmo files. If you don’t know what ASCII is, please quickly look it up. If a file contains any non-ASCII character, Nuke is unfortunately quite unstable and working files tend to get corrupted without any warning at any given time. Just something I wanted to mention here as I have seen this issue so many times and I hope this tip will reach a few users here who create gizmos from time to time.


You have a bunch of experience teaching technical courses via Pluralsight, and have tutorials on your portfolio too. Whilst creating these courses, what have you learned about learning?

I have created three pluralsight courses, “Developing Python Tools in NUKE”, “Developing GUI-based Tools for Production in NUKE” and “NUKE Node Enhancement with Python”. Pluralsight has a few guidelines that authors need to follow and additionally all tutorial videos get checked on content and technical issues. All these strict rules ensure we get the best quality possible. I learned a lot about how to create high-quality tutorials while creating tutorial videos for Pluralsight where I had to stick to these rules. I apply the same rules for my personal tutorials.

In general, I think the way you present a topic in a video tutorial differs quite a lot from how you would teach the same topic in front of a class. Video tutorials should always be to the point and brief. I don’t want to waste anybody’s time and I also don’t really like to watch tutorials where nothing really happens within the first 5 minutes.

I try to make lots of notes before recording a tutorial and have a very clear roadmap of what I want to say. Having good visuals is always a good guideline and it helps the audience to better understand certain topics.

What I found also beneficial is keeping video tutorials short. I think it is better creating several smaller videos instead of one large one that covers multiple topics. I think navigating a bunch of small videos is easier. In addition, I personally find marking code sections that I am currently explaining in the tutorials extremely useful. Otherwise, the viewer might lose track which part of the code is currently being discussed.

When learning something new, I like using video tutorials and having something written at the same time. I tend to implement this in my tutorials too and think it works quite well when you provide some downloadable pdf files alongside with the video tutorials.


You have founded Cragl vfx tools, some of which have been shared via Ben’s Comp Newsletter in past issues. What motivated you to start this project?

The cornerstone for Cragl VFX Tools was set in 2015 when I was still employed as a Compositor. I was experimenting with several ideas for tools that I wanted to have inside Nuke for making every day’s compositing work simpler and to automate certain things. This is still Cragl’s philosophy nowadays.

There were a few basic tools on Nukepedia that tried to solve my needs but they missed several key features that I required. And often times they were not intended to work on all three major operating systems Linux, Windows and MacOS, at least they did not officially state it. That aspect was quite important to me as I use all three operating systems.

My previous company did not have any established pipeline and also no pipeline TDs. So I started creating lists of ideas, workflows and useful features. I created tools out of these that would help to enhance and speed up the work for our compositing team. I kept adding more and more ideas and functionality and quickly found myself in a situation where I had created something that, considering size, went far beyond what I used to create and upload on Nukepedia. These plugins became quite large software projects with several thousand lines of code for each plugin.

I invested some time next to my job as a Compositor in finishing up the initial 4 plugins smartRecents, smartLib, smartShelves and smartMessage. I was experimenting with the question of how to distribute the plugins to the user. I wanted to keep this process as simple as possible and didn’t want to bother the user with downloading a plugin and following several manual installation steps. So I created an automated way of distributing these plugins. That resulted in another plugin known as Connect, which downloads and installs any Cragl tool fully automatically for you so you don’t need to do anything manually and you don’t need to struggle with any download and installation steps yourself.

A good friend of mine, Lars Wemmje suggested why not create a commercial brand out of it. In the beginning, I was a bit unsure if I should go commercial with the plugins but I thought why not. Lars helped me a lot with the design, colors and the Cragl logos which he still does nowadays, by the way.

I was and still am not aiming to make serious money out of it, there is also not really the market for it. I think at the end of the day everything comes down to simply enjoying and continuing what I do as a full-time developer. I enjoy creating new Cragl plugins and adding new features to existing ones.

Besides offering paid plugins, Cragl also offers a few free tools. Given the fact that several weeks or months are spend on each tool, and once purchased you get support and any tool update, offering these tools at quite a low price is a fair deal, I think. Making a little bit of money out of it is a great thing and I usually spend it on buying technical books, tutorials and software, so everything stays in a cycle.


What are your thoughts on personal branding, and tying everything you do together into a cohesive identity online?

I think at the end of the day everything comes down to simply enjoying what I do. I don’t really think about it to be honest. Once started, sometimes I get a little bit obsessed with things and want to make them better and better. Working on software projects at a large scale, constantly trying out different things and putting everything into a cohesive identity is simply something that is natural for me and I love doing it. Also when it comes to bundling everything into a website as I really enjoy web programming. If I can help other people, be it due to giving away my knowledge via tutorial videos or creating some new tools they might find helpful is a good way of giving something back to the community.


How do you balance your time between working for a studio, working on Cragl plugins, and spending time with your friends & family?

I am under the impression that many people struggle to get everything combined – So do I. It’s definitely not easy. Friends and family have top priority, of course. I am however also thankful that my partner understands my passion for programming and she supports me so I often do have a bit of time for some programming in my spare time.

Besides family and friends, there are several things that help me to relax. If I find the time, I like doing some jogging and swimming. I have been playing the guitar for several years and this is also a good way to forget the rest of the world for some minutes. Oh, and I love filming and photography which I have been doing for over half of my life. I bought my first Canon camera when I was 13 and have been a Canon guy since.

Doing some totally different things that don’t have anything to do with programming at all is a good way to keep your mind focused.


Where can people find out more about you and your work?

You can find more about Cragl VFX Tools at I also have a personal portfolio at where I post personal projects and software I created besides Cragl if I find the time.