To celebrate the astounding amount of free content on the interwebz (and the Corona Time allotted to us to spend as we see fit), I'm compiling expert advice from some people on my creative family tree.
First up, Japanese animation auteur Hayao Miyazaki.
Studio Ghibli's Animation Software
...is absolutely free.
Miyazaki's Custom Paint Palette
Hayao Miyazaki spent years developing his own sense of color. While each of his films uses new colors, here is the list he describes as his "base set":
Permanent Yellow Lemon
Permanent Yellow Deep
Permanent Yellow Orange
Permanent Green No.1
Permanent Green No.3
Cadmium Green Deep
Cobalt Green Yellow Shade
Cobalt Blue Hue
Rare Miyazaki Sketches To Study
You can find the link here.
It took me way too long to realize that's it's absolutely miraculous and beautiful that we have access to so much art that used to be confined to museums and private galleries.
Art is 50% observation. The more we can take the time to see and study, the faster we'll approach our artistic ideals.
Miyazaki's Run Cycle, Broken Down
How Miyazaki Got Started
Miyazaki spent his childhood reading comics and drawing tanks, submarines, planes. But by the time he hit college, he couldn't draw people!
He didn't got to college for the arts, either. He studied economics while attending a manga club that more-or-less had very little to do with drawing. As fate had it, he got his first job out of college as an in-between artist for an animation studio. While most present-day animation studios outsource for talent, back in the day you could actually learn-on-the-job by being a labor-intensive in-betweener (I still think it should be this way, but I digress).
After getting off from work, Miyazaki said he would try to practice drawing on his own--but would often fall asleep.
So, pretty much, Miyazaki learned to love drawing and stories and movies when he was a kid, went the safe route in college, and got himself a job that let him practice his craft all day long. He spent his off hours working on weaknesses or simply drawing things he enjoyed (he said in one interview that to de-stress he would spend an entire week drawing out custom airplane models).
The point is--you don't have to be a consummate artist by 17 or go to an arts school to become a great artist or even animator. It's ok to hone your skills (and your focus) at a later date.
An Easy-To-Use Studio
Hey, we humans are naturally lazy. It doesn't mean we don't want to accomplish, aren't capable of accomplishing, or haven't accomplished amazingly human things. But it does mean we need to fess up and make things easy on ourselves so we can get started on the hard things.
Miyazaki talks a bit about how he minimizes hassle in his work environment:
"If we're going to moan and groan about too many listless animated works being created recently, when the people with drive and motivation aren't assuming any risk at all, then we've got a problem too. So that's why I think there is real meaning in improving the working environment.
...In designing [my studio]...I tried to make it super easy for me to get from my desk to a conference, or to a discussion with the various production sections, or to the clean-up department.
...We actually planned a room to take a break in which we call 'the bar.' I hate to see people forced to eat lunch at their desks...Until now the [various departments] have been too scattered about to get together easily, so I wanted to create a place where they could gather and communicate with each other if need be, and even have parties. We therefore located the bar in the center of the studio so that it would be easy for people from any section to get to, and right in front of the bar we created a spiral staircase. And we will also plant as many shrubs and trees as possible around the building...hopefully, the neighborhood will be improved a bit by our building this new studio."
[ from Starting Point 1979-1996]
I hope you're finding the mixed blessings during this time.
As a side note, this site is still undergoing constant restructuring as I figure out how to represent what all "this" is (hey, maybe next time we can talk about my very first rejection slip I just got!!).
But until then, glad you were here.
In excelsis Deo.
Recently I came across Jennifer Dewalt's inspiring website about, well, building websites.
A few years ago, Dewalt decided to learn to code by building 180 websites in 180 days. This struck a chord with me.
So I changed up my own website. There's now a tab called "100 Projects." And I'm going to split it into quarters. This website is about where writing meets games--so there's a lot to learn beside coding! But I immensely liked the idea of doing 25 Code Projects in 25 Days, followed by other subjects: pixel art, game design, UI, audio, etc.
But let's not put the cart before the horse. Today, taking inspiration from Dewalt, I wanted to funnel that syllabus I wrote a few weeks ago into these more streamlined deadlines.
Well, my first step was to create this super cool take on Rock Paper Scissors, complete with a new rule system and everything. But seeing as how I've been troubleshooting that all week, I realized that I needed some kind of goods to deliver. So I needed to think even smaller. More by-the-book.
So I found a two-hour C# tutorial that has nothing to do with game development but we're going to follow along anyway.
Project 1/100 = Consignment Shoppe
Step One: Bird's Eye View
When I pay attention to professional programmers, I find one thing they do right off the bat: they define their mission. It's more like they translate their idea into a bullet list of requirements. Once they have a list of the things they want to happen in their program, they can then underline the nouns and pretty much figure out what kind of classes/objects they will need to create. It's both a big picture and fine details approach, and makes code seem a lot more concrete and a lot less abstract.
For Tim Corey, he defined the consignment shop demo in the following way:
1. List of Vendors
2. List of Items per Vendor
3. Each Vendor should have a default Commission rate
4. Commissions can change
5. Track how much to pay the Vendor
6. Track how much to pay the Store
Step Two: Using Excel and Visual Studio To Create Back End Design
We can use Excel to quickly organize all our "moving parts" if you will, and organize them by class and data type. I've never been a huge fan of Excel, but I have to admit, looking at that simple and well-organized table did have a Zen-like effect on me.
Then, Corey set up what our UI should look like in Windows Form.
All of this before hardboiling any code.
This is what's meant by Back End Design: putting down the bones before we make them move.
Step Three: Wiring the Front End to the Back End
Step Four: Testing Small Changes
Step Five: Clean Up
What I Learned:
In Excelsis Deo.
Making A Screen Saver in Visual Studio #C
Last week, I "completed" this screensaver tutorial. Can't say I completely understand everything that was going on (plus I couldn't get preview mode to work), BUT, it still demystified the following things for me:
Gotta admit, it was a thrill going back over some of the code he had written and suddenly going "A-ha!"
I still couldn't have come up with the code itself, but my ability to read and comprehend is getting better, bit by bit.
Riddle Me This
We talked about programming sub-skills a few blogs back, and we came to a conclusion: puzzles. Mental gymnastics, learning how to learn, puzzles, riddles--yes, good. Good for budding programmers.
So I started doing Sudoku puzzles. But going beyond what I used to do, actually looking into two things:
1) Mental techniques for improving my form/efficiency (I turn off the clock on my Sudoku app, but I started caring about the time it took me to complete a puzzle, insomuch as I wanted to improve each game and not just coast through each game for entertainment purposes only)
2) Focus (being able to focus on just this puzzle from start to finish, no interruptions)
And there's a third thing hidden in there:
3) Problem solving
Mental techniques, focus, and problem solving: all of them sub-skills for programming.
I couldn't believe it took me an hour to finish my first Sudoku puzzle. It was only on moderate difficulty.
But the second time, it only took me twenty minutes.
And then I couldn't believe the improvement. I even noticed that I was feeling much less foggy within a week of starting the exercise.
The idea of completing Sudoku puzzles actually came from V. Anton Spraul's book, Think Like A Programmer. In it, he also mentions a gem by the name of Sam Loyd.
I mean, just check out this guy's dedicated web site.
Sam Loyd was an early 20th century puzzle pioneer, and his puzzles are just beautiful to look at. I went ahead and ordered a few of his collected riddles and puzzles, figuring they'd make great keepsakes and handy tools for sharpening my rusty problem-solving skills.
So, I guess the lesson from this practicum is: strengthen your mind, not just through programming. Especially when actually being able to understand programming, let alone being able to program yourself, can be slow goings.
Bonus: Things I Tried To Make Learning More Automatic and Organized
1. Defining My Environment
The same computer I use to write short stories, browse the internet, check emails, and play video games is the same computer I use to work on my projects, take tutorials, write my blog, and watch lessons.
Oh, and it's also in the room where I read and sleep.
Needless to say, some days the temptation to noise and distraction is overwhelming.
So I tried two things.
I made sure all my clothes remained in my closet, at least 80% of the time.
I lit a candle every time I had trouble focusing on just coding.
Keeping my room an average level of clean kept me from anxiously nitpicking it or anxiously ignoring its faults. And lighting that candle served as a signal to my brain that it was time for one specific thing.
2. Getting Up At The Same Time Every Day
I really struggled with brain fog between Blog #5 and Blog #6. So I did what I knew I should have been doing all along: regulated my sleep schedule.
This is easier said than done. I should say I wake up at relatively the same time every day. And that this one is a work in progress.
But I decided that this task was important, even if it felt only tangentially connected to my more passionate goal, which was to wrap my head around the concepts we've been exploring. I realized, however, that I was chasing stimulation instead of results.
And it's hard to admit, sometimes, that results are a product of time and, not, strictly, productivity, or what passes for productivity.
So, I've made consistency a priority, even if its slow goings.
3. 30g of Protein within the first 30 Minutes of the Day
Sometimes I really don't want to do this one (and, um, sometimes I just don't do it), but I know its results first-hand. I started this habit way back in high school and the results spoke for themselves: I lost weight, gained energy, and had a habit I could rely on.
So I retuned this habit recently, taking Timothy Ferriss' advice to eat 30g of protein within the first 30 minutes of waking up. This is one of Ferriss' MEDs (minimum efficient dosages), or the least you can do for the most results. In this case, eating 30g of protein within the first 30 minutes of waking up is a two-fold no-brainer:
A. It regulates fat like nothing else. Without changing anything else in their diet or exercise routine, obese practitioners who put this habit into daily usage saw a monthly increase in weight loss (Ferriss' own dad went from losing 5 pounds a month to 18+ pounds a month from this ONE thing alone--he didn't regulate any other part of his diet and he didn't start hitting the gym).
B. It regulates mood. Some days I'd be fine skipping breakfast--could even feel heroic. But the compound interest would result in a few inefficient, foggy days about a week later--it almost always works like that, doesn't it? The results of our decisions can feel so delayed it's hard to say what caused the sudden lag.
4. Putting A Win At The Beginning of the Week
Ray Bradbury once told struggling writers to aim at writing 52 short stories a year, one for every week. I mean, you can't write 52 bad short stories in a row.
Realizing that the first week of January had yet to pass, I thought--why not? Some would be prompts, some would be flash fiction, some would be just for me, some would definitely be aimed at contests and publishing.
Then I made one more caveat: I'd make sure I got the story done at the beginning of the week. Monday or Tuesday, using Joyce Carol Oates' advice of just writing the rough draft in one complete gulp. "You can edit for weeks afterword." Well, hopefully not, but as weird as it sounds:
We're going for quantity over quality this time around.
And I'm putting this goal at the beginning of the week so I have psychological goodness running through the rest of my week. When I'm struggling with making progress or staying focused or skipping breakfast or some other misstep, I can think--"Yeah, but I finished that thing."
And I finished that thing today, y'all.
It feels good.
Bonus Bonus: A Good Read
Great interview from game designer Chris Avellone.
In Excelsis Deo.
This week I completed Computer Science 101: Master the Theory Behind Programming. Here's my notes!
As a disclaimer, I don't claim to be an expert that can teach you these things, which is why I make sure to link plenty of articles from people who are experts. But using the Feynman Technique, I'll fancy myself a teacher trying to explain these topics to a student. Your patience is appreciated.
Now in the grand scheme of things, this is furiously brief. Check out the course in the link if you're so inclined, or pick up a book (Computational Fairy Tales, The CS Detective, Computer Science Made Easy--just to name a few), or find some free YouTube vids to go further in depth!
Here's our Table O' Contents:
I. The Binary System: How Do It Know?
II. Time Complexity: What We Talk About When We Talk About Runtime
III. Or What's An Algorithm For?
IV. Math: A Way of Thinking About...Everything
V. Who's Afraid of the Big-O Notation?
VI. The ABCs of How To Begin Thinking Like A Programmer
VII. Congratulations, You Made It To The Summary!
But for now, let's hit the ground running.
I. The Binary System: How Do It Know?
This is how computers think:
This is just a short blurb about the binary number system. It's not essential to know this inside-out, but for the purposes of understanding the logic of computers, it's pretty helpful.
"At the fundamental level, the computer only knows zero and one."
Let's break that down.
So, our computer runs on--what? Electricity.
Go over to your nearest light switch. Or just look at it, that's fine.
We switch it on. To a computer, that's the equivalent of a "1."
We switch it off. To a computer, that's the equivalent of a "0."
So, way down deep, underneath all those fancy user interface windows, all that complicated looking code, all the complicated code underneath that code, way way down deep, the computer is really just looking for a series of on and off switches. It's just looking at what's a zero and what's a one.
And that's basically all you need to know here. When we're programming, we're just using human-made languages that work with these on-off switches (also known as transistors). Or you can think of it as passing along the torch to a team of interpreters. Either way, we don't need to concern ourselves with the nitty-gritty, but it's good to know a little of what's going on underneath the hood.
So now it's time to switch back to a human mode of thinking. Even though it might not sound very human at the first read. In fact, it's going to sound wonderfully science-fictiony.
We're going to talk about time complexity.
II. Time Complexity:
What We Talk About When We Talk About Runtime
What is time complexity?
Well, first of all, what is run-time?
We could break down a software program into two stages, just to simplify things: it compiles and it runs.
First, our program compiles. It's loading all the systems in place. You'll especially see this on complex computer programs, such as highly modular computer games, where you not only implement the "vanilla" systems but can also add fan-created modifications to the queue (Skyrim and the Sims come to mind).
In the second half, our program runs. Our program's runtime is simply what happens between when a program opens and when it closes.
But we've all encountered long load screens and lag before. The underlying code of a program needs to be organized in such a way that it's not tasking the computer to run too many things at once and take longer than it needs to.
There's a way computer scientists can talk to each other and analyze each other's programs; how they can figure out how long and complex a program really is; and how to make it more efficient.
It's called time complexity.
And time complexity is actually about algorithms.
An algorithm is a set of rules a computer follows in order to make calculations and solve problems. When a program is running, it is essentially running through multiple algorithms that control the logic of the program.
Time complexity "is a standard way of analyzing and comparing different algorithms. It allows computer scientists to figure out how to improve what's already out there" (Kurt Anderson's words, not mine).
So, when we talk about runtime, we talk about time complexity, and when we talk about time complexity, we're using the standard of computer scientists around the globe: an analyzing algorithm known as Big O Notation.
But first, let's open up algorithms a little bit more. After all, they're the bread and butter of computer science (and thus the bread and butter of game development and all other related fields).
III. Or What's An Algorithm For?
To reiterate, an algorithm is a set of rules a computer follows in order to make calculations and solve problems. It's like a recipe, giving a computer a series of steps to follow to complete a computational task. Wikipedia makes it even more succinct:
logic + control = algorithm
And guess what?
We encounter algorithms all day long.
You know plenty of them already.
Here's some examples you picked up in school:
Here's some examples from everyday life:
Here's some examples of technology using algorithms in the background:
Here's some examples from video games:
And here's the one we're actually going to focus on. We've mentioned it before: Big-O Notation.
But before we talked about Big-O Notation, let's talk about its predecessor, n-Notation. Using caterpillars.
n-Notation looks like this:
and reads like this:
n is a function of n
and if you translated that further, that means:
output is a function of input
Here's an illustration of that, using something less abstract than "n":
When a caterpillar enters a cocoon state, it follows the logic of a caterpillar (in this case, it's "cocoon function"), and the logical output is a moth. However, this moth isn’t a completely new, unrelated factor. The moth is a natural part and extension of the caterpillar. And it’s controlled. Remember, algorithms = logic + control. Even though caterpillars munch on leaves all day long, no amount of logic will turn it into a leaf. In the end, the output must be a function of the caterpillar itself. You could go even further and say this particular caterpillar couldn’t even become a butterfly if it wanted to—because this is a specific caterpillar that will turn into a specific moth. Another caterpillar might become the Monarch butterfly, but that would be a different function. Different caterpillar, different function.
Even though we’re dealing with abstract things like ‘n’ or big numbers or what-have-you, this is the basic logic.
So, caterpillar is a function of caterpillar.
So, n is a function of n.
Here's Kurt Anderson's bold note: "n-notation is NOT an analysis of how long an algorithm will take to run, but an analysis of how the algorithm will scale with more and more input data."
And guess what? We're still not moving on to Big-O Notation.
Nope, in the spirit of Mr. Miyagi, we're going to build up the suspense--but it's all much needed stuff, don't worry.
Continue not to worry, even as I unceremoniously drop our next topic:
IV. Math: A Way of Thinking About...Everything
Yes, computer science is built on math. More accurately, it takes mathematical concepts to explain the reasoning behind computers and their programs.
I'll say this: learning this kind of math has been much more fun and a lot less airy than high school math. We're not talking about train time tables or abstract text book questions--this has real-world applications, and, even if it takes a couple passes, I found it...amusing.
In fact, when you decide to study math on its own, for its own sake, for your sake (and not your academic system's requirements), it's a whole new world. No less difficult, but now it's a welcome challenge rather than a chore. That's been my experience.
Math, and computer science, are really about thinking.
Computational reasoning wasn't invented by computers; it was invented by other human beings.
Computational reasoning is logical reasoning.
And we often don't give math credit for its sexier attributes: its explained hypothetical futures, ended wars, illustrated the shape of space, helped construct magnificent cathedrals, enabled rockets, and organized the entire sum of human knowledge.
And today we only have to cover logarithmic functions.
I'll link more in-depth explanations here and here (this last link goes ahead and explain Big O Notation as well), but I'll quickly try to explain what a logarithmic function is and why it's important by illustrating its opposite:
So, if you've graduated high school, you have at least a cursory knowledge of what exponential is.
4^n can be read as 4 to the power of n.
Which means if n = 2, then 4^2 means 4*4, and therefore 4^2 = 16.
And while not the same equation, just to get a picture, on a graph of x = n^3, it looks like this:
That's an exponential function. We're increasing exponentially.
As stated before, an exponential function is the opposite of a logarithmic function.
Let's do the logarithmic version of the exponential function, x = 4^2. It would look like this:
log₄16 = ?
log(4) of 16 = ?
We can convert this to the exponential:
4^? = 16
4 to the power of what is equal to 16?
Well, 4 to the power of 2!
So another way to refer to logarithmic functions is to call them inverse functions. They are the inverse of exponential functions. Just look at the graphed comparisons between these two types:
They are inverse. They are opposites.
V. Who's Afraid of the Big-O Notation?
Now, the reason why n-Notation and logarithmic functions matter is because they lay the groundwork for our first important algorithm: Big-O Notation.
Q. What does it do?
I like Jeremy Kubica's definition from his book, Computational Fairytales:
"Big-O notation is a method of specifying the worst-case performance of an algorithm as the size of the problem grows. Big-O notation is important for understanding how algorithms scale and for comparing the relative performance of two algorithms."
Q. Why is it called "Big-O Notation", and how is it related to n-Notation?
Look at the chart below:
Big-O Notation is referring to the second notation listed there, the bigger O. (Yes, we can ignore the Greek letters for now).
This chart also notes the relationship that Big-O has to n-Notation. The n-Notation is included right there in the parentheses. Big-O is a function of N. In this case, it's a function that tells us how many operations this algorithm will need to operate to complete the problem at hand.
Q. What does it look like?
The above is a screen capture from this website, which is worth overstudying. Scrolling down the page, you're going to see all sorts of terms, like array and heapsort and insertion, that we're going to see over and over again in our study of computer science and game development.
But we don't need to eat the whole elephant at once.
The last thing we need to think about in regards to Big-O Notation is perhaps the most important.
Q. Why should I care?
We've already established that computer scientists need a way of analyzing an algorithm's efficiency. If we throw, say, 100 elements at it, is it going to take 100 steps for that algorithm to run?
Well, if n = n, then yes. But the larger n is, the less desirable that particular algorithm becomes.
We've already established that Big-O Notation is a way of measuring 'n.' N, in this case, is just our stand-in variable for however many steps a particular algorithm will go through. N steps for N elements. Written in Big-O-ese, that's O(n).
There are two ways to look at Big-O notation: from a mathematical POV and from a computer science POV. We've already tapped the surface of what the mathematical background is (with sizeable gaps, I know, but check out this video here for a better take on the subject), but all we need to know is why computer scientists care about Big-O Notation:
We use it to judge the worst possible outcome so we can devise the best possible solution.
If it's good enough for the pros, it's good enough for us.
VI. The ABCs of How To Begin Thinking Like A Programmer
Andy Harris gave a great speech a few years ago about how to think like a programmer. Or, in his case, how to teach a beginner about programming. The speech is an hour long, so here's the breakdown:
A. Coding is not about the programming language.
B. You can learn one or two dozen languages, but the same basic concepts apply across the board.
C. It's that way of thinking about and combining these concepts to solve problems that constitutes coding.
D. According to Harris, there are only about eight concepts in all of programming:
E. Declaring a variable with appropriate name, type, and value.
F. This is actually an algorithm, too. Remember, an algorithm is a recipe. Here's what the above is saying to the computer: "Create a variable called Name, of type Type, that starts with the value InitialValue."
G. Output. Telling the user stuff. print ("Hello World") and the computer will print "Hello World" to the console.
H. Input. Asking the user for input before you give them output.
I. Convert to integer. Take something that's not an integer (A.K.A. any number positive, negative, or zero) and make it into an integer. Perhaps taking a float number (3.14) and converting it.
J. For loop. (This and while loop is best saved for an in-depth discussion at a later date).
K. While loop. (Ditto).
L. Debugging. A.K.A. Why is this broken?
M. So the #1 skill we are after is so obvious it hurts: problem solving.
N. In Harris' own words, "The secret isn't code, it's algorithms and data."
O. Further, "If you're lost in coding, it probably means you shouldn't be coding yet." (I.E., learn how to think first)
P. Comments aren't there to explain the code to other programmers; code is there to explain the comments.
Q. We're all beginners.
R. Best Practice: Write an algorithm in plain English before you start coding.
S. Failure is WONDERFUL.
T. Begin debugging now.
U. Of course, the best way to debug is to not have bugs.
V. "Bad implementation can be Googled, bad algorithms cannot."
W. "Don't start with the solution; start by truly understanding the problem."
X. "Nothing is messier than game code...you don't write it to be maintained, you write it to be fast."
Y. It will all happen in good time.
Z. And finally, his recommendation for what to learn after you're comfortable thinking computationally:
VII. Congratulations, You Made It To The Summary!
Happy New Year Everyone!
In Excelsis Deo.
Unfinished creativity is living with a cloud over your head.
Why You Can And Should Pursue More Than One Passion
I ran into a bit of a funk this past week. Bit of an expected funk—you’re a few steps into your journey, and you know this is unpaved road so you’re expecting a few bumps. But expecting and experiencing are two different hings. What is this feeling of having left something undone, even as you’re in the middle of getting stuff done?
For anybody who has stopped and started multiple projects, you’ll know the feeling.
For anybody who has ever felt passionately about more than one thing (and who hasn’t?), you’ll know the feeling.
So I was in the middle of my first practicum assignment for my Ultralearning project, when I kept running into a Block. We talk about writer’s Block, about the general creative Block, and we argue about the Block—does it exist, is it just laziness, or amateur hour, or an excuse?
Well, it’s certainly a hurdle. And if you haven’t trained for hurdles, you end up with halted progress and at least one bruise.
So there I was, vision suddenly clouded, ego bruised, frustrated at my inability to keep my fingers on the keyboard. My eyes felt clammy, my chest cold, utterly dissatisfied with whatever progress I slogged through. Even switching to a video game for a little while, even closing my eyes for five minutes, even having dinner, even restlessly organizing my wallet, taking the dog out, placing a phone call—absolutely nothing could shake this feeling that something was wrong, life was blue, creativity was lonely. Something was missing.
Like almost all epiphanies, it shone a light while I was tossing and turning that night:
I was stifling my instinct to write.
Whoah! I just started a super ambitious project. I needed to be focused, clear, get to Cal Newport’s lauded “deep work” state. I couldn’t go traipsing off again, spending an afternoon working on a short story, to only haphazardly switch back to coding the following day, then back again, never reaching a milestone in either pursuit. Right?
And besides, didn’t writing this blog count? What about journaling? What about just writing again in the future?
But it wasn’t so much the act of writing that was missing. It was the finished product. All my life I’d chosen one clear vocation: I was a writer, I was going to be a writer, my writing was going to be read. And here I was, pursuing a new goal, not necessarily giving up the old goal, and the ghost of what-was-not wouldn’t unhaunt me.
(It really does feel like that—like you’re being haunted. Maybe just the silly bed sheet variety; which is why thoughts of clarity often arrive under the comfort of a blanket).
How could I pursue this new undertaking when I hadn’t kept other promises to myself? When I had very little psychological foundation, the small wins, that I could rest on, look back on, take inspiration from? It was like going straight into a triathlon without the muscles, or with the scantest training possible.
What I’m trying to say is: can’t do one without the other. I have to produce writing and I have to produce progress in game development.
That’s what I set to find out this past week.
Pursuing More Than One Passion: The Triathlon Approach
I started thinking about triathletes. They pursued more than one sport and then combined everything into one super project, one super test: the triathlon. Swimming, biking, running. Sure, you can lump them all under “sports,” “competition,” “endurance,” but if you ever compare a pure runner to a pure swimmer you’ll notice pretty big differences between their physiques, schedules, even their temperaments. And there’s a special amalgamation when it comes to triathletes. They’re like Renaissance Athletes.
So, if we can learn from any group on how to pursue more than one passion, we have at least two models to pick and choose from.
Renaissance men, like Leonardo Da Vinci, show us clear examples of pursuing multiple passions, often to the point of mastery. My two projects—game development (which is already a combo of several sub-fields, from coding to art) and creative writing—are decidedly creatively bent passions.
So Renaissance men, OK, yeah, that’s a given. But what can athletes teach artists? Athletes train themselves in procedures, in muscle memory, for physical activity—that’s completely different from the more conceptual skills like those involved in programming and story development.
But there had to be overlapping principles—bottom lines of success, universal rules. So I set out to find them.
When triathletes sign up for a triathlon, they don’t immediately set out the following day and attempt a mock triathlon.
They break down their tasks, apply it to a schedule, and do things one day at a time.
And then when they get to completing those daily tasks, they condition their bodies by starting with where they’re at and not (immediately) where they’d like to be. Conditioning.
What does conditioning look like for an artist? I can’t speak for everyone—some of you may be here because you’re interested in what I find works for writing and some may only be interested in the game dev side of that. But let’s take one extreme example, for writing this time. Ray Bradbury once gave this advice to beginning writers: write one story a week. His logic? It’s nearly impossible to write 52 bad stories in the course of a year.
That is an example of a condition to meet—an exercise schedule, if you would. You write throughout the week and finish one story by the end. Rinse and repeat the following week, etc.
Now, add to that another passion that we want to pursue. In my case, it’s computer science (with an emphasis on game development).
The toughest part here may simply be sticking to a schedule for pursuing these passions. I’ve been guilty of writing up a schedule that slots me to focus on programming for two hours in the morning followed by two hours of writing later in the day. But then I wake up in the morning and I’m in the mood for writing instead. And the whole day turns into an attempt at writing, because I want to “take advantage” of my inspiration. So that creates a pattern of unreliable scheduling and chasing the muse.
How could I condition myself to work on an isolated subject at one time and another subject later? And do this every day, regardless of the inspiration or lack of external pressure to continue doing so?
An athlete breaks down their muscles into groups, and exactly which days they will be worked on and which days they will be allowed to rest. Can the same be applied to mental exertion as does physical exertion? I think so. But I wanted something concrete. The danger with conceptual activities is that it’s easy for everything to remain a concept. So many “how-tos” for artists and writers on the internet are usually filled with generic advice rather than concrete guidelines. “Follow your passion,” “put butt in seat,” “set a word count goal,” “learn by doing.” How does one do?
I thought about it. I read about it. And here’s what I came up with.
Here are the areas that artists of all stripes can condition:
A) Focus: “The ability to make timely progress on cognitively demanding tasks and produce more results in less time.”
Case in Point: Stephen King writes 2,000 words every morning. On a bad day, it might spill into the afternoon, but he’s honed his schedule and craft to a point where he usually meets his daily goal before lunch. Cal Newport, author of Deep Work, came to this conclusion: "Three to four hours of continuous, undisturbed deep work each day is all that it takes to see a transformational change in our productivity and our lives."
How To Practice:
Game Development - If you don't currently have a project you're working on, or continually find yourself more in Google/blank stare mode, you're not getting a Get Out of Jail Free card. Instead, you can always find time to hone your ability to code and code at length by completing code challenges, on sites such as CoderByte, Codewars, Codefights, or Codingame. (Reviews of these forthcoming).
Writing - Ah, this one is so simple it hurts. And, unfortunately, there's no guaranteed results. Flannery O'Connor, for instance, would do this every day for two hours, and some days she said she didn't get out a word. And that's what this suggestion is: settle down for an allotted time each day with the intention to write. You may not actually get anything good--but the important part is to sit down the whole time and deal with whatever pops up, whether than be genius, drivel, boredom, or the flow state.
B) Intuition: “Solve any problem by finding the underlying pattern, not fiddling with the particulars."
Case in Point: Swiss educational reformer (and one of Albert Einstein's early influences), Johann Heinrich Pestalozzi once said, “Visual understanding is the essential and only true means of teaching how to judge things correctly." Basically, thinking in images is preferential to thinking in words or numbers. We first learn through images and sensations, only later learning symbols for these things--the written word, the Arabic numerals.
One common factor among geniuses, from Albert Einstein to Richard P. Feynman, wasn't that they were memory machines, human calculators, or mysterious magicians. They developed their intuitive senses. Yes, it's something they were born with. But we're all born with intuition, and we all can choose to practice our intuition.
How To Practice:
Game Development - There's a popular term in coding that comes straight from science fiction: Robert A. Heinlein's "grok." Transported from Heinlein's novel to the Oxford English dictionary, to grok is to "understand intuitively or by empathy, to establish rapport with, to enjoy with".
Well, there's actually quite a few programming/computer science books centered around the idea of "grokking" subjects, such as algorithms and the like. And they do so through pictures and real world examples. I suggest starting with Grokking Algorithms--it's even available in an audible version (which I have--and I'll tell you if it's worth it without the pictures).
Writing - Writing itself is an intuitive process, but what better way to hone your intuition than absorbing the work of countless artists before us? It is easier to write stories when you're in the habit of digesting them. Read outside your genre or preferred medium--try plays and poetry, science fiction and literary. Try telling your stories through images--or, better yet, illustrate them outright. Read your stories out loud, not just in your head. Write backwards. Do anything to flip the script and think from a different angle. It might feel like a lot of sideways fuss when you'd rather be plowing a path straight to the end of a particular project, but the whole point of conditioning is starting with where you're at (and we've got some weaknesses to work on, y'all) and working deep, before we're able to execute quickly and intuitively at a later date. This is time well spent.
C) Overworking the Problem: “Practice something more than necessary and it’ll stick around for good.”
Case in Point: Students who take higher-level math courses score better in lower-level math refresher courses because the higher-level courses force them to use lower-level concepts to a point that goes beyond earning a grade or getting the gist. They have to know how it applies in more than just isolated situations, but how the concept of them builds into more complex problems.
How To Practice:
Game Development - Choose a difficult concept. Watch the same video, read the same paragraph every day for X time. Keep watching/reading every day, even if you feel like you understand it. Build the same project over and over if you have to. Do something often enough till you're sick of it.
Writing - This one applies to your editing process, usually reserved for the very end of a project, but BOY IS IT GOOD. When you finish a story, take out a fresh page and start re-writing it. You can go word for word if you want, but you'll often find yourself intuitively editing as you go along. But you're in the mechanical flow of writing as well, so you're working at multiple levels. You're not limited to your own stories either. Practice by copying established short stories, pretend you're role playing as George R.R. Martin or Jane Austen. Whatever. It's a psychological release as well as a practical exercise, and you'll be surprised by what you learn.
D) Memorizing Core Patterns: “Roses are red, violets are blue, certain things are a given, cite the facts and you’re through.”
Case in Point: Some things you just gotta know. The trick is to filter out what's fluff and keep what's essential. Richard P. Feynman memorized basic logarithmic calculations to make seemingly impossible calculations in ten seconds or less. He didn't actually calculate that fast; he just memorized more laborious outcomes to simplify future problems. It's like memorizing multiplication tables, or mnemonic songs that help you get through the periodic table, or the simple fact that Kyoto is the capitol of Japan.
How To Practice:
Game Development - Algorithms. Data Structures. Conditionals. Design Patterns. Exposure, exposure, exposure. This one is just going to take time.
Writing - Yes, that dreaded word: analyze. Actually, I used to hate writing exercises, isolated paragraphs and dialogue exercises and half-full notebooks. Ugh. I just wanted to write what was already in my head. But when you come to enough dead-ends and head-scratchers, you start wishing for just about anything that will keep you keep writing and start to demystify why you struggle in some areas when you're doing so strongly in others. And sometimes that means not writing at all, or doing one of those dreaded writing exercises. This is a writing exercise that doesn't involve writing: analyzing your favorite short stories (you could attempt novels, but you might be here longer).
Break down your favorite short stories into the Hero’s Journey, use word count to find out how long each section is before breaking, cite any specific authorial flourishes (Catherynne M. Valente’s weirdpunk terminology, Hemingway’s bare prose and lack of background story, Lovecraft’s use of mannered verbosity broken up by alien mania, Diana Wynne Jones’ chatty style over top structures dense in magical systems and literary allusions, how C.S. Lewis wrote for children vs. how he wrote for adults, etc). Do this for at least one story.
II. Overlapping and Tangential Skills
Now let’s get into the nitty-gritty of how and what we’ll do when pursuing more than one passion project--pursue, not dabble. We’re not finger painting on Saturdays and writing an essay here and there. We want to make masterful progress in more than one discipline, and we want to be smart about it.
The reality is—we only have so much time in a day, and large chunks of that are occupied by commuting, sleeping, eating, socializing, working. When we only have small chunks of time, how can we make that time count, especially when we’re tracking more than one subject of interest?
I experienced some lull during work on Friday when I came up with some small things I could reasonably perform when I wasn’t needed at another task and waiting on customers. Using scrap pieces of paper, I started working on puzzles designed to help sharpen my problem-solving skills. In V. Anton Spraul’s Think Like A Programmer, he dedicates the first two chapters to riddles and conceptual puzzles. It’s not enough to be able to figure out certain set problems and textbook exercises, or to copy and paste common coding solutions--you'll be smarter in the long run if you build the mental habits that allow you to break down “puzzles” and put them in order.
Problem-solving, in the form of riddles and puzzles, is an example of a tangential skill. In this case, it specifically applies to my aim of being able to program the ideas I have in my head. Tangential refers to something that is slightly connected to the main topic of interest. Coming up with the correct answer to the Sphinx riddle didn’t make Oedipus a programmer, for example, but an aspiring programmer working through different kinds of problems—those posed by the Sphinx, by a chess board, by a Sudoku puzzle—are practicing the same mental muscles needed when programming new solutions, in addition to teaching their brains patterns of logic. It can’t replace actual coding, but when coding is a no-go, it certainly doesn’t hurt.
Now, overlapping skills. These are the skills that apply to more than one area of study. What are the overlapping skills one can practice if they want to become a better programmer/game developer/creative writer?
Triathletes are working on tangential and overlapping skills all the time. Bicycling strengthens their leg muscles, which helps them endure longer swims, which strengthens their lungs, which helps with the whole running bit, etc., etc.
But what about our subjects?
Well, working on a short story has very little impact on my finishing a coding project. Unfortunately, I cannot reasonably complete both at once. This is precisely what I struggled with this past week.
However, a small win in one category provides confidence in another.
Writing, in general, is a skill promoted to top-tier importance in almost any field you are looking into. A film director said that once--forget the camera and the acting connections, just write a dozen screenplays. If I could quote the guy, I would.
And you know what skill you can't teach a computer? How to write like a human being.
But, to be more concrete, I came up with the following lists below (please feel free to comment with more--I could always use fresh ideas):
III. Small Wins
We touched on "small wins" a few paragraphs ago. I was watching Joyce Carol Oates' Masterclass on short fiction writing when she talked about the importance of writers working on short fiction--because completing something (and short stories are easier to complete than novels) gives a "very necessary psychological boost" to a writer. Hey, completing writing for the day feels great, but completing an entire complex idea, a short story, is even better.
Again, we can find examples of this in the world of sports. Athletes train to beat their own records--it's not the same as racing or even winning the triathlon, but it's a smaller goal that they set out to complete on the journey to the bigger goal.
It's not enough to just have one big goal. Along the way, we need to set realistically small goals so we can realistically attain small wins. It's those boosts of glucose we need to keep running the good race.
IV. Exhaustion and Rest
Working a muscle to exhaustion is the first step in strengthening it in the long run. And the second step is to rest it.
We talked earlier about overworking problems to get the concept behind it at an instinctual level. Renowned physicist Richard P. Feynman created a natural intuition for physics and problem-solving by doing more work than was expected of him at almost any given math problem. Essentially, he went through the act of "discovering" and "inventing" the solution to the problem rather than relying solely on existing solutions and common proofs. This took longer, but the results lasted pretty much forever.
Though failures and setbacks often feel more annoying than rewarding, it's when I've failed to get a piece of code to work or a story to launch that I learned the most about the process behind it. Don't get me wrong, I still yearn for shortcuts--when you've got a lot of interesting problems and ideas queued up, you're impatient to get started on them all. But slowly I've learned that going deep on initial problems builds up a library that is in increasingly easy access.
For example, most of us are pretty good at typing because we use computers all day long; back in the day, only typists could claim such exclusionary value. Typing is an example of a "problem" we've overworked.
Children are also naturals at overworking problems. They'll ask a million questions on one subject that we long ago tucked away as "obvious," so we no longer think deeply about it. The first five years of our life, however, are an example of extraordinary cognitive expansion. And it just comes from relentlessly observing and asking questions and tracking down answers.
Above I've already listed a few ways to overwork some problems within game development and writing; we can start there. Add to this an exhaustive write-up of all the questions you want to ask. The more curious we are, the more motivated we are to get to the bottom of things.
The Perfect Plan vs. The Actual Execution
There’s actually a pretty strong scientific case to only master one thing at a time. More accurately, to build one new habit at a time.
There’s a lot of conscious effort at the beginning. Already facing down old habits, resistance, time changes.
In light of this, I think it’s just as important to learn how to mentally deal with failure.
Here are four principles:
1. You Still Have One PRIMARY Pursuit (RE: You Will Make More Progress In One Area Than Another)
Don't think of perfect percentages or a neatly sliced pie. The reality is you can't parcel out your time evenly, and in order to feel any real sense of progress you're going to have to prioritize. There's only room for one at the top. For me, I'm not sure if that will be writing or game development right now. Game development has the most room to grow and go, but the small wins are found within writing, as it's a skill I already possess and the resources needed are extremely simple: pen and paper or a simple word processor will do. Figure this out organically.
2. Focus On The Three Most Important Tasks (Day, Week, Month Editions)
Don't kill yourself with an ambitious to-do list. Every day, give yourself the Top 3 Tasks. Anything beyond them is a bonus. This can be extended to the week and the month, saving you precious mental space to focus on the tasks at hand instead of constantly bringing back up a list of disparate errands to remember and evaluate.
3. Don’t Hold Yourself To Hardcore Deadlines Till You’re Halfway Through
Reiterating this point from Blog #4. This is productivity guru Scott Young's advice--when you start a difficult project, don't hold yourself to any deadlines till you're 1/3 to 1/2 way through. Because it's nearly impossible to set realistic goals when you're still a novice.
4. Any Progress Is Still Progress
Fr. Mike Schmitz has a great video about dealing with setbacks and going off your chosen path, and much of the advice is universal--particularly his point about any resistance to a bad habit and an effort in a good habit counting toward the end goal. You're on a diet and you waited two hours before eating a donut? Most people assume they are diet failures at this point; Fr. Mike's point is that those two hours of resisting made you stronger for the next go-around. So don't underestimate the fact that you are facing numerous battles and may not win them all--not only are you battling to understand, you are battling to get your butt into seat, you are battling to get out of bed, you are battling to read just one more word, or concentrate for one more minute. And all of these efforts count, even if you don't hit your goal. Any progress is still progress.
1. Make A Simple Visual UI in Visual Studio
1. Write 3 morning pages every morning
2. Break down three short stories, each from different authors, and compare them, using the writing example above under “Memorize Core Patterns.”
Bonus: Take one of the stories you picked to analyze and copy it word for word. Enjoy the process of getting inside the words and watching the story literally build before your eyes.
In Excelsis Deo.
“It is possible to become world-class in just about anything in six months or less. Armed with the right framework, you can seemingly perform miracles, whether with Spanish, swimming, or anything in between.” - Timothy Ferriss
What’s the most efficient way to learn game development?
How can I make my designs concrete?
Well, game dev definitely has something to do with coding, my younger self concluded.
So I, a non-coder, set out to learn coding.
And I got it—kinda. Enough to know some basic syntax stuff. It’d be the equivalent of knowing all your high school French vocab, buuuuuttt…not knowing how to string a sentence together.
It’s a weird plateau—where do you go from there? Any student who has studied a foreign language (and any programming language you pick up is just that, a foreign language) has faced this problem. They know enough to be dangerous, but not enough to communicate what they want to communicate.
So I recently cracked open Timothy Ferriss’ Four-Hour Chef, and, yes, it’s going to help us learn coding. It’s designed to help you learn anything—as efficiently and effectively as possible.
Without getting lost in the weeds, I’ll just bring out the most important concept from Ferriss’ book (though I highly recommend you check it out—it’s packed with meta-learning tips and practical know-how; everything from braising steak to memorizing Japanese kanji to building a fire with a bow drill).
But Ferriss boiled his master plan for how-to-learn-anything into two succinct acronyms: DiSSS and CaFE.
So below you’ll find out what those letters stand for, and I’ll attempt to answer them with a bent towards game development.
I’ll write another blog post on how I came to the decision to learn C# for game programming, but most of what you’ll see below is language-agnostic.
Our real question here is: how can we get a programming language to deliver our game design ideas?
DiSSS (Deconstruction, Selection, Sequencing, Stakes)
Q. “De-construct what you’re learning. What are the minimal learnable units, the LEGO blocks, you should be starting with?”
A. I’m going to answer this question broadly. What broadly applies to any game engine, programming language, or video game genre. And I’ve boiled it down to this:
For any programming language: Strings, Variables, Methods, Conditionals, Loops, Operators, Assignment, Arrays, Passing Arguments, Objects, Classes, Recursion
For the basic architecture of a game: Game Loop (Input processing, updating the game world, outputs), Delta Time, Game Objects (Draw, Update, Draw+Update)
What the pros are trying to get better at: Algorithms, Git
Q. “Which 20% of the blocks should you focus on for 80% or more of the outcome you want?”
A. The question is referring to the Pareto Principle: "80% of effects come from 20% of causes and 80% of results come from 20% of effort."
Suffice it to say, I really puzzled over the answer to this question. It seems like the pieces of code you should understand vary by project. Coding is more like writing or painting than it is like weigh lifting, cooking, or tango: coding is very creative, and there are multiple solutions to similar problems.
So I decided to go about it like C# really is a foreign language (which, as we established before, it technically is).
In Ferriss’ book, he has a little section on learning foreign languages quickly: learn the most frequently used words and learn those FIRST.
So I create a very incomplete graphic that goes over the basic idea of game architecture (how games are set up), and some of the more specific C# concepts that would be useful to know (outside of what basic tutorials normally cover, such as what a string, variable, and array are).
Yes, yes, the shapes mean nothing, the colors are arbitrary, there's a lot missing, it's far from a complete cheat sheet.
BUT--it does give us a jumping off point, with an overall glimpse at how games are organized (before they start looking like Rosetta Stones of incomprehensible text), and gives us a road map for concepts we should study, rather than going by the very vague: "master C# programming and game architecture."
Q. “In what order should I learn the blocks?”
A. In all my Quora spelunking for this blog post, I actually came across a perfect guide—you’ll see me follow it here on site. So let’s all thank Al Nelson in advance:
Al Nelson's advice is like a warm-up for game engines (Unity, Unreal, MonoGame), which I love. We're going back to the basics and working, not on tutorials, but on prototypes. I'll be going through this road map over the next few blogs. Our 'little adventure game' will be created in Twine, as I work on a little project you may have seen listed under My Work: "Imbue."
After that, we can go over those algorithms and key words in depth.
Q. “How do I set up stakes to create real consequences and guarantee I follow the program?”
A. This blog is my stake. It’s got my name on it. I paid for the domain. I’m going to publish underneath this thing. That’s quite a bit of weight! You might consider something similar.
BUT…if things should slide way off track, Ferriss recommends betting a bunch of money on you failing, so you’re motivated, at the very least, to not lose the $500 you promised to shell out if you failed your goal. Aversion psychology.
CaFE (Compression, Frequency, Encoding)
Q. “Can I encapsulate the most important 20% into an easily graspable one-pager?”
A. Why, yes I can (try). See the above infographics above.
Q. “How frequently should I practice? Can I cram, and what should my schedule look like? What growing pains can I predict? What is the minimum effective dose (MED) for volume?”
A. I read recently in Josh Kemp's "No Degree? No Problem!: How To Become A Software Developer in 8 Months" that the sweet spot is around 3-4 hours per day for 6-8 months. And no, blogging doesn't count. Regardless, we'll keep track of the results here on this site. Of course we're going for game developer rather than software engineer/developer, but the basic overlap is learning a programming language and turning out prototypes.
MED: 3-4 hours a day.
Growing Pains: Gotta resist chasing multiple rainbows.
Q. “How do I anchor the new material to what I already know for rapid recall? (Acronyms like DiSSS and CaFE are examples of encoding).”
A. Weekly updates here on the blog, summarizing what I’ve learned, with occasional tutorials.
And that's all she wrote. Next time we'll start looking at some actual code (and eventually we'll put this blog on a schedule, but let's just take Al Nelson's advice and go one step at a time).
Thanks for tuning in!
In Excelsis Deo.
What follows is all the things this author has failed at.
I feel cheery as I type this. Like getting ready for a tall glass of cold water after a hot, muggy, impossible day. Like a nice rinse on top of it. Getting cleaned up, clothed, rested, before putting on brightness and warmth and trying again, more humanly this time, until we need to take a glass of water and rinse off all the non-human stuff again. Non-human stuff. Bitterness, polemic, sarcasm, curses, regret.
The rite-of-passage for children becoming adults is, increasingly, no longer a valid driver’s license or a road trip or a hair on your chest—it’s nodding sagely at the notion that “we’re only human after all.”
Only human—as though joy or satisfaction or a small job done well were not the most human things.
So that’s why we’re admitting our failures right now. To stop identifying with the failures. We’ll end up admitting them again. I want to rinse this stuff off and try again. And not have any baggage when it’s time to learn something new.
Failing upward—I like succinct phrases like that. But here’s more a mouthful, more a fine broth that gets better the more you let it settle and simmer:
Jakoś to będzie.
Yakosh toe benjay.
That’s Polish for (essentially): “Act, without worry, for it will all work out in the end.”
An active (act without worry) and a passive (it will all work out) promise. Works and Faith.
Let’s start again, listing times we’ve acted and failed, because we’re going to act again. Without worry. For it will all work out in the end.
Here’s the Author’s personal professional failures. The reason for listing these isn’t to throw a sad Internet party. Like I said before, this is all about the cleansing effect. There’s another word for that, a Greek word: catharsis. Catharsis is the “cleansing and purging of the emotions.” It’s that feeling of your feelings being in order after watching a good drama or laughing with friends.
Of course, stories do catharsis best. That’s what stories are for. So I hope you find some hope from my story.
The formula is: A) list a failure, B) list a rewrite of that failure, C) try and do the same with yours, D) list your small and big wins too.
1. Wrote three uneven novel manuscripts, started but never finished dozens of short stories, and the only thing I’ve submitted and had published were two poems.
Rewrite: Finished three novel manuscripts, actually finished two or three short stories and learned lots of writing practice from the rest, decided that I wanted better for myself so now I’m pushing toward a deadline for a short story contest at the end of this year, and hey! Someone actually published my writing.
2. Started learning coding on Udemy and then stopped. Twice. In fact, I’ll link the course. Each time I keep stopping on the choose-your-own-adventure section, because I’m a perfectionist and I want to create a story that I can show off (on this website).
Rewrite: Nothing is stopping me from finishing that Udemy course. And it’s what got me started on this game dev journey in the first place. Without it, I might not have tried to self-teach myself at all.
3. Tendency to pick up hobby for a number of weeks and get through 2/3 of a course or a book and then stop for a few months, in pursuit of another hobby I left off a few months before that, leaving gaps in learning and feeling like a perpetual intermediate beginner.
Rewrite: I’ve now started a blog where I have a lot less leg room to go traipsing off into the woods, and, if I do go off the beaten path, I can document what I learned here and have a bread crumb trail back to the main path when that particular jaunt is done. I’ve created a new paradigm to get stuff done in. And though I’m ready to learn things in a faster, more organized, thorough manner, at least what I’ve learned so far is still there, a thin foundation, a few steps closer than I was before I started any of this haphazard learning. And learning is learning is learning.
4. Quit my day job, had a plan, tweaked the plan, forgot the plan, still don’t know what I’m doing.
Rewrite: Got a new job that’ll let me meet new people and still leave me time to write and learn. Adopting a new mindset: jakoś to będzie. Will be honest about my mistakes. Don’t see myself staying in a slump. Patience.
5. Moodiness. Inconsistency. Not walking the talk.
Rewrite: I know what I work on. Consistency is all about right now, day-by-day. I’m walking the walk right now. And when I’m moody, I can always listen to “Fresh” by Kool & the Gang.
That list could be longer, but it doesn’t have to be. That’s the sum of my main mistakes, and I’m sure yours fall in the same types of categories. Not my categories, but your particular habitual categories. Maybe you struggle more with workaholism, or not taking yourself seriously, or you simply don’t have the time to pursue your dreams right now, because you’ve got people to take care of, and it’s going to take some time to work things out.
Jakoś to będzie. Jakoś to będzie. It will all work out in the end.
In Excelsis Deo.
What It Feels Like To Get Off Track/Fall Off The Wagon/Sail Alone
Start. Stop. Cold feet. 30 Day Challenges with only 19, 10, 7, 3, 2 days marked off the calendar. Good intentions, meet Bad Indigestion. And a gremlin that comes out of nowhere and insists that your optimism was all a sham and you’ve always been a pessimist, come join the dark side, we have cookies that will make you feel temporarily better and incrementally worse. Wanting to change your writing style, your lifestyle approach, your mentors, your outlook, your plan of action. Stopping because this makes you feel dumb, bored, insecure, cold, lonely. Stopping because maybe you’re enjoying this TOO much, getting TOO far ahead. Fear of success? You’d heard of it once and thought it ludicrous. But now you know what it means.
Oh, hello there.
This is the entry for all you Eternal Beginners out there.
Does this sound familiar? You’ve got a goal. It lines up with your core values, your dreams, who you are. You’ve got the time, the money, the interest, the resources. You’re learning coding, or drawing, or a foreign language. You pay for lessons, download an app, order a book, brush up on concepts you’ve learned before. You remind yourself of past successes—the early morning appointments you’ve kept, the awards and recognition, the promises kept, the right characteristics, the right intentions.
And it’s working. You’ve put in Day 1. Smashed Day 2. Humped through Day 3. Had a flash of inspiration on Day 4. Told your family breathlessly on Day 5. Took a mini-break on Day 6. Felt refreshed and got twice as much done on Day 7. And the wheels fell off on Day 8.
This is the entry for all of you who’ve rode a Goal Wagon with the wheels falling off.
This sucks! You don’t have time to fix this wheel, you’re supposed to be plowing ahead! That seven-day race toward that already distant goal? Feels like a waste now, stuck here in the mud, not even sure how to put the wheel back on, since you don’t know how it came off in the first place.
This could be a challenging test or quiz or project you’ve gotten to, a milestone, that supposedly tests all you’ve learned so far, but you swear you’ve never learned ANY of this. How are you supposed to put two and two together when they’ve thrown in an elephant?
And then it starts raining. You know, you’ve got the Storm Clouds. The Blues. And you watch the clear track of progress get all muddied, first by the rain, and now, it’s all muddled in your mind’s eye, behind that curtain of tears. Tears of frustration or anger or remorse—c’mon, we all cry on the inside, even if we don’t always cry on the outside. And nothing can bring on those particular tears quite like watching ourselves get further and further off course. The track gets lost in the mud. We stumble forward but the wagon doesn’t ride as smooth as it used to (you know something is still missing, that the best you could do was a patch job and that little thing you don’t understand grates on you every time you hit a new bump in the road and the wheel threatens to roll away yet again). And what’s worse, the path before you is no longer so clearly delineated, and the path behind you is getting harder and harder to remember.
Has it really only been two weeks since you started this crazy journey?
Besides, look at all those pioneers over there. They hardly ever lose the wheels on their wagon, and if they do, they know all the buzz words that can get them out. And they have connections. To experts. In fact, they’re not hobbying it up like you do; they’re professionals. They get bit? They suck out the poison. They lose their way? They draw up a new map. They stumble into a trouble area? They call in a knowledgeable buddy. And you feel alone. And foolish. And cowardly. Because you’re ready to pack it in. Maybe you’ll get back to it in a couple months. Maybe a couple years. Maybe, maybe, you’re ashamed of that word, so you keep it hidden like a middle name. But having Maybe as a middle name is even worse. It’s always there, taunting you, a part of your identity you can’t shake. A middle name like Gaylord or Dorcas. You’ve made it a part of you now. You’ve made it a part of your name. I’m so-and-so, the quitter, the maybe, the wannabe, the hobbyist, the some-gotta-win-and-some-gotta-lose-so-I-guess-I’m-the-loser. You think if there’s a place in this current society for you, it’s Anti-Hustler. You don’t have the sweat equity, kid.
This is the entry for all you Anti-Hustlers out there.
First, A Bit About Me (Then A Bit More About You)
As an American, I'm a big fan of the American Ethos: Work Hard, Work Smart, Wear Your Heart On Your Sleeve (But If You Have To Cry, Cry Into Your Pillow At Night Gosh Demmit).
There's no irony there. I think I'm being truthful. That's the American Work Ethos as I understand it.
And I lived by it for the first twenty years of my life. Then something caved in around that time. Sordid details? None really, and besides, we're not here to be down together. We're here to stand up together.
And whether you're visiting this plot of internet country from an American or an Estonian server, there's a current in modern culture we're all familiar with right now: the Hustle Culture.
But, my friends, if you've read this far, you're wondering what the heck I mean by Anti-Hustler.
And what this blog is going to be about.
To be an Anti-Hustler is to embody this adage:
"Dance to the beat of your own drummer."
Do you feel like you don't have what it takes because you've never gone "full tilt" on your dream? You didn't quit your day job (OK, I did that, but there's a Failing Upward blog you should check out that illustrate how that doesn't necessarily mean insta-results or insta-pride or insta-satisfaction...), you didn't go back to school, you didn't even finish the YouTube tutorial you started. So you start hearing this, on the internet, from frustrated family members, from your monkey mind:
1. "You just don't want it bad enough then."
2. "If you hate your job, just quit. Who cares what people think? Do what you love, what you want!"
The author has personally said these things, or nodded her head from time to time. Not just to herself. To others. To friends (I've got an apology planned this weekend).
Dear Reader, I'm going to start this pilgrimage of penance by NOT saying any of these things to you.
Because we aren't hustlers. We're more like pioneers--this is wild country for us (for me, it's about writing and coding and where those two overlap), and we're going to take our time and work hard because we want to make a life here.
What These Scribbles Are For
This site is an author's website. But this author is not just a pioneer, she's an apprentice. There are lots of experts talking about the topics I'm going to talk about. And I've got my own small pockets of expertise to share.
But this is also a site about the Beginner's Journey: putting down stakes, making claims, small wins.
Eternal Beginners. Eternal Pioneers.
Or finishing a short story--and sending it out for publication.
Or just getting your email set up to your website, because I'm still not sure I'm doing it right.
If there are stops and starts on Day 8, at least they'll be documented.
That's what these Scribbles will be about, in a nutshell.
To start this off, they'll be a nice daily burst here at the beginning, followed by more scheduled updates on Mondays and Saturdays at 11 a.m.
We'll learn it together.
In Excelsis Deo.
NOTE: To improve my pixel art, I've decided to do the terribly ambitious thing of creating a custom pixel piece for each blog entry (or in this case reshading one I'd already done). DOUBLE NOTE: For the sake of sanity, they may be small, but I'll at least try to make them relevant.
K.W. writes novels, short stories, the occasional ode, game scripts, and (with actual evidence!), this here blog.