Grant Skinner

The "g" in gskinner. Also the "skinner".


JSFL #include & classes.

I’ve been doing a lot of work with JSFL the last little while, and was starting to get frustrated with the inability to define my classes and methods in separate files. I did some hunting around, and found a couple of solutions that worked by putting objects in an implicit global scope, but this doesn’t seem to work in CS5.

After some messing around, I came up with an approach that seems to be working:

In MyClass.jsfl

MyClass = function() {}
var p = MyClass.prototype; = function() {

in main.jsfl:

var JSFL_PATH = fl.configURI+"path/to/jsfls/";
var included = {};
function include(file) {
	if (included[file]) { return; }
	included[file] = true;
var foo = new MyClass();;

Creating Great Developers: Shadowing

Earlier posts in this series: “Introduction“, “Hiring“, “Orientation“, “Training“, “Planning“, and “Production“.

Once the new hire has successfully delivered their internal project, they are ready to move to the next phase of training: project shadowing.

We pair the new hire up with one of our senior developers, and have them work on the same project and tasks in parallel. At the start of each week, the senior developer will sit down with the new hire to outline the goals for the week, help prepare micro-deadlines (ie. production targets for each day), and provide some guidance on architecture and approach.

Throughout the week, the new hire works towards the assigned goals, and is free to ask their mentor for help or advice in an appropriate, organized manner. We schedule time for the senior developer to account for this, so that it does not create a burden on them.

At the end of the week, the trainee is provided with the mentor’s source code and given some time to compare it to their own efforts. They then sit down with their mentor to review their code quality, communication, and productivity. This also gives the trainee an opportunity to ask additional questions that arose during development or (more critically) while they were comparing their efforts to the senior developer’s work.

Besides being another great learning opportunity, it also provides the trainee and the senior staff with applied benchmarks as to how they are performing on a real project, without the risk associated with actually placing them on a client project. An important factor is that shadowing is treated as a serious project by both the trainee and the team, with a project manager, deadlines, and testing / quality control.

We repeat this process for 3-5 weeks, depending on the trainee’s performance. Most weeks we will switch mentors, so that the trainee is exposed to a variety of working / coding styles.

At the conclusion of shadowing, the trainee has been with us for between eight to twelve weeks, and is ready for their three month review, which will is the subject of the next article, available here.

Creating Great Developers: Production

After an extended hiatus, for which I apologize, I’m finally going to wrap up this series with the last 3 entries: Production, Shadowing, and Conclusion.

Earlier posts in this series: “Introduction“, “Hiring“, “Orientation“, “Training“, and “Planning“.

With their plan in hand, the trainee now has 3-4 weeks to develop their internal project. They are assigned a project manager, and expected to treat this project as though it were real client work. This includes checking in regularly to version control, tracking their time, adhering to deadlines, and effective communication of issues to their manager.

They are provided full access to the team in order to ask questions or seek feedback, but are briefed on strategies to leverage this resource effectively without distracting others.

Every week (on beer Fridays) the new hire presents an update of their progress to the entire team. They walk everyone through their code, and ask for input on things they are having difficulties with. This provides the entire team with an opportunity to interact with them, get a sense for their strengths, and provide input on their code quality or approaches. It also gives the trainee experience with managing client feedback and change requests mid-production.

This weekly review is supplemented by ongoing reviews from a senior mentor who will check in every day or two to ensure the project is progressing well, validate their approaches, and do a quick review of their code.

By the end of production, they will ideally have completed coding their project, documented it with ASDocs, fully tested it, and debugged it. The final project is staged, and the trainee presents a full project debriefing which includes an analysis of what went well, what went poorly, and what they would change if they started again.

The senior staff then reviews their progress according to a variety of criteria, including:

  • Adherence to timeline and micro-deadlines or ability to notify management appropriately of non-adherence. Estimating time is hard when you’re new to it, so we expect a lot of inaccuracy. The important thing is that they communicate that back to their project manager in a timely manner.
  • Communication. Did they effectively communicate changes and issues to their manager. Did they utilize the support of the team in an appropriate and non-invasive manner? Did they accept, understand, and implement feedback well? How well written were their docs?
  • Introspection. How well did they judge their own abilities. Were they able to identify weaknesses and work to address them? Do they show an improved understanding of time estimation based on their own productivity? In brief, do they demonstrate an ability to analyze their own performance and work to improve it?
  • Tool use. How well did they use tools like SVN, time tracking, Basecamp, and their developer tools?
  • Code. Adherence to company standards, architecture, appropriate commenting, documentation, use of appropriate frameworks / libraries / patterns.
  • User experience: Did they attempt to create a usable, aesthetically appropriate interface? Do they demonstrate an understanding of UX core concepts and underpinnings.
  • Productivity. How productive were they in the time they had, accounting for things like necessary rewrites, and accommodating feedback?

Based on this review, we may ask them to spend another week or two cleaning things up or extending the project, or we may proceed into the next phase, project shadowing.

This internal project development gives the new hire a great opportunity to learn and apply new technical concepts while gaining an understanding of our processes and all the elements that go into delivering a successful project. It also gives our senior team to evaluate the new hire in a near real-world situation, without any real-world risk.

The next article, on project shadowing, is available here.

Spelling Plus Library (SPL) Version 2 Released

I’m happy to announce that we have released version 2.0 of our Spelling Plus Library (SPL). SPL provides real-time (as you type) spell checking for Flash, Flex, and AIR applications built with AS3. Version 2’s most significant new feature is full support for TLF text and components, including the Spark component set in Flex 4. We’ve also made a number of other bug fixes and enhancements.

To make up for the long wait for this version, we’re offering existing customers who purchased SPL within the past year a free upgrade, and a significant (~60%) upgrade discount to everyone else who owns a previous version of SPL.

We’ve already started work on SPL 2.1, which will add a number of new features targeted at mobile, and will be a free upgrade for all SPL 2 owners.

For more information on SPL, check out the product page here.

Finding Time to Play… and Using it Effectively

I’m a big proponent of play as a means to grow and succeed. In my career I’ve spent endless hours building things that interested me with no thought of recompense or acknowledgement, simply to broaden my knowledge on a particular subject, or chase a particularly intriguing idea. Play provides you with a fun method for exploring your medium without risk or judgement. It also allows you to build the things you wish people would pay you to build, and market the results to help steer your career.

In my conference talks, I frequently encourage others to experiment with interactive media. At first, I would often be asked “where do you find the time?” In answer to this, I started talking about an approach I call “Passionate Procrastination”, which simply involves using time you might otherwise spend procrastinating to build interesting experiments. We all have those moments in our day when we need to step back from the task at hand and let our brains mull things over. I proposed that rather than read Digg, watch videos, or surf Facebook, that time could be used to work on something else that you are passionate about.

When pressed further, I started talking about how little time was actually required. Twenty minutes every day gives you three full work weeks per year to apply to experimental projects. Considering the average American watches more than twenty minutes per day of advertising, this time shouldn’t be that difficult to find.

This seemed to convince most people (or they simply stopped asking) until today when I was yanked unceremoniously into a dotBrighton meeting via Skype and posed a question from an attendee regarding my recent talk at FOTB (I think his name was Paul, but I was a bit distracted, my apologies if I got it wrong). He cited my twenty minute figure, and asked how I was able to accomplish anything in that little time, given that it typically takes a good five or ten minutes to really ramp up on a new task.

I thought it was a great question, and that it warranted a more coherent answer than whatever I mumbled over Skype at the time. For me, there’s three parts to how I use this time effectively:

Firstly, that twenty minutes is an average that I only use as a demonstration of how little daily commitment it requires to accumulate a fair amount of play time. I would guess that most of my experimentation sessions last between 30 and 90 minutes, but I definitely don’t do it every day.

Secondly, it’s important to have a goal ready for when you decide to take a play break. I maintain a list of ideas in a text file on my computer, and glance over it regularly to keep the concepts fresh. I try to think through the implementation of these ideas during AFK (away from keyboard) times, like when I’m showering, or lying in bed trying to sleep (these are my two most productive idea times). This way, when I have some time to play, I’m ready to jump right into writing code and testing if my ideas work.

I also try to disassemble my implementations into small, easily-achievable sprints and accomplish one or two of them during a single break. This helps define and limit your time, as well as giving you a sense of accomplishment which can help propel you when you return to your usual work.

Thirdly, most of my play time is while procrastinating on other work. This means I already have my tools open and ready to go. In fact, I’ll often have a real project and an experimental project open at the same time, and swap over to play when I get momentarily stumped on real work (or just need a quick break). You mileage on this may vary depending on your work circumstances and your boss.

Play offers so many benefits, and it really helps keep working with technology from becoming mundane. Finding time to do it is likely easier than you think, even if it means missing the next Old Spice ad. I’m on a horse!

Creating Great Developers: Planning

It’s worth reading through the first four parts of this series if you haven’t already: “Introduction“, “Hiring“, “Orientation“, and “Training“.

Once we’ve finished subjecting our new hires to a week (maybe two in future) of classroom training, we turn them loose on an internal project. The core goals of this exercise are:

  • Familiarize new hires with our process and all the steps that go into a project.

  • Apply concepts learned during formal training, and continue their technical growth.

  • Begin developing their competency in critical secondary skills including estimation, time & project management, project planning, user experience (UX), leveraging existing resources, effective communication, QA and issue resolution.

  • Develop skills with tools including development tools, SVN, and Basecamp.

  • Start them thinking about value and business considerations for projects.

  • Force them to respond to feedback and changes in an agile, responsible manner.

The trainees are informed about this project on their first day at work, and reminded of it throughout their first week so that they can brainstorm ideas in advance. They are also encouraged to run their ideas past people to get feedback. Over the course of the second week they then develop a full project plan, which is maintained and organized in Basecamp.

At the start of this phase (usually the first day of their second week) the trainees are asked to solidify their concept(s) for their internal project, and prepare whatever materials they deem necessary to present it.

The only requirements for the project is that it fit in a 2-4 week timeline, and that it provide value to the company. This value can come in a number of forms; it could be useful, have market potential, have promotional value, contribute to the knowledge of the company, or it could just advance their training in a significant way.

At the end of the first day of this phase, they present their concept(s) to the senior staff, and are presented with feedback as to its viability, value, and implementation. They then revise their concept based on that feedback.

Next, the trainee develops wireframes, defines user flows, and identifies any data requirements for the project. Again, this is presented to available senior staff and revised based on feedback. In particular, we focus on the appropriateness of the user experience, and the completeness of the wireframes, flows, and data requirements to ensure the trainee has a good understanding of the full scope of their project.

The trainee then moves into doing some high-level architecture. They prepare a CRC outline (classes, responsibilities and collaborators), and an I/O spec (input / output for a web or local service). Once again, this is presented and revised.

With the architecture approved, they write up a project plan that includes a timeline, with milestones and micro-deadlines (ie. goals for each day or two).

Once all of this is complete (generally on the Friday of that week), they present their complete project plan (wireframes, architecture, I/O, timelines, etc) to the entire team for feedback and criticism. This lets them receive and filter a range of input, as well as letting them see the more experienced members of the team disagree and debate different ideas.

With their plan complete, they are ready to move on to production, which is the focus of the next article.

Creating Great Developers: Orientation

If you haven’t read the first two parts of this series, “Introduction” and “Hiring“, I’d suggest starting there.

The first day for a new hire is a busy day of orientation. The goal is to get them set up and comfortable with all of our systems, policies, and processes.

First, they get reintroduced to the whole team and educated on everyone’s roles. They learn who to talk to for specific issues, and who will be guiding them through their training.

They start with the administrative side of things. They sit down with our office manager to sign their employment contract (which they receive in advance so we can answer any questions), fill out forms, talk about payroll, benefits, employment policies (lateness, time off, overtime, external work), and general office polices. We put a lot of emphasis on the core clauses of their employment contract surrounding NDA and IP considerations.

Next, they get set up on all of our systems, and receive training on each. This includes:

  • Our network, dev PCs, and connected devices.

  • Software, what’s available, how to request serial numbers, etc.

  • Our email system, webmail, and signatures.

  • Instant messaging.

  • Basecamp, project tracking, and writeboards.

  • Subversion, checking out / in, branching, creating projects, etc.

  • Tracking time, and why it’s so important.

Next we walk them through all of our processes. We outline the full training program they will be going through, including informing them of the internal project they will be building (part 5 of this series). We give them a high-level introduction to our process for delivering projects and doing quality assurance. QA receives a lot of emphasis – what are the processes for testing, identifying bugs, resolving issues, and communicating status back to the project manager. We also talk a bit about our policies for using open source libraries in client projects (ie. usually only MIT licensed or equivalent and only with prior client permission).

Finally we remind them of their NDA, and introduce them to all of the current projects we’re working on. This can be a quick overview, or a more in-depth dive into each project depending on the time available.

Before the end of the day, they are asked to enter all of their time into our time tracking system, and are expected to keep this up to date going forward.

The next article in this series, “Training“, is up.

Creating Great Developers: Hiring.

If you haven’t read the introduction to this article, I would suggest starting there.

The first challenge in creating a great developer is finding someone who has the right raw attributes to start with. There are two parts to this: finding candidates and screening them to choose hires.

To facilitate the former, I work to establish connections within the local community. I sit on advisory boards for a number of local interactive programs, I get to know the instructors, I give occasional guest lectures to classes, and I try to contribute to (and in some cases, establish) local user groups. This lets me help steer what (and how) students are being taught. More importantly, it helps me identify the rising stars in each class and in the community.

I look for people who are smart, creative, communicative, and demonstrate a genuine passion for the field. I want someone who can solve problems, and is going to be very self-motivated about learning new things and building cool projects.

Once I’ve identified candidates, I invite them in for an interview. Two days before the interview, I send them code from a small internal project, and ask them to familiarize themselves with it. I also ask them to bring in samples of work that they are especially passionate about, or think best demonstrates their abilities.

Our interviews tend to be very casual. They start by meeting the full team, to introduce them to the people they’d be working with. We sit down, and I ask them a few general-purpose interview questions about their interests, goals, strengths and weaknesses.

I have the candidate show me their previous work, and ask them a lot of leading, high-level questions. “Why did you want to build this?” “How did you plan the project?” “Why did you build it this way?” “Why did you approach this problem in this specific way?” “Why not this way instead?” This lets me judge a bit about what motivates them, their technical expertise, and their ability to communicate.

Next, I open up the code I sent them earlier, and start asking questions about it. I try to ask questions that involve both technical understanding and problem solving, such as why they think a certain block of code was written in a particular way. I also ask questions about UX design, because this is such a critical part of interactive development. I start simple and ramp up quickly, hitting them with questions that are both a little beyond their technical comfort zone and far beyond it.

Throughout this process, I encourage them to talk me through how they are solving the problem. I also teach them about more advanced concepts, then I ask them related questions. This is important, because I’m more interested in how they learn than what they know.

I spend a lot of time just listening. I let them decide when they are done answering a question. It’s pretty amazing how much you learn about a potential hire by just letting them talk until they are done, while fixing them with an inscrutable look. Some people babble themselves into an ever-deepening hole of incorrectness (bad). Some stop, and admit ignorance (good). Some talk their way towards a solution (better). A rare few ask appropriate questions to guide their response (best).

This approach lets me gauge their technical & UX knowledge. More importantly, it reveals their intelligence, creativity, and problem solving process. It also lets me see how they perform under pressure, and how effectively they communicate technical concepts. I also try to judge how well they will fit into our corporate culture.

If things go well, we’ll talk a bit about what it’s like working at, both the benefits (cool projects, bonuses, benefits, etc), and the potential drawbacks (a lot of learning, taking a beating from the team early on, and the odd high stress moment). We’ll also start a dialog on compensation. Sometimes we’ll finish up with a game of ping pong or foosball with a few members of our team to get a better sense for their personality in a more casual setting.

If things didn’t go well, I’ll give them some honest feedback on why, and try to give some suggestions for how they might be able to improve. If I think it’s likely that they’ll be able to rectify the issues, I might invite them to come back in the future when they feel they are ready for it.

Finally, I generally try to hire in pairs, with the same start date. This allows us to train them together, which reduces the time spent and helps with retention (because they can help each other). It also gives them a “buddy” at a similar level that they can identify, work, and learn with.

The next part of this article, “Orientation”, can be found here.