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.
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?
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.
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.
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.
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.
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.
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.
 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!
 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.
 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.
 please see: https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/#Rendering_engines, 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.