Important Development Concepts

Whether you’re an expert or just getting started with interactive development, there are a lot of concepts to keep in mind around your development practice. Some of these things you might pick up quickly at the beginning of your career and others are things that you might only start to approach after you’re already an advanced developer! In this post, we’ll cover a few of these interesting and important development concepts that apply to any software development stack.

D.R.Y.

This is one that I can share my personal experience of, since I only really started thinking about this and being aware of it after I had already been an advanced and high-end developer for almost a decade! D.R.Y. was a concept brought to my awareness by none other than Matthew Ragan, and it’s an acronym for Don’t Repeat Yourself. I’ve written about this one a bit previously, and the way I internalized it was that it’s better to be lazy with your fingers than it is to be lazy with your brain. That’s how I approached it at the time and could feel it in my practice. As I review more and more work of others, I feel this is a great one to start to think about as early as possible in your development journey. The main idea is that if you find yourself repeating the same line of code over and over, or if you start copying and pasting a bunch of nodes ad nauseum, that there is almost certainly a better way to do what you’re about to do.

There’s a bit of catch-22 here because if you’re a younger developer, you may not know the better way to approach things, and once you’re an experienced developer, you try to let muscle memory take over so you can finish the projects quicker with the same techniques you’ve used that work. If you’re on the newer side to development, what I’d suggest is reaching out in the community. Between the forums, the Facebook TouchDesigner Help group, the TouchDesigner discord server, and The HQ PRO community, there are a lot of places you could throw your question out there and see what comes back. This kind of practice will really accelerate your learning. On the pro side of things, this one is trickier because you have to find a way to unlearn some habits you may have built up (like I have!!) and replace them with better overall practices (like writing extensions for re-usability of your code). This takes time and can significantly impact your development speed. The best strategies I have for this are:

• Try to find time outside of project work to practice and explore some of these options in an environment free of stress and deadlines (that often cause you to resort to what you know)
• Setup a meeting with a colleague or friend of yours that you know does this already and ask them to show you around a project of theirs or show them a project of yours and ask how they would apply something like D.R.Y to it so that you can quickly get up to speed with how another developer views the same concept
• At the start of a project, pick one small/medium sized thing that you’d like to try to improve about your workflow, then try to integrate that into your project. If you pick something too big, you’ll certainly get frustrated and revert back to your normal patterns, but if it’s small/medium sized, you’ll likely be able to stick to it and actually see how that technique affects the rest of your real-world project

Don’t Resize Operators

This one rides the line between personal preference and what I’ve seen other pros do, but it’s something worth thinking about. I rarely see pro projects where there are lots of operators (like Table DATs or Null TOPs) resized to make them bigger and easier to see. In contrast, a high number of projects I see new developers work on have lots of operators of varying sizes throughout them. Why such a discrepancy? That’s a tough question to answer and my thinking at the moment is that more experienced developers tend to make smaller networks that have compartmentalized functionality, so they often aren’t looking over a network of 100 nodes trying to make sense of it, maybe there are 10 or 20 nodes in a neat little layout. Either way, if you’re just getting started on your journey, I wouldn’t say “Never Resize Operators”, but if you can avoid it and lean instead towards making a higher number of small networks that talk to each other, you’re on the right path to fitting yourself into professional environments more easily.

Keep the project flow matching the logic flow

This one sounds easy but can often sneak it’s way into your project. The main idea is that your project’s layout and data flow should actually match the logical flow of what you’re trying to do. For some projects and types of work this will be easier than for things that have a lot of recursion and feedback loops, but the idea is important. I’ve seen a lot of projects where if I take the developer out of the project and just ask them what are the steps of everything that should happen in order, they can quickly and easily talk through the high level (or even low level) steps. Then I drop them back into their project and it feels like there’s a sense of unfamiliarity or being lost. Why is that? Often I think it’s because TouchDesigner feels really good when we’re almost stream-of-conscious programming. We’re throwing down nodes, making connections, expressions, referencing things, bing bang boom! But often that ends up with some things flowing left to right, then one wire seems to do a wrap around back to the beginning and then things stack top to bottom for a while, then there’s a few things laid out in a grid for reasons, etc etc. This natural flow of development is a great thing to aim for, but if we can always keep our logical flow of what needs to happen active in our brains as we’re flowing, I find people end up with projects that not only can they navigate much more easily but other developers will find it much easier to understand.

This also has real world benefits of making projects more bug resistant! Most bugs I find aren’t because there’s some weird underlying quirk of software I’m trying to workaround, they mostly exist because at some point in time we started throwing spaghetti at the walls to get something done quickly, and now all kinds of things are happening everywhere in the project all at the same time and we don’t have a clear picture of things in our minds. So the more you can keep your project in line with your logic (or start by making logic diagrams before making your project), then the more pleasant your overall development experience will become.

Wrap up

Whether you’re a veteran developer or a beginner to it all, there are lots of concepts you’ll hear on your journey. If you can do your best to try to really internalize as many as you can, you’ll save yourself future re-learning. Obviously it isn’t always possible to take a timeout and re-think your development in the 11th hour of a project, but bringing some of these ideas into your personal practice and skill development can put you on a great path to turning development into a full time career.