In 2006, I moved to southeastern Pennsylvania. Just a year later I discovered Philly.NET, the leading Microsoft developer user group in the Philadelphia area. I was inspired by the brilliant presentations given by the local leaders, Microsoft MVPs, and Microsoft evangelists.
It took me about another year to decide I wanted to join the ranks of dedicated speakers at their Code Camps and I started off by presenting how you could write games for the new Windows Phone 7 operating system. I stuck with the game talks for awhile, but I’ve also been hard at work talking about ASP.NET features. I use ASP.NET on the job and I enjoy game development as a hobby, so I’ve been on these parallel tracks.
Teaching other developers
What this means, essentially, is that I’ve been teaching development techniques or tools to other developers. This means I get to assume some or all of the following:
- The audience is proficient with C#. They use Visual Studio and it’s debugger regularly.
- The audience is proficient with ASP.NET (I’ve gone as far as assumed they know frameworks like ASP.NET MVC).
- The audience understands concepts like HTTP, TCP/IP, listening on a port, why you’d build a client/server architecture,
On the contrary, I never assumed the audience understood game development concepts, because I knew I was speaking to “business developers”, so this meant I tried to explain concepts like:
- The game loop as the controlling program structure rather than event based programming
- Sprites, Sprite sheets, and sprite animation (2D animation)
- Simple vector math to enable gameplay through the update loop
- Getting user input on a per frame basis
These lists are not complete, but they illustrated that I was consciously thinking about what I thought my audience already knew and what they didn’t. I comprehended as time went by that I was assuming too much about the first list and that I needed to make my talks about ASP.NET SignalR work for people new to ASP.NET as well, because they might be evaluating ASP.NET SignalR versus Socket.Io or their own WebSockets implementation.
Teaching someone to code
The point of all this is to introduce that I have recently been working on teaching people to code. When I say teaching people to code, I mean starting nearly from scratch. This is VERY DIFFERENT from teaching developers new tricks. This is thinking about how to best bring someone up from the bottom and help them learn how to build software and how to go about the process of learning more every day.
I have two motivators for this. First off, I decided to start a game developers group. It was “the group I always wanted to go to.” So I now am the co-founder of Philly GameWorks. We meet in Malvern, PA at the Microsoft offices, but my mission for the group was to be a place where anyone could learn to develop and publish their first video game (on any platform). This attracted business developers, but it has also attracted a number of artists, designers, and kids.
However, I quickly understood that I was not just speaking to developers anymore, and that I couldn’t simply assume someone who came to Philly GameWorks even knew how to code!
At the same time, I realized that there was a whole language of terminology and concepts that would become useful to these budding game developers.
For example, over a decade of game development as a hobby, I became fairly conversant in 3D Graphics lingo and concepts. I realized I needed to take a step back and plan a meetup where we just discussed these concepts and terms… an Introduction to 3D Graphics Programming… but teaching the concepts, not the code.
And it was our highest attended meetup so far.
The second motivation is that recently I had two longtime friends decide they wanted to learn to build web sites. They started aggressively on their own, and another veteran developer and I who are all mutual friends have been trying to guide them and push them. But this was yet a whole other reason to think more deeply about how to go about teaching someone to code.
I’ve begun to observe some things and form some ideas about how to go about teaching someone to code based on both of these experiences. I realized that others might benefit from some of the same advice, techniques, or content that I’m building for Philly GameWorks or in talking with my other “students”.
I advised these new students to do two things:
- Start working on a real web site, perhaps a small app that does something useful or a small game. Art is shipping!
- Blog about your experience. This helps reinforce that you are doing and working, and now you have what you learned in writing. Reinforcement!
One of those blogs is underway, courtesy of Sean Hornsby. I do suggest you check it out if you either are learning to code or interesting in observing the process.
So coming up next, I want to compare my journey in learning to code… a journey that started in 1984 (or thereabouts) and what I am recommending as a journey today. Times change. You’ll see they aren’t identical paths or parallel paths.