For those who didn’t know, the winter workshop was a three-week, full time program Nick Aversano and I ran in January 2015. The 10 or 12 of us (depending on how you count) committed to showing up every day and working on technical projects. Everyone who participated wanted to learn lots of coding, or hardware or something, and we wanted to get projects done.
We also wanted to have fun, be friends, build positive habits, and show that we could learn and get things done without the structure of the university. Do we need deadlines and exams or a boss and a paycheck to be productive? NO!
On all counts, we were moderately successful. Compared to doing nothing or trying to learn and get projects done alone, we were incredible - we were together, we made things, we learned. At the same time, every part of the program has room for improvement. We are not yet near the theoretical limit of fun and productivity!
A typical day in the workshop would see Nick and I arrive at 8 or 8:30 to plan out the day. In week 2, Nick was out to recover from tonsillectomy, it was just me, and I’d usually arrive closer to 9. Week 3, we were in the swing of things, and didn’t need as much planning, so it was 8:45 or so.
Everyone else would begin to arrive at 9. Of course, with college kids on winter break, 9am was sometimes a struggle. Around 9:15, we’d text and call late arrivals to make sure they were awake and on their way. Once most of us were in, we’d gather in a circle and share our goals for the day and what we were working on. Knowing what each other were doing helped us keep each other accountable and helped us know who we could ask for help.
Most of the day was spent at our laptops. We tried to implement break-taking mechanisms, with some success, but breaking people’s concentration and disturbing their flow took social and emotional heavy-lifting, and sometimes it was easier to just keep working on what we were working on. We ended up logging a ton of coding time, collectively, but that might have come at the expense of health and happiness. Getting this balance right seems tricky.
Nick and I split our time between working on our own projects and helping everyone else with theirs. I was happy to get this blog up and running (with Jekyll!), push a chrome extension, and learn about WebRTC. Nick made several versions of a bouncing ball game - he was trying out different languages and learning about the Cocos2d-x game engine, and ended up redoing work several different ways, all as part of the learning process. He found that Lua is the best language for development, because of the rapid iteration time. Lua compiles instantly, so when a change is made in the app code, it is instantly reflected in the simulation of the game.
We taught and helped lots of ways: small modules on git, databases, and web scraping; coding over the shoulder, helping debug, wireframing and logic modeling; digging up decent reference material, tutorials, and documentation. Sometimes we were pretty helpful - CSS selectors in particular gave a few different people issues a few times, and the independent modules were spot on. Sometimes the problems themselves were genuinely hard (as far as I can tell), like figuring out signal processing on Arduino, which doesn’t have the memory to use the good C fft libraries. Nick, with his deep and broad code knowledge, could also help with specific debugging issues that I couldn’t - I haven’t got extensive Android or Rails experience, so I couldn’t tell at a glance what might be causing a bug, or explain tricky concepts.
In a word, we were helpful when we actually knew what we were doing.
Going beyond the technical, we were helpful when we brought people together and facilitated goal sharing, checking in, and encouragement. It helped that the group was friendly, smart, and dedicated - they wanted to be encouraged. We had a lot of fun doing shared meals and breaks. Somehow, though, without the explicit prompting and framing from Nick and I, those group interactions didn’t seem to happen. If we were to do it over again, I would worry less about the projects and technical part and focus more on making sure that everyone was clear about their daily goals and struck a good balance between work, conversation, and play. Goal setting and daily check-ins are particularly important - missing a day throws off the habit.
Now, Nick and I are looking at running a four-week part-time program. Learn to code, 5-9 Tuesdays, Wednesdays, and Thursdays. (Check out the Website). We are narrowing our focus to learning coding, and, because we are time-limited, we aren’t going to focus as much on big-picture goal setting. I’ll miss going into the depth that we got to over winter with each of the participants - this group is much larger, and will inevitably be less personal. Still, the lessons about teaching and learning coding still apply:
I’ve got an implicit internal list that keeps growing all the time; by now I should be pretty great at learning and teaching programming. Here’s hoping!
All in all, it was a wonderful way to spend the first real weeks after graduation, with tons of life and learning packed into what was really a very small number of days. Thanks to Nick and everyone who attended for being such a great community!