Blog
Geeks Girls Carrots Mentoring
One of my fave meetup groups has always been Geek Girls Carrots (not to be confused with Girl Geek Dinners, another awesome networking/professional development group with equally awesome food and locations). Last spring, Geek Girls Carrots led the second of the Code Carrots courses. Ladies with any level of programming experience come together, form groups, pick an “app” to develop, decide which stack to use, follow an “agile” schedule of week-long sprints, and work with a mentor to advise on all of the above. I was lucky enough to be one of those mentors to a group of four ladies working on a Django project related to reporting sexual harassment in the workplace.
The main challenge here was time. We all worked full-time, and met after work once or twice a week. There was rarely a week when all group members could meet in person at the same time. I set up a Slack account for us to use, and it really helped when one or two group members were remote. I was also a git/github resource – such a tricky technology to novice programmers to get used to. It’s hard to keep the cognitive load low enough for actual learning – trying to use git correctly, not “break everything”, get code to work, and write code well at the same time (as any developer knows, even when years into their career).
In fact, on the first day of the project, I was called on to do an impromptu intro class to using git and github to the whole group of about twenty women. Let me clarify – I had zero idea I was going to do this until the organizers said, “Jessica! You know github, right?”. It was really challenging, but really fun, and reminded me of what I enjoyed about teaching. By the end of the class, everyone was able to clone a repo and contribute to it. Success!
After eight weeks, all the groups presented their projects. All had a working prototype, and many had one hosted online, like Heroku. It was a great experience that I hope they repeat soon (nudge, nudge).
Teaching is an Agile Process
If you’re like me, you get a special satisfaction out of pronouncing “processes” like “processEEs”. In that case, you are awesome.
Yes, it is late, and yes, I spent all day trying to incorporate a Google places details search over my Google nearby places search while learning about Casper.js testing, modularizing and objectifying (sorry, couldn’t help myself there) code, in addition to using the Google autocomplete function after sprinkling on some regex to validate user input although I still want to go in and run all input through some escaping a la OWASP recommendations but let’s face it, I need some metaphors, and teaching and programming are a great combination.
So, back to my topic: teaching is an agile process. Let’s take a look at agile and what that entails:
Quick turnaround. Instead of creating a finished, “perfect” product a long time from now, create the project in “sprints” (stages) and check in with stakeholders after each stage. That way, it’s easy to incorporate feedback before the next step.
It feels unnecessary to even explain how that’s like teaching, but let me spell it out anyway. In teaching, you must teach a class at a certain time. If you don’t have a “perfect” lesson planned (and you never do – that’s the dangling carrot that keeps you up at night and working on the 4th of July), you must teach anyway. And your “stakeholders” will give you feedback immediately (both non-verbally and verbally, not to mention on assignments and tests later on) on how lacking your lesson planning is and where to improve.
In agile, you can make small changes immediately in response to feedback. You might even adjust features and perhaps alter your overall course.
In teaching, if your class is feeling lackluster, you can change your plan in the moment to a different activity. Not only can you, but you must. Or, if your class is not following your carefully-planned content, you must change your plan accordingly. You cannot wait two months. You must do it now before Jim falls asleep, Sally starts texting, and Bob asks an off-topic question. If you realize the next day that what you had planned to to on Thursday is not what the students actually need, you must change your goals for the week.
Although maybe it’s not specific to agile, test-driven development is a big deal (again, it’s late, forgive my lacking vocabulary). This means that you write tests and expectations, followed by actually writing code. This is an awesome concept that mirrors teaching.
In education, assessment is all the rage. And with good reason – there must be some way to “measure” the black box of the human mind and learning. Yes, I will continue to use “” with “measure” because obviously there’s NO way to measure learning empirically, but we do our best to get a rough estimate, notwithstanding affective filters, investment, hunger, temperature, relationships, money, daydreaming, rectangle-gazing, parents, children, landlords, boredom, depression, cold, rain, snow, sun, lightening, dirty classrooms, raccoons, religion, gender, clothing, food, bedbugs… yes, these are all things that affect student learning and assessment accuracy. And yes, these are all things that have distracted students in my classroom. I’m especially proud of the raccoon.
Finally, in agile your client is not always aware of what it is they need and what exactly you do in order to produce their result. Same in teaching – when students complain of one hour of homework, they don’t realize the dozens of hours you will spend grading said homework. Also, students often think they want to do one thing (watch a movie, do fewer presentations, take more multiple choice tests) when in reality a teacher knows a better way to get them to their goal. And when students endure an activity or lecture, there’s little realization of the time and effort put into preparing that.
I’m certain there are more parallels to be drawn, but for now there are more Google APIs to be discovered.
Recent Comments