February 2018 · 14 minute read

Over the past few years, I’ve been diving into game development. The goal was always to publish fun little experiments in game design or creative applications of the technology. It’s been a hell of a ride (and a lot of math), and I’ve enjoyed myself in all of the little bits of personal and professional growth.

I have this theory of how I find joy in this silly pursuit I’ve chosen for my life. I call it “The Ding”. Little else, other than learning is as fun as the growth of my understanding in subjects that interest me. I dabble with music production. Do I do it because I aspire some fully realized career in it? No. I enjoy it. Same goes for learning about 3d programming, shaders, or some new flavor-of-the-month JavaScript library. Guitar? Same. Writing? Jury’s out, but it’s looking like more of a hobby.

Overwhelmingly, my time is spent learning how to build the same kinds of things we all build, but in new languages — new systems to build in golang, C++, python, or JavaScript. But most of it comes down to: I really want to write software that you’d consider “Games”. Which means I have to learn a lot of geometry, algebra, and design. It also means learning techniques, over any specific implementation details in a particular engine.

The style of learning how to work in 3d from the web, is by watching tech talks of game developers from Game Developers Conference, whose YouTube channel contains everything the growing developer needs to ding, as well as places like Udemy, who provide sprawling, 80 hour courses detailing every intricate detail of a specific game engine, like Unreal or Unity. All work the same way I’m describing: Techniques over Specifics.

The way I learn is just like how I like to teach: by building a foundation. Techniques and concepts that are needed and necessary to even stand up a cornflower blue screen. A tutorial will probably show you how to do this in any language and rendering system on earth; a bad tutorial will show you how a specific engine does it, a good tutorial will provide some insight and understanding around the topic of a camera and how it works, a great tutorial will have you thinking about how you use that generic tool in your infinite carpetbag of tools for any situation.

That’s the rub. What I want, more than anything else, for those who choose to learn new things: focus on your carpetbag¹.

Over time, doctors carried a bag of “stuff”. This medical version of our carpetbag were not solutions for everything; be more pragmatic than that. What would be in a doctors bag in the 1800s? what about 1940? how about 2018?

In the 1800s, you’d probably see a lot of basic tools. Lancets for boils, bandages were just a sheet from your house, and you would have to account for the fact that aspirin wasn’t available until much later, so in its place? Opium. (or Heroin, but lets not get into that right now…)

Move forward in time 10 years. Does the bag change? What did the doctor learn from 10 years of house calls? 20? 100?

Lets apply that to the way that we learn about technology, specifically programming, and specifically JavaScript, on the web today. I know, deep down in my bones, we all google for answers to basic things. Google itself is just another form of carpetbag, containing various levels of rotting and useful garbage, parsed manually, looking to reignite that ding you had when you were able to recall — say, how to use curves in animations on webpages — worked.

You looked around for a bit and realized that curves were based on two things; Easing equations, and Cubic Bezier curves. Check. Pop that into your carpetbag. How do you use an easing function? Well, do some googling, and pop that in, too.

This is a close approximation to the last few years as I’ve grown as technologist. There is an ever expanding grip of tools that I can use to solve a problem. Most problems. As a polyglot engineer, being able to dip into visual programming, systems programming, or network programming is a significant part of the very foundation of my ability to work in this field. I see it as an absolute; a necessity. Nobody can remember the details of so much without tools, and chiefly among them are my carpetbag.

I’ve also been doing this for what feels like an eternity, and I’ve been privileged and lucky in the kinds of things I’ve got to work on. So what learned?

Find the generic thing more useful than the specific thing. Be cautious! Try not to trust a tutorial or explanation of a system or phenomena that is maximally specific. Reading a tutorial about how to manage state in a web application? Awesome! Reading a tutorial about how Redux 1.2.3 handles recursive actions? We’ve gone off the rails. I’m not saying those articles aren’t useful to their audiences, but perspective is important. One is attempting to teach a concept, and the other is teaching a topic.

This goes the same for people who want to be considered teachers of the trade, and that goes double for anyone who considers themselves mentors. There is little value to your student(s) if they can’t learn at least 50% of the material on their own.

