Thursday, January 16, 2020

My First Coding Project: A Ruby CLI Application

I was a little nervous getting started with Flatiron's Coding Bootcamp. I knew that I enjoyed coding, but I had also been teaching the same introductory content for years and didn't know how I would feel once I left that little bubble. After completing my first project, I can say that it is an incredible high to have designed and written a program that uses a host of tools and concepts -- object models, interacting classes, a command line interface, data from an API -- and that someone else could legitimately use! It's a far cry from being "useful" in the real-world sense, and still leaves me with this gnawing question of "will I actually be able to create things that people are willing to pay me for?" but I do feel that this project was a big step in the positive direction. Here are some reflections on the process.

Using an API: Imposter syndrome is always an issue for me, and it is often triggered by hearing terms over and over that seem to mean something specific to everyone else but are confusing to me! Once of those terms has always been "API" -- I would hear those letters thrown around so casually and think that I must be the only one who doesn't actually understand what an API is. This project was a great way to tackle that head-on. My awesome instructors demystified the idea of an API as simply a way of communicating with a database, and modeled the process of playing with various API requests and the data they returned. I used this list of public API's to guide my research and wound up choosing Open Trivia Database's Trivia API.

Starting with the End Product: In teaching we call this "backwards planning", and I found it to be great advice in terms of getting past that blank-screen syndrome. Instead of starting by mapping out all of my classes and methods, I started high-level: by creating my command line interface. What did I want the user to see when they pressed 'run'? When they pressed 'play', what menu should appear? As I thought about this from the perspective of the user's experience, the necessity for certain methods just became super clear. (I love the idea of calling the methods you wish you had, and then going back and implementing them!) Once I had something working, I was able to go back and refactor my methods ... but it was much easier to think calmly and deeply about my program's structure when I already had some working code.

Creating Object Models: In previous labs, we had been told what attributes and methods our objects should have. This time, it was up to us to design our classes. It made sense to create TriviaQuestion objects out of the trivia question data I was retrieving. Most of my attributes corresponded with information I was pulling directly from the API request: every trivia question had a category, a difficulty, a question, etc. I had to get a bit more creative in terms of storing a TriviaQuestion's answer choices. The API returned a question's correct answer as a string, and its incorrect answers as an array of strings. For example, the following question:

has a correct_answer of "1984", and incorrect_answers of ["Catcher and the Rye", "The Old Man and the Sea", "To Kill a Mockingbird"] ... which is all well and good, but doesn't really help when the user types in 'A' or 'C' as their answer choice! So, I decided to create an answer_hash attribute in order store the (randomized) letters themselves as data, and associate them with their corresponding strings. This particular question would have an answer_hash attribute of:

The previous data structure labs were interesting but had left me wondering why and how I would organically create such a structure (like a nested hash) on my own. Hence the epiphany when I came to this part of my project!

Testing for Bugs: After some playing around, I decided that five was the right number of questions for these mini trivia quizzes. I was having a lot of fun testing my program and answering trivia questions from various categories, and it wasn't until I had done this about 15 times that I happened to hit a category that didn't have five questions for the difficulty I had specified (I believe I was looking for hard questions about gadgets?). I referred back to the API documentation and noticed that "the API appends a 'Response Code' to each API call to help tell developers what the API is doing." How convenient! As a solution, I decided that I would generate as many questions as possible using the desired category and difficulty, and then fill in the remainder with questions from random categories of the same difficulty.

In future iterations of the program, I'd like to enable the user to select multiple categories from which to pull questions. For now, I think this is an effective work-around that prevents a somewhat subtle bug from causing some unexpected behavior!

Being OK with "Smile and Nod": As I continue to embrace the beginner's mindset on my coding journey, I can't help but think about phrases I used to repeat to my high school AP Computer Science students (most of whom were coding for the first time). One such instance was on the first day of class, when they'd write their first Hello World program in Java. To get this one statement to display to the console, students would have to declare a class and a main method using public static void main(String[] args). This was literally gibberish to my kids and I tried to encourage them by telling them this was a "smile and nod" moment: although they had no idea what things like public and static meant, it didn't matter -- they could still write cool code, and if they kept on learning then one day they would understand things like public and static.

