Wednesday night was the second Code Academy “Demo Day” and over 50 students had just three minutes to present what they learned and what they planned to do next. Hats off to every single student for their engaging and inspiring stories, and big props to Justin Brown, the student I mentored. Before Demo Day Justin kept telling me how nervous he was speaking in front of big crowds… which of course made me extremely nervous for him! However, he nailed it and gave a solid presentation.

Dan, Paul and I had the honor of leading off the festivities and we discussed what we’ve been doing since Code Academy, what we learned on “the project”, and then offered some advice to the students. We put up a pretty big list of all the things that we learned, but our advice to the students boiled down to two words: build something.

When the three of us sat down to talk about what we wanted to say, everything we put up on the white board was borne of the fact that for one month we focused all of our energy on a project with a specific goal, deadline, customer, a great mentor and a team we enjoyed working with. We learned everything that we needed to in order to finish something on time and within our capabilities (Agile, FTW). We also developed an even stronger understanding of what we didn’t know but needed to start learning in order to take the next step down our respective paths.

There were a few specifics to our “build something” challenge that we didn’t have time for in our presentation, so here’s some guidelines for any CA students or new developers that choose to take it on:

1) Find a “customer” that understands the goal of the project is primarily about learning, so they should think of the final product more as a prototype.

2) Since it’s a learning exercise as much as a “job”, there’s a good chance there will be little to no-pay— but trust us, the experience is worth it and the four weeks will fly by anyway.

3) Find a mentor that is available to meet with the team two or three times a week. Someone that can look over any hairy sections of code you want to clean up but can also be a third-party to verify that your team is on track to deliver- and help scope it down if need be.

4) Plan time for user testing! We did our testing 7 to 10 days from the finish so that we had plenty of time to tweak all the little UX flaws we hadn’t even considered.

5) Team up with people you get along with (if no one is getting paid you at least better be enjoying each other’s company), but also with people that have complimentary skills. Dan had the most design experience, Paul had written the most code and I’d managed a lot of teams (surprisingly there wasn’t that much difference from a cycling team: it’s all about the common goal). That doesn’t mean we just focused on what we were good at it either. Instead it allowed us to help each other learn more about our “specialties” (which is also just like bike racers).

6) Last but not least, learn about Agile for teams and stick to it: stand-ups, estimations, iterations, velocity, retros, customer involvement… the whole works. JC recommended that we read The Agile Samurai before we started and it was a great resource for providing structure to our workflow.

Best of luck to all of the Code Academy 2.0’s.