If I were to write a series on 3D programming², I’d make absolutely certain that there are very important fundamentals in place of why and how things work, starting from the very bottom. I would work my way up into each system. Vectors, Matrices, and then Cameras. That would allow me to cover Model Space, View Space, and World Space as a detail of the other three. This “connecting the dots” style of teaching, I think, has a profound effect on how a student comprehends the material.

Please keep in mind the idea that the person who’s reading what you want to teach has no idea of what they’re doing. Even if you’re leading them with both nostrils, in a well lit room, with visual aids. The more you can provide clear and simple examples and progress shots of your work, the easier the material is committed to memory.

For a JavaScript programmer teaching other JavaScript programmers, I implore you to use real world examples of problems you’re trying to solve. If you’re writing a series about Redux, be sure to include an example system you want to improve by these specific things by some quantifiable measurement. I’m not talking about load time or something like JavaScript profiling (although hey, that could be useful, to the right audience), but more generically as a way of comprehension. Teach an example. Target a specific problem. Propose a solution, and implement it fully, including any risks, side effects, or potential problems. Once you’re done, let them practice what they’ve just learned.

Nobody learns anything from “an introduction to Vue.js” but people who were already interested in Vue.js as it is mentally equivalent to Xerox or Kleenex; These are just brand names, now. We need to start thinking about how we train others and evolve the state of the art in parallel with the libraries.

Everybody loses out if we just teach libraries and abstractions on the web. We need to put these brand names into perspective and remember the Law of JavaScript Library Adoption³, that I just invented, just now:

Nobody cares and everybody else has already forgotten. There is a local maxima of value⁴ to all of these modern JavaScript libraries and frameworks like React, Ember.js, Vue, and others.

You need to focus your precious, limited time on learning techniques rather than focus on a specific framework, library, or SDK. It’s great to specialize later on in your career and I understand completely if your job has already specialized on one. It’s just the way the industry works. That does not mean that you should spend every waking moment just learning a specific framework or library.

Filling in one layer (your view) with react is fine; plugging in redux into the state management one and json api onto the data layer itself? You probably don’t need it, at least right now. And you certainly aren’t a better programmer just by utilizing those tools.

Underlying a significant number of them, though, is a new “design pattern” that is actually older than most web programmers of today.

Data Down, Actions Up. This technique basically summarizes that, given any other alternative, your data should drive what you show on screen and how it behaves, animates, or handles changes, specifically and strictly based on what kind of data you hand it when it renders, by rendering as often as you need to.

You may have heard of this as “The reactive programming model” and I guess that’s apt enough for our discussion but what this really means is that you stop working in what you thought was the most logically efficient mode — my brain made some decisions into how the system should work first, and then render that second — and inverts it. The control you had with your original mode — Imperative Mode — is inverted into a new one: Immediate Mode.

The thing is with this scenario is that this new contract — Immediate Mode — requires that you think in a way that, perhaps, feels a bit wrong.

It feels inefficient, doesn’t it? If you wrote JavaScript heavily before React hit the scene, the idea that you can just re-render at will was a sea-change in what you could allow a web page to do. This is amplified significantly if JavaScript was your primary language. To have your code running ALL THE TIME meant that the browser would slow to crawl. You’d lag the page scroll. You could eat up memory with a leak, or just have your work just look “off”. And most of this work? We did it without any of the fancy profiling tools, heat maps, and so forth, that we have today already taken for granted. Both ways! Uphill!

React was ultimately successful in changing the ethos around how much work JavaScript could do due to the idea that browsers, and computers in general, had become significantly more powerful, better designed, and efficient. So do the thing! render however often you need to! Let the superfast computer sitting on your desk figure out HOW it changed, and just render the difference.

That wasn’t necessarily how it was sold to me, for some reason. React was billed, in my experience, as a more elegant way of writing large, complex applications. This sort of color in the discussion about how one group of people looked at their own creations has always felt a bit navel gazing, and missed the mark in what the web developer scene had figured out. All frameworks are a bit guilty of this, but the underlying technical achievement here was applying a clever Inversion of Control⁵ pattern into an effervescent, simple, usable package.

