IF ( writingCode == leftBrain + rightBrain)
I’ve always felt like artists and engineers are the same people. I’m an artist AND an engineer, and I really don’t see the difference between them. Both artists and engineers tend to be very creative, very smart, and somewhat introverted. But artists and engineers also tend to divide themselves into separate groups, and that’s sad.
Artists know that they’re considered nerdy by the rest of the world, but they also tend to think that engineers are even nerdier than they are. And engineers tend to think they’re much smarter than artists.
So they each put up communication walls between each other. It takes someone who is fluent in both worlds to pass information over the walls so that artists and engineers can work together. These walls slow our society down.
While there are cases where the stereotypes may be true, the majority of artists and engineers are exactly the same kind of people. We’ve all been told that we’re strong on one side of our brain, but that’s a lie:
Both sides of your brain are strong.
Whether you’re an artist or an engineer, you have to build things. We are builders. Builders conceive of a vision of what could be, and we manifest it into reality.
When I look at all the amazing things that have been built by either artists OR engineers, I see the same qualities from all of them:
- the ability to extrapolate a solution from a problem
- the ability to create something from nothing by following a vision
- the ability to take a complex task and break it down into smaller, more manageable sub-tasks
- the diligence and focus to not give up when those sub-tasks keep multiplying into more and more and more sub-tasks
- the drive and the hunger to see their creations to its fruition
Builders are problem-solvers. They’re solution creators. In computer science, we use the term algorithms. An algorithm is nothing more than a solution to a problem, a road map to a goal. Artists use different words. They call it creating a pipeline. It’s the same thing. Artists create algorithms just the same way engineers do. The only difference is that they don’t write them down in code.
Code is a wall between artists and engineers. Code makes software engineers feel smart because we have to perform mental gymnastics to read and write it. Artists look at code and want to run for the hills.
At the end of the day, code is just a complex set of instructions for a computer. Those mental gymnastics are actually just evidence that communicating with computers is still hard. Writing code is not something to be proud of. It’s a problem in and of itself, to be solved.
Our current understanding of code is not the end-all be-all method of communicating our ideas to a computer. There’s evidence of this in the history of computer science. Most programmers today write their code in languages that we call “higher-level.” These include C#, C++, Java, Objective C, etc. A vast majority of the systems on all your devices (and across the internet) were constructed in these languages. But do you know why they call them higher-level?
It’s because they’re closer to human speech than the languages that came before. Many software engineers who worked in the early days of computers say that higher level languages are nothing more than “pseudocode.” You need to perform FEWER mental gymnastics to read and write them; therefore they promote laziness.
While it may be true that higher-level languages enable younger computer scientists to write lazy code, these newer languages also eliminate communication barriers between humans and computers. That benefit, it seems, has won the day. Who still builds software using Basic? A great big group of NO ONE. That’s who.
Higher-level languages are not understood by computers automatically. They need to be compiled (i.e. translated) into ones and zeros before computers can process their instructions. We use higher-level languages anyway because they’re more intuitive to human communication. More intuitive means faster and more efficient. You’d think that engineers always aspire to greater efficiency, but you might be wrong in this case.
We software engineers are human beings (surprise?), and like everyone else we become set in our ways. We may be the most tech-savvy people on the planet, but we still fear change like everyone else. We promote the use of higher-level languages even when they’re not necessarily the most efficient means of communication. We do this for two reasons:
- We spent years learning the ins and outs of our favorite languages. We don’t want to see them go the way of the dinosaur.
- Job security. You might not pay us that massive six-figure salary if any old high school kid could do what we do.
Yet, in the software community, there’s also this funny Jiminy Cricket character called open-source. Open-source ideals fly in the face of our fears of self-deprecation by forcing us to admit that we’re stronger together. We know that breaking down any obstacles to sharing and communication is the fastest and most efficient path to technological progress.
So, in the spirit of the open-source community, let’s admit that higher-level languages are clunky, slow, and inefficient… not in comparison to what came before, but what will come after. You know what’s faster than higher-level coding a lot of times?
Visual scripting.
They say a picture is worth a thousand words for good reason. We can process orders of magnitude more information with our eyes than with our voice, and yet we still use our eyes to stare at one line of code at a time.
Writing code is not that hard. Like any language, it’s a matter of syntax familiarity. The hard part is holding an imaginary construct of the algorithm in your head while you’re doing it. It turns out that most software engineers spend a fat majority of their time THINKING, not writing. We have to wire up the system in our minds before we can do it on the screen.
Why do we have to hold so much of the work in our heads? It’s like doing Calculus without a graphics calculator. It might be a healthy mental exercise, but it’s SLOW.
We could be staring instead at a 3-dimensional (i.e. intuitive to real life) visual representation of the entire system as we go, with the ability to drill down and manipulate any part of it. Where’s that solution?
If we look at the current state of video game development, we see visual code finally emerging. It’s funny because “visual” is exactly what we called higher-level languages as they started to emerge. “Visual” Basic. “Visual” Studio. In retrospect, are they really all that VISUAL?
Visual Studio refers to the fact that you can construct the UI in sync with the code that drives it. But when I say “visual” I mean it in a different way. I want visual CODE. I want a graphical representation of the algorithm.
There are many systems in their infancy that can do this. They call it node-based scripting. We had KISMET on the Unreal Engine, which has evolved into Blueprints. Instead of writing code, you add and remove LEGO-esque blocks and wire them up together. There are many similar node-based visual systems in the game dev world.
There are similar node-based systems like Mecanim, Playmaker, and ShaderForge for Unity. We have the Substance Engine for procedural texture creation. Many artists’ professional tools are heading in this direction.
Apple’s xCode with Interface Builder and Microsoft’s Visual Studio are the OLD “visual”. They assume that there’s a front-end UI which should be represented graphically, and a back end which should be represented in code. These newer entries in the game development community challenge the assumption that code is the best way to represent the back end. We CAN make the back end VISUAL.
There are even lower barriers to entry in systems like Game Salad that attempt to bring in builders who have no computer science experience whatsoever. Unfortunately, most engineers see these visual scripting tools as fun toys for artists to play with. After all, those silly artists are CLEARLY not smart enough to handle a higher-level language, so let them have fun with their Tonka Trucks while we’re driving real vehicles.
If we put away our Jump-To-Conclusions mat for a moment, we’ll see that we don’t want to be hasty in pigeonholing these visual scripting engines. It’s true that visual scripting is typically not Turing-complete. In other words, they’re fine for their limited scope of functionality, but they can’t do what a fully-fledged computer language can do (i.e. ANYTHING you want).
The assumption that visual scripting systems will remain in this niche is short-sighted. Artists are just as capable at building algorithms as engineers, and they’re just as hungry to get to their goals. When some of these visual scripting systems do become Turing-complete, software engineers of the world beware. They’ll be coming for your jobs.
Visual scripting is the new “higher level,” and when it’s Turing-complete it’s going to bridge the gap between engineers and artists. The transition will more than double the number of able-bodied software engineers in the work force, which, believe it or not, is a very good thing when we’re closing in on a million unfilled software jobs. The old-school “higher-level” coders will fill the senior positions, and the visual scripters will fill the entry-level jobs.
Higher-level languages are HD, and visual scripting is 4K. It’s only a matter of time before it’s the de facto means of constructing software systems. Engineers, you might be thinking “yeah, right, when pigs fly.” I have one thing to say to that. I’ll bet you there are thousands of retired Basic programmers who thought exactly the same thing about C++.