As a highly linear thinker, it can be difficult to take this particular advice myself. I like to start at the beginning and understand everything fully, in order. As we know, this just isn't always possible. One particular "smile and nod" moment for me in this project was noticing that the API calls seemed be returning strings with some encoded symbols. I did a little digging and decided that the easiest solution was to ask the API to return the data using what seemed like an even deeper level of encoding (base-64), but one that appeared straightforward to ask Ruby to decode using the Base64 module. I understand very little about encoding and literally nothing about base-64, but I'm proud that I forged ahead and patched up the problem rather than allowing it to consume me.

Saturday, December 21, 2019

Why Software Engineering?

Wow, it sure has been awhile since I've posted here! I thought about starting a new blog to document my software engineering journey, but then figured that the real start of my journey was my experience as a computer science teacher ... so really, it makes perfect sense to document that here!

This blog is definitely missing an account of the past several years of my professional life, so I'll start there. Until 2016, I was lucky enough to teach at one of the most amazing schools in the country -- a public charter school in Newark, NJ that has a true sense of mission and is doing fantastic things for its students and their families. Everyone at the school truly believes that education is freedom and that mantra imbues the work ethic that is evident from classroom to classroom -- from the teachers who put in countless hours reflecting on their lessons and putting those reflections into practice to ensure better outcomes for their students, to the students who bring incredible perseverance and focus, to the administrators who truly support classroom learning and create an environment that incents everyone to be their best.

Although I started out teaching math (and pure math will always hold a special place in my heart!) I quickly realized that teaching computer science was my jam. I learned to code by teaching AP Computer Science A and got such a thrill out of both my students' progress and my own -- I honestly remember struggling with the idea of a constructor in Java for months! As concepts started clicking for me, it was great to use my new insights (as well as an amazing AP CSA teacher community) to hone my lessons and design activities centered around conceptual understanding, especially since most of my students were totally new to coding. I found tons of personal fulfillment in my role, and was rewarded in a variety of ways - not the least of which was a Milken Educator Award in December of 2015 (if you're not familiar, the folks at Milken go above and beyond to showcase teachers and schools; check out their work here).

As my own family began to grow (I now have two little guys of my own), I decided to leave my full-time role and pursue various opportunities in education while spending more time with my sons. After awhile, though, I just felt like I wasn't quite finding my niche in education the way I had hoped. I also noticed that I was happiest at work when I was coding -- either coming up with new projects for my students, or learning something new myself. I just loved the intellectual challenge, and I would often get lost in code for hours at a time. At some point I had to just listen to that nagging voice in the back of my mind telling me that I owed it to myself to pursue coding as a career.

As a CS teacher I have a grasp of many programming fundamentals, but still lack an understanding of how those fundamentals get used in real applications (as opposed to, say, simple games that live in an IDE). After just two weeks of Flatiron School's coding bootcamp, I'm starting to get a taste for what those applications might look like. Last week, we wrote Ruby code to scrape a web page's HTML and use the scraped data to create and manipulate objects. Seeing code that I wrote interact with actual websites was kind of mind-blowing, and I know that this was merely the tip of the iceberg.

I'll admit that I'm nervous about leaving a field that I'm so comfortable in, to pursue a field that is a big unknown to me. I have lots of motivators -- primarily my own intellectual curiosity, but also my sons. My 4 year-old asks me constantly, "How did coding go today?" and I love that he gets to see mommy taking on this challenge. I will always be passionate about education and part of me hopes I will eventually find a way to marry education and coding -- whether that's back in the classroom, or by designing software to help tackle one of the many problems in public education. Perhaps I can work with an organization that's already doing great things, or maybe one day I can found my own. For now, I'm interested in learning as much as I can and broadening my perspective on how I can make even a tiny contribution to the technology industry.

