If you haven’t already done so, you might want to check out the first three articles in this series: “Introduction“, “Hiring“, and “Orientation“.
Once we have a new hire brought up to speed on our tools and processes, we begin a week of intense, classroom-style training.
Currently, this training spans over four days (ie. Tuesday-Friday of their first week), and is taught by a mix of me and my most senior staff.
For the most part, we use slide decks (which you can find here) that I’ve presented in the past as a framework for the training, elaborating extensively and providing concrete examples throughout.
We try to leave the new hires some time in the afternoon of each day to explore some of the concepts taught. Each successive morning, we leave some time for a quick review of the previous day’s content, and to address any questions that have arisen.
On the first day of training, we run through “Things Every ActionScript Developer Should Know”, breaking out into “Resource Management” at the appropriate time. This introduces code standards, some philosophy, programmatic motion, object oriented programming, design patterns, resource management, and some related project management and UX concepts.
The second and third days are based around my “ActionScript 3 Workshop” slides, and focus on a technical overview of ActionScript, Flash and the AVM2 ecosystem. The third day ends with an overview of UI frameworks, including Flex.
While we work with a number of interactive technologies (such as Silverlight, HTML5, iOS, and Android), Flash remains our core business and is our reference technology. It’s easy to teach someone another technology if they have a strong grounding in one already.
Their last day of classroom training includes a run through optimization strategies and core user experience concepts using “Quick As a Flash” and “Creating Effective RIA Interfaces” as the outlines (the latter is old, but remains largely relevant).
Based on feedback from our first “grads”, we’ve been debating spreading out this rather intense four days of training over an additional week, and giving the trainees day-long projects to solidify their knowledge in between classroom sessions.
We end the new hires’ first week with a review of the next phase, solo project development, and encourage them to brainstorm over the weekend.
The next article in this series, “Planning”, can be found here.
Nice. Really enjoying seeing the process. Your job seems really fun to work for. And really digging the classroom experience wish my current place provided some training.
It sounds a bit strange that you have to go through object oriented programming and things like that to a newly hired guy. Wouldn’t an understanding of OOP be a requirement before hiring?
hello grant,
Great article, thanks for sharing your experience.
While I was reading it I have discovered your presentation “quick about flash” and there is a part about casting :
http://gskinner.com/talks/quick/#46
I’ve just read an article about the same subject in jackson Dunstan website and he has a completly different results :
http://jacksondunstan.com/articles/830
So I was wondering what you think about that ?
thanks.
hello grant,
Great article, thanks for sharing your experience.
While I was reading it I have discovered your presentation “quick about flash” and there is a part about casting :
http://gskinner.com/talks/quick/#46
I’ve just read an article about the same subject in jackson Dunstan website and he has a completly different results :
http://jacksondunstan.com/articles/830
So I was wondering what you think about that ?
thanks.
@Bjorn – if you read the prior articles in Grants series – specifically “Hiring” – you will note that he doesn’t look for people that already know all of these things, instead he looks for people that have the appropriate passion for their work, and exhibit traits that would work.
Plus I have found that just because a person has experience and knowledge of OOP practices, it doesn’t mean they KNOW it or UNDERSTAND it the way you need them to.
loudoweb – I’m seeing similar results to that article. They are a little less dramatic, because I’m not isolating out the assignment time.
For example, I’m getting 90ms for Function casting versus 56ms for “as”.
Note that the slide deck executes those tests at runtime, so you may see different results depending on your system, player version, browser, and whether you’re using the debug player.
Could you give us a concrete example of what a ‘day-long project’ would be for your company?