Digging In
The following is a guest post by Sarah Duve and originally appeared on her blog. Sarah is currently a student at The Flatiron School. You can follow her on Twitter here. We just started “Build Mode” at Flatiron, which means switching from a labs and lecture-based school day structure, to an entirely project-driven, freeform day with completely new […]
The following is a guest post by Sarah Duve and originally appeared on her blog. Sarah is currently a student at The Flatiron School. You can follow her on Twitter here.
We just started “Build Mode” at Flatiron, which means switching from a labs and lecture-based school day structure, to an entirely project-driven, freeform day with completely new teams. Avi gave a great pep talk to kick things off, addressing why our projects were assigned rather than self-chosen, and specifically with less-than-riveting use cases. It all boils down to the fact that as web developers, we’re often hired to solve other people’s problems; we cannot be driven by purely personal interests. This is a message that was particularly important for me to hear. My college didn’t have a required “core”, and as a Psychology and European Studies double major I was able to relatively easily fulfill what requirements I did have. This meant I only had to take two or three classes that I really truly didn’t want to be in. You can imagine the kind of harsh wake-up call that awaits someone that has only been studying exactly what she’s interested in, with spare hours filled by passion projects that are given a level of attention that only a person living in a bubble could maintain. Avi shared a story about a project that initially seemed very dull, but after digging deeper into the issue at hand, actually led to an important innovation. Being a great developer thus means not just being able to care about other people’s problems, but also finding ways to make projects interesting that on surface may seem anything but.
My team is tasked with the “OpenExam” project, which uses student-generated quiz questions to gamify both ends of the assessment process. The fewer people that can correctly answer your question, the higher your score. While this may not have initially been my first choice, upon “digging in” I’ve found a lot to be excited about.
One thing that my Flatiron experience is a constant reminder of is how detached our concept of “education” has become from actual learning. Take away things like grades and graduation requirements and people often become very suspicious, as if they’ve forgotten entirely that the aforementioned things are meant to be indicators of what has been learnt and not an end in themselves. This is a great opportunity to engage more deeply with these ideas as OpenExam flips the testing paradigm, making success require more than just regurgitation and closely targeted cramming. I’m still admittedly a bit skeptical of this model (are students really learning if they’re just hunting down edge cases to stump people?), so it will be interesting to find ways to measure its effectiveness, deciding which key metrics to present to instructor users and how.
Figuring out what motivates people is a core psychological concept, and one we’ll be dealing with once we get into the gamification aspect of the application. How can we engage student users and motivate them beyond seeing question creation as yet another dreaded homework assignment? Once we have the core functionality down, this feature provides a lot of room for expansion and creativity.
My exposure to user testing and human computer interaction (and their relation to psychology) is arguably what got me interested in code as a full time professional pursuit, so it may be hard to believe that I didn’t see the huge opportunity here for user testing until Avi mentioned it in class on Monday. As he pointed out, since none of the projects stray very far from the realm of students learning to code, we’re all surrounded by our users. I’m really excited to try my hand at some informal user testing and usability studies, as well as play with some of the wireframing and UI tools that are out there. Coding in particular presents a unique challenge for the app. Is multiple choice really an effective way to test programming, or might we have to look into repls if we decide to dig deeper into this problem?
Of course the main goal is still to learn as much as possible about Ruby and Rails. Hopefully these points of interest will be enough to propel me, without distracting from the key task at hand.
Disclaimer: The information in this blog is current as of July 16, 2013. Current policies, offerings, procedures, and programs may differ.