Data Down, Actions Up gave us all a flash of insight into how to solve a serious issue when it came to writing a big, complex JavaScript app; how do you organize the damn thing? How do you make sure that the thing you moved from the left of the screen to the right of the screen was still on the right of the screen, and not back to where it was supposed to be?

This is entering tangent territory, but the above problem — how do you make sure that the information describing the way the UI should look matches what the UI actually looks like — is to this day the underlying challenge with learning how to write big web applications. Data Down, Actions Up, described a way of working — Immediate Mode — so that any time some of the information of what the UI ought to be doing matches exactly with what it is doing; because you made damn sure it did by forcing it to render when the data changed.

This insight powers the majority of the “next gen” web application frameworks, because it eliminates a huge swath of issues that face fresh programmers.

To more experienced developers, sloughing through these problems in Backbone or earlier stuff like Prototype or Dojo, it all felt so laborious. It by no means wasn’t possible — it just felt like a large, complex problem that had at least 1,000 ways to solve it. And it did! React hit a real humdinger⁶.

You wouldn’t have to write your own coordination of things looking-down-and-to-the-left-when-the-mouse-hovered-over-it, and all of the information that goes into making that system. Just punt it! (poof) it’s gone, forever! Any event that doesn’t fit into an action or the data itself can probably be cut.

Before Data Down, Actions Up was the closest thing to a “Standard” that web developers could point to; we did it the opposite way, usually. We would write a some state, apply it to our conceptual copy of what the UI was doing, and make modifications. This approach works, make no mistake. Big, complex, monster websites like Amazon, Twitter, and even Facebook used JavaScript this way; It was salt, not steak. React took the steak we were building with JavaScript and turned it back into salt.

People write software every day that doesn’t require us to use some new method of thought to have basic literacy in. I switch between JavaScript, which has its own flavor, to Golang, which has its own, to python, to elixir, to C#, and finally C++, which means my code is mostly a three Michelin Star garbage pail. Would an Immediate Mode / Data Down, Actions Up technique work in those languages? Sure. Is that the right technique for a server? Probably not, but in some cases? Like in the elixir language Phoenix framework? It fits like a glove.

That’s because I’ve learned the technique. I want to cook a great steak, and if that steak needs a little salt, well — now I know.

Besides, too much salt is bad for you.

Do more up front design before using that new tool to see if it really makes sense, or if it’s just you chasing a hip new fad they teach at conferences. Learn techniques, not just libraries. You’ll be googling how they work, for the most part, for the rest of your career.

I’ll promise you here and now, you’ll be a better developer for it.


[2] I’m doing this, actually! It’s just getting started and I’m hype to share it as I finish up each chapter. Interested? Follow my big fat head on twitter and I’ll post stuff there before it’s ready for release. Critique my hot garbage writing!

[3] The law of JavaScript Adoption states: Any sufficient improvement in the writing and deployment of JavaScript is immediately lost upon anyone who doesn’t use that tool, and everyone other than the maintainer has already forgotten most of how it works. Working in nothing but libraries focuses our design skills on those libraries, rather than how to google for what those libraries do for you, when you need them to.

[4] What do I mean by maxima of value? There is only so much impact those tools should have on what you’re building. Think of a carpenter. The practice of carpentry has been around for ages, right? Do you really think every time some new joint was invented, they retooled the workshop specifically so all of their work included a dovetail joint? No. Each joint has a purpose; some are more aesthetic than others, while some are more difficult or precise, with some kind of trade off or requirement. A maxmia of value in React is; it’s just a view layer — So that leaves the other two layers up to you.

[5] If you’ve read anything about design patterns, Inversion of Control might immediately bring to mind dependency injection — you’re not wrong to think that, as it is a specialized version of the pattern — I’m applying it more generally to the idea of manual coordination rather than DDAU’s version of it. The immediate mode / reactive pattern posits that coordination happens at the action level, and the data itself is immutable once within the render loop of the algorithm.

[6] please see:, also please understand the idea of immediate mode rendering is old as dirt. React’s innovation was applying this technique to the DOM and setting the JS world on fire.