Tuesday, February 18, 2014

Setting the Record Straight: My Experience at an Urban Charter School

I recently attended an education forum in Newark, NJ where two mayoral candidates spoke to several educational issues. Beneath the exterior of good old-fashioned debate, though, some well-worn myths about high-performing urban charters reared their ugly heads. We’ve all had that experience: the family dinner where you’re asked - no, told - for the umpteenth time that “students have to take a test to get into your school, don’t they?”, or the casual conversation where an acquaintance finds out that you teach in Newark and immediately responds in a sympathetic tone with some vacuous comment like, “It must be so difficult when the kids have so many other issues to deal with.” Education is a funny thing, because everyone feels like they’re a little bit of an expert. (Heck, we’ve all been to school!)

I’m all for discussion - but let’s get some facts straight.

First, a little about me: I am a math and computer science teacher at North Star Academy College Preparatory High School in Newark, NJ. I began my teaching career at High Tech High in San Diego, California - a project-based charter school that I loved and that continues to shape many of my classroom activities and goals for students. I am a product of a large, suburban public high school. I have my Bachelors’ and Masters’ Degrees in Mathematics, and took an “alternate route” to my teaching certification. I have been teaching in public charter schools for 5 years - and I am about 5 years overdue in writing a response to the incessant questions on the very existence of charter schools (based in varying degrees of fact), as well as unfounded attacks on methodologies employed by some of the highest-performing urban charter schools, like North Star. I do not speak for my school, for the “education reform” movement, or for anyone other than myself and my students who have turned themselves into into amazing, college-bound young adults with a little help from us. And so, the high-performing urban charter movement as I see it:

The Data Myth

Based on some of the scathing critiques of exit tickets I’ve read (see this rant by a former KIPP teacher), I have to come right out and say it: If you are that critical of the very idea of an exit ticket, then clearly you and I have different ideas for what an exit ticket is.

An exit ticket is just a way for you as a teacher to figure out what your kids learned in a given class period or series of class periods, and what they didn’t learn. It’s a low-stakes, immediate form of assessment that is used to inform your teaching tomorrow and next week, because goodness knows that not everything we teach gets “learned” the first time around. It’s an acknowledgement that, yes, while I might be teaching the same curriculum as I taught last year, I’m teaching it to a different group of students who are going to have different needs. How do I know their strengths and weaknesses unless I gather that data? Not on some standardized test at the end of the year. Not even on a unit test, or a weekly quiz. But sooner. That day. Why wait until a high-stakes assessment to figure out what your kids know?

For this reason, I am sure you can understand my confusion around the attacks on exit tickets. Call it an exit ticket or call it something else, but if you’re not assessing what your kids have learned before moving on, then what kind of teacher are you?

The Robot Myth

My students are not little minority robots, relegated to a classroom where silence, obedience, and multiple choice tests reign supreme. Instead, they are budding intellectuals, realizing the potential and the brilliance that all students of any race or socioeconomic circumstance have within them. On any given day, they are discovering the subtleties of object-oriented programming in Java through inquiry-based labs, debating a mathematical question in a hands-down discussion, or playing a ridiculously fun game to practice their Unit Circle facts because, yes, black or white, sometimes you just need to jump through some hoops to be able to get to the next level in life. In my English, History, and Science colleagues’ classrooms, you will be confronted with a similar level of intellectual engagement that would be astonishing even at a suburban school. Without reservation, I would send my own children to North Star.

Do we have systems that some perceive as “over-the-top” - a relentless uniform policy, daily homework detention, mandatory after-school tutorials? Yes, we do. And I assert, unapologetically, that those systems are the very means by which our students are able to achieve to the levels that they do (see above), and that similar systems would benefit any student, of any race or socioeconomic background. And yet, I understand the realities. If I were a teacher at a suburban school, I might not freak out to the extent that I do now if a student didn’t turn in their homework one day. Of course, systemic poverty is an ugly thing and forces us to be a little more relentless on our mission. Anyone who doesn’t acknowledge that teaching underserved students requires a different set of tricks, has clearly never taught an underserved student. Even Diane Ravitch would agree with that, right?

