We want to do innovative things.

In our casual conversations and social media, we excitedly bring up the latest product that another studio just released. It’s their magnum opus, a brilliant convergence of ideas helped along by famous developers and an ingenious design. We may compare it to our loftiest goals with a tinge of vicarious excitement or envy.

We get swept up in this dream as we sit at my desk with creativity and ideas bouncing through our minds.

But then reality strikes. The day quickly fills with obstacles and roadblocks.

You're searching for a game job.

Your first one? Pivoting from a different industry? Seeking a healthier work-life balance? A better salary? A challenge?

You need to do job research. Everyone needs to do job research.

I wish more beginners to game development understood the incredible momentum that they can build from small projects.

When I ramp up inexperienced programmers, my goal is to give them tasks that are small and challenging enough for them to make many small mistakes.

As they gain experience, I want them to work on larger and more challenging features, and have them use the experience around their mistakes to mitigate the impact of larger pitfalls.

Six months ago, I was a beginner level in Japanese. Today, I still am a beginner, despite all this work. The obvious question is, why focus on kanji before other things? Learning so many characters is not immediately useful, and furthermore it’s well known that without practical, repeated use words are easily forgotten, leading you back to square one!

Well, first off, kanji was a big personal hurdle for me. Playing a game or reading an article, I would almost immediately be stopped in my tracks. Unable to comprehend I’d be jumping into a dictionary constantly, only to forget what I learned by the next day.

I was intrigued upon finding that many self-studiers used a specific, mnemonic-based approach, optimized for adults, to learn the kanji much more quickly than even native Japanese speakers did as children. Could I make my future learning easier by getting over my biggest obstacle first?

I place a big value on personal improvement. Software engineering isn't just about making better tools, processes, and organizations. Those things are important, but at the end of the day nothing works right without talented people, and we as engineers have the responsibility to improve ourselves.

I'm not artistic.

I was never a science person.

I just can't listen long enough to learn.

I wasn't born with drawing skills.

These are negative identities. Things we are not. Many at their core rely on the dichotomy of natural versus learned abilities. The framing of almost anything we discuss related to talent has the assumption built in that some of what you are capable of is tied to your genetic code, locked in the vault of your chemical makeup, and other parts can be improved through study, practice, repetition, or enlightenment.

The first time I really thought about conventions was about a year into my first programming job. I had a coworker and good friend, Victor, who was looking into our process for adding new power-ups to the game. He asked me to write up a document indicating what needed to be done just to duplicate an existing power-up and put some skeleton code in so we could use it in game. I came back with a list of 14 steps that needed to be done, with some nasty gotchas involving human error.

Fourteen steps just to get started.

Production methodologies are overrated. It sounds silly to say it because it's repeated so commonly. Everybody knows it. "Scrum is not a silver bullet" say the supporters AND critics of scrum.

Then producers apply it to every problem anyway.

Think back for a moment to presentations you've witnessed or conducted in a classroom, a recent programming convention, or a co-worker explaining a concept.

The typical exercise in code evaluation presents a problem in a neat, isolated space, and it looks at one or two dozen lines of code that encapsulates an algorithm. "Look here!" the instructor says, "There's actually a problem right on this line!" The problems in the code is subtle, perhaps language-specific, and the solution seems ingenious once the teacher reveals the solution. On looking at the example long enough, the learner is usually able to recognize that the solution is logical, and if she was to see such a problem in the future, she would be able to apply this knowledge. This makes the learner feel accomplished, and the exercise is complete.

One of the things I ask myself often is how do great programmers separate themselves from good programmers. As a follow up, how does exceptionalism relate to my personal pursuit of sucess?

Today I'm going to throw out some thoughts I've been having about software architecture.  Why is architecture so interesting?  It's the land of the dreamer, the big picture thinker, the mountain mover.  It's implications are great, and all responsibility is held by the one, the chief architect.  He or she crafts the perfect blueprint while all other coders scramble to construct the low coupling, high cohesion brilliance.  It takes a genius architect to solve all the high level problems so the rest of the team can work like clockwork to divulge the mythical perfect project.

It feels terrible to write bad code, especially on projects involving real money and people instead of some silly class project.  Worse yet, you feel your senior peers looking right through you.  They know.  They know you just fiddle around aimlessly, deleting 90% of what you write over and over, until you give up, look over your shoulder, and throw some crazy hack in.  If you have a code review, they see, they frown and try to speak, but your code is so mangled that you have bamboozled your lead programmer, and he can't even formulate a suitable design after seeing your nonsensical partial interfaces and spaghetti methods.

Well this is exciting, my first blog post!  I've been interested in blogging for a long time, but have always had this apprehension to publicizing my opinions.  It's probably because I am terribly critical on the blogs I read.  So many people write about topics they have no clue about!  Why should I contribute to the entropy of the internet by adding my opinion slop to the top of the pile?