Grant Skinner braves the daunting task of telling all of us what we should know (and I assume that we DON’T know). Either way, it had a kickass intro… Wonder what the track was.

A set of his slides can be found on his website:

Types of Developers


This type of dev is learning syntax, language, and focused on completion. Totally reactive, not at all proactive.


From here we learn structures, algorithms, focus on correctness, pick up the proactive tendencies, and lastly you are considered a specialist.


Focus on learning reasoning, gestalt the application as a whole, focus on results, pragmatic, and generalist. An architect stops worrying over quibbles over commas versus learning how things should be DONE.

Grant is showing a chart showing how as you gain experience, the adherence also goes up, until you get to architect status. Bending and breaking rules is somewhat tolerable in order to achieve optimal performance.

There are NO right answers

When it comes to development, there’s plenty of WRONG answers, and some good answers, but none of them are necessarily right.

Code is Art

I like this, it is, he got it right. In order to be exceptional at what you do, whether it be development, a musician, painting, etc you NEED creativity.

So what?

It is vitally important to understand practices and approaches, and when that has been reached you can then creatively solve problems by bending and breaking conventional rules.


The goal for code standards is to create self-documenting code. Well written code doesn’t always need man created documentation in order to be easily read.


  • classes – Singular noun, leading capital, camel case.
  • packaes – reverse domain notation
  • imports – use full import statements; .* doesn’t define actual dependencies
  • peperties – noun, leading lowercase, camel case
  • methods – verb, leading lowercase, camel case
  • constants – all caps, underscore separates words
  • name according to purpose, not its type
  • emulate language standards by using nomenclature where reasonable
  • comments – indicate variations from the norm; colon indicates comment applies to following lines, period applies to a block of code
  • signed comments – internal comments indicating that code should be revisited
  • ASDocs – document properly to create documentation

Programmatic motion


Tween libraries are powerful, easy to use, great for transitions, and ensure you evaluate on appropriate criteria.
For things used in games, where an animation will change we should use simple ease outs.

[sourcecode language=”actionscript3″]
x += (targetX-x)*0.1
if (Math.abs(targetX-x) <1) {
// end tween


More organic feeling, and more adaptable to user input.
[sourcecode language=”actionscript3″]
velocityX += (targetX-x)*0.1
velocityX *= 0.95x += velocityX
if (Math.abs(targetX-x)<1) {
// end tween

Resource Management

Delete is NOT the answer

Deleting does not delete the value, only the variable. Likewise nulling a variable replaces the value, doesn’t delete it.

Objects are passed by reference

All references must be removed before eligible for garbage collection


Creates references to your object, you should use weak references to fix it; if using anonymous functions you (have your own issues to work out) should use strong references.

Objects active until collected

Objects will continue to use memory and execute idle actions until the GC runs.

Collection is indeterminate

You cannot accurately predict when the GC will run.

GC is costly

A GC sweet uses significant CPU and can cause animation to stutter.

Resource management is a large topic, and requires research based on the topic at hand.


Reuse, maintenance, planning, estimating, debugging, scaling, etc are all awesome reasons to use OOP tactics rather than procedural. Of course, you may not need to use it if it’s such a small application/component.

Simply stated, OOP is simple disassembly and encapsulation. We like to break up a big problem into small problems.

Think Lego, not Playdoh. Legos can attach to eachother easily because of common interfaces, where playdoh is too ambiguous.

Object communication is done in two main ways: methods, and events. Reusable pieces would utilize events to remove coupling, where non-reusable pieces would use methods to be specific in interaction.

We want to also favor composition over inheritance. Inheritance requires coupling of functionality, where composition allows for a relationship through references, not necessarily defining coupling. We can even go a further level and utilize Inversion of Control (IoC) to have components communicate around events and auto-manage themselves. This allows for pluggable components and more variations.

Large systems with repetitive items should look into Object Pooling.

I’m going to skip the rest of this topic because I think OOP is something that you either pick up, or you don’t. And, there’s tons of articles about OOP out there. GIYF (Google is your friend). Also check out antipatterns.