Bottom line: My students are not robots. I am not an ivory-tower outsider who is inherently disrespecting them and underestimating the unfortunate circumstances they were born into. On the contrary, I am committed to doing whatever it takes to unsurface the scholars - the budding philosophers, engineers, computer scientists - that lie beneath the sometimes-ugly picture that is life for a child in Newark, NJ.

“There’s nothing that charter schools are doing that public schools couldn’t be doing if they wanted to.”

I am paraphrasing a quote from Shavar Jeffries, a brilliant son of Newark who is currently the underdog in the race for mayor of that city. I am beyond sick of hearing complaints that the most successful charters are benefiting from an uneven playing field, from more autonomy that the public schools are allowed. The conclusion that some draw that we should all be subject to the same inefficiency (economic and otherwise), bureaucracy, and paralysis by teachers’ union that has sucked the education out of urban public schools is the true disservice.

Indeed, that conclusion is exactly 180-degrees incorrect. There are immediate, instruction-based changes that any school could be making in its classrooms tomorrow if it wanted to replicate some of the best practices of some of the best charter (or public, or magnet) schools - that’s something we do constantly at North Star, and it almost always results in more student learning. If it doesn’t, we stop doing it. It really is that simple.

Thinking longer term, a strangled public system that has proven a failure for our most vulnerable population should not be stuck in the status quo just because it’s not “fair” for some schools to be better than others. The system needs a slow, careful, and deliberate overhaul.

A “corporate agenda”?

Slow, careful, and deliberate is the name of the game. The best charters have been subject to so much criticism because they don’t immediately serve the highest-need students in the same quantities that public schools do. Factually, this is correct. Rather than a criticism, though, I see this as a necessary part of the reform process. You don’t perfect a long-term successful model by immediately subjecting it to the highest possible amount of stress. Instead, you start with a small test group - 50 kindergartners, say, or 25 fifth-graders - and you slowly expand. Because of the level of control possible especially at those early stages, you are able to experiment with systems and determine which ones work and which ones need to be changed. Six or eight years later, you find yourself serving 2,000 students, many of which are coming to you with significant challenges. Now, though, you are in a position to actually serve them using a model whose components have been refined and might just actually work.

This is how real, sustainable progress happens in any sector - technology, business, or education. And if that’s a little too “corporate” for your tastes, you’ll get no apologies from me.

Wednesday, May 15, 2013

Have an hour to fill with your students?

Something amazing is happening at my school right now: the kids are all abuzz over - WAIT FOR IT - the prospect of a computer science class next year! I mean, yes, there is also talk of prom and all other aspects of teendom, but for the past few weeks there has also been a tangible excitement over coding.

It started when my school decided to hold an "Academic Festival" - one day when we were encouraged to deviate from our curriculum, throw guided practice to the wind, and teach something that we are passionate about. I decided on a one-hour introduction to programming, which was really a thinly disguised pitch for the computer science course we'll be offering for the first time next year. I had my students warm up with a Do Now asking them to identify some of the many ways they rely on coding in their everyday lives, without even realizing it. I used this PowerPoint as a basis for our discussion, which led into this (now semi-viral) video put out by, and finally some live coding in Python (the Word Smoosher was a big hit). The anxiety I felt prior to this lesson can only be compared to the anxiety I felt nearly every day when I taught in a project-based environment: What if the kids don't find programming interesting? What if the lesson is a flop? What if we speed through the PowerPoint in two minutes flat and they have NO questions and they fall asleep during the live coding???

Of course, that did not happen - not because of anything special I did, but because my students had never before been exposed to the world of coding. In fact, I had to pinch myself at one point, when I announced to one group that there would be a coding class next year and they actually - no exaggeration - cheered wildly. "Okay," I thought. "They're really into it now. But they've never actually tried coding. What if they find it boring/frustrating/uninteresting?" 

I thought I'd have to wait until next fall to get that question answered, but just a couple of days ago North Star was lucky enough to be paid a visit by Jeremy Keeshin, cofounder of Thirty-two (out of 74) juniors from across the academic spectrum signed up for an after-school workshop that Jeremy ran to introduce students to some of the basics of coding as well as the terrific online platform for learning coding that he has developed. The program is such that students are able to watch short tutorial videos and work on challenges at their own pace, and Jeremy and I mainly circulated to help students troubleshoot -- what a great model for true differentiated instruction in computer science! In less than an hour, kids were already getting at some pretty big concepts softened only by the cuteness of Karel the Dog and the entertaining challenge names (Mario Karel!): "How can I teach the dog to turn right using ONLY turnLeft() commands?" "What if I want to make Karel move over and over - is there an easy way to do that?" 

When it comes down to it, what I'm feeling right now is probably what every teacher feels at some point - the magical epiphany that "A few weeks ago, my students didn't know [what programming was], and now they're [running home to work on coding challenges] and [saying that they want to study computer science in college]." 

They say that what we do every day changes lives, but some days that just feels especially true. 

Saturday, May 4, 2013

A Fun Twist on the Jigsaw

Like every teacher in the universe, I am constantly searching for review activities that are both engaging and effective. I have played with the idea of a jigsaw before, but have struggled with engagement in my lower-level classes when the students returned to their home group to teach each other.

Nothing much was different about the setup this time - students in my classes sit in groups of 3-4, and so each "home group" got split up and students joined one of four groups, each of which was responsible for mastering a particular review problem. The small twist came when students returned to their home groups. They had about 10 minutes per problem to work through a packet that contained the 4 different problems that the different groups had mastered. However, during the 10 minutes when a student's group was working on the problem that they had already mastered, instead of doing the problem himself and just serving as a "resource" (the approach that had led to disengagement and non-ideal group work in the past), that student actually had to STAND UP and circulate around the group just as I would during independent practice. We modeled what this would look like beforehand, which the "teacher" closely monitoring all other students' work, watching for errors, and asking guiding questions if a student got stuck.

There was something about the physical aspect of standing up that completely changed the dynamic of this activity from a thinly veiled guise for getting students to simply to more practice problems, into an opportunity for each student to delve more deeply into the intricacies involved with actually "teaching" a problem and identifying common errors. For me, it was incredibly fun to watch my students - especially the lower-performing students who don't typically take on a teaching role in class - hover over each other, get frustrated at their peers for not understanding and themselves for not being able to explain something as well as they thought they could, and then ultimately figure out what exactly was confusing their "student."

Overall, I really liked the accountability that was built into this activity. One other nice (and rather selfish) unexpected consequence was that students all commented on how "hard it is to teach something without giving away the answer" -- I couldn't agree more!

Tuesday, March 19, 2013

Back-to-Back Pictionary!

Last week in my highest level class (Calculus A, a class for juniors that combines all of Precalculus and the first half of AP Calculus AB) I was astonished to see how abysmal my kids are at describing graphs using the kind of terminology that their tests and exit tickets would *indicate* they understand - words like increasing, decreasing, concave up or down over the interval ... , symmetric about ... , etc. This occurred to me as I was having a student review a Do Now with the class and when he called on a student to describe the graph of f(x)=x^(2/3), the student described it as "the bird." It was clear then that we had a problem. Students could define the terms above and use them in the context of multiple choice test questions, but they are far from fluent in graphical lingo.

Enter Back-to-Back Pictionary.  I played this today in one of my regular Precalculus classes and it turned out to be a blast and also extremely productive. Partners sat back-to-back, each of them with a different sheet of nine graphs each. Some of the graphs were recognizable based on the types of functions we've studied, and others were strange piecewise concoctions. They also had their mini whiteboards. Students took turns choosing a graph to describe to their partner, the caveat being that they could only use sentence starters from the word box: "The graph is increasing/decreasing over ...", "The graph is concave up/down over ...", "The graph is symmetric about ..." etc. I told students that they weren't even allowed to reference the name of a parent function in their description (let alone make bird noises, as one student asked). The sketcher listened to his partner and drew the graph on his board; when he thought he was finished, he'd show to graph to his partner. The team got a point if the graph on the whiteboard matched the graph on the sheet.

I modeled one with a student, and then they played for around 15 minutes. The room was loud and slightly chaotic, but it was exciting to hear students screaming at each other "I TOLD you it was MONOTONICALLY INCREASING!!!" Not something you hear every day (but hopefully something I'll hear more often, going forward).

Saturday, June 9, 2012

The 33-50-95-100% Model

Every so often I have an epiphany about life or about teaching, and even less frequently I have one that lies in the intersection of the two. I realized recently that my OCD, type-A, control freak nature (while often productive and even, some say, endearing) has just as much an effect on my classroom as it does on my life outside of school. Although it would be healthy for me to take a step back and learn to relinquish a little control in both realms, I'll spare you the details of my personal life and stick to my teaching. This "relinquishing of control" is something I'll call the "33-50-95-100% Model".

I'll start off by explaining the model I had been using, which I'll call the "100% Model." In the 100% model, I'd introduce a new concept, design a class period or maybe two of very thoughtful, methodical guided practice, assess the objective on an Exit Ticket, and foolishly hope that 100% of students had mastered the topic. Undoubtedly they wouldn't, and so I'd hurriedly try to patch the holes using Do Now's or spiral homework assignments over the next couple of weeks, so that all 100% would at least master the objective by the time of the unit test. Which, of course, they wouldn't.

Right now my Precalculus class is finishing up their last unit, on limits & continuity. The first topic in that unit was reading the graph of a piecewise function to determine one- and two-sided limits, function values, and types of discontinuities at certain points. And, as with anything graph-related, there was a group of students (about one-third of the class) who immediately caught on (aced that day's exit ticket) while the rest seemed to have forgotten everything they ever knew about reading a graph. Ordinarily I would have done a significant amount of spiral review, but due to timing constraints I had to give a quiz prematurely. Of course, the 33% who understood the material aced the quiz, and the 67% who didn't, didn't.

I had a little more wiggle room during the week after the quiz, so when I handed back the quizzes I did so in groups of 3, basically putting one of the stronger students in charge of tutoring 1-2 peers who were struggling. They had 30 minutes to figure out their mistakes on the quiz and then complete a practice sheet with similar problems. At the end of the period there was an independent exit ticket, again with similar problems. Results of the exit ticket suggest that around 50% have mastered the content, while all but a few are on their way and much closer to mastering it than they were at the time of the quiz.

I suspect that spiral review (through Do Nows, quick drills, etc.) will be much more effective now that a critical mass of students have mastered the objective - hopefully so much so that by the time of the unit test, only a few students will still be struggling. And those are precisely the students that I will be able to focus my attention on during after school tutorials.

I think the only real difference between the two models is that in the 100% model I was operating on the (obviously false) premise that if I just taught a particular topic "well enough" the first time, all students would be able to master it at the level I required and on a timetable that was convenient for me. The latter model is simply acknowledging the unreasonableness of this assumption by allowing kids to move on with a slightly new topic so that they don't feel like they're beating a dead horse every time they walk into class, and then coming back to the original topic in a few days or weeks with a fresh set of eyes and a built-in set of peer tutors. The buzz in the classroom was focused and productive during the peer tutoring session; the strong students were challenged to explain problems and forced to ask questions about the subtler points that even they struggled with, while the weaker students got the one-on-one targeted instruction that they needed but would have never gotten in a large group review.

Of course, this was not easy for me. I had to accept that 100%-or-Bust only has one possible outcome, and I had to trust both my student tutors and tutees to do what they needed to do while I merely facilitated or clarified a point here or there. But at the end of the day, I think I have myself a new paradigm for thinking about how my students actually learn (as opposed to how I wanted them to learn).