Test Driven Learning: setting learning goals for yourself, Software Engineering edition

February 10, 2014 – 10:01 pm

Stacey asked me for a refresher on Test Driven Learning for Hacker School, so here we go.

Test Driven Learning is a software engineer’s articulation of Wiggin & McTighe’s Understanding by Design framework after being strongly influenced by Ruth Streveler’s ”Curriculum, Assessment, and Pedagogy” course at Purdue.

Many software engineers are familiar with the process of Test Driven Development (TDD).

  1. Decide on the goal.
  2. Write the test (“how will you know if it’s working, exactly?”)
  3. Make the code pass the test.
  4. Celebrate.

 

Test Driven Learning (TDL) simply says “it’s the same thing… for your brainnnnn!”

  1. Decide on the goal (“learning objective”).
  2. Design the assessment (“how will you know if you’ve learned it, exactly?”)
  3. Go through the experiences/etc. you need to pass your assessment.
  4. Celebrate.

 

That’s it. Really.

Step 2 is the part most people flub. With software tests, you have a compiler/interpreter forcing you to be precise. With learning assessments, you don’t — but you need exactly the same level of precision and external execution. If you asked a group of external people (with appropriate expertise) whether you’d passed the assessment you set for yourself, there should be no disagreement. If there’s disagreement, your assessment needs a redesign.

A good assessment is a goal that helps you stretch and reach it; sometimes it encourages you to do more. But sometimes it also gives you permission to stop doing stuff – you’ve written the code, you’ve delivered the talk, they met the criteria you set —  and now you’re done. You can absolutely set a new goal up and keep on learning. However, you’re no longer allowed to say you Haven’t Learned X, because you’ve just proven that you have.

Here are some rough-draft quality TDL assessments you might start with, and a bit of how you might improve them.

I will learn Python. (What does that even mean? How will you know you’ve learned it?) I will complete and pass any 50 CodingBat exercises in Python. (But I could do that by solving 50 really easy problems.) Only 10 of those 50 problems can be warm-ups, and at least 20 of them must be Medium difficulty or greater. (Does it matter if you get help with the problems?) Nope, I can get as much help as I want from anyone, as long as I could explain the final solution to another programmer.

I will get better at testing. (What do you mean by “testing”?) I write a lot of code, but I’ve never written tests for any of it. I hear the nose framework is nice. (What do you mean by “better”?) Well, I’ve never written a test at all, so even going from 0 to 1 would be an improvement. I could use nose to write tests for 3 different pieces of working code I’ve already written. (Do these need to be big or exhaustive tests?) Nope, I’m just trying to learn what writing tests is like, not get full test coverage on my code… at least not yet. Even if I write a 3-line test that checks out one minor function, it counts as one of the 3 tests. (What does it mean for a test to be “done”?) When someone else can check out and successfully run my code and my test suite on their computer without needing to modify either bit of code, it’s done.

I will understand how databases work. (By “understand,” do you mean the mathematical theory behind their design? Or how to actually implement and use one?) Oh geez, the latter. I don’t care about the math so long as I know how to interface with a database. Any sort of database. (So you need to make a demo.) Yeah, but that’s not enough; I can blindly type in code from a tutorial, but that doesn’t mean I’d be able to field questions on it. (What could you do about that?) I will give a presentation to fellow Hacker Schoolers demonstrating a small database interaction in code I have written. That’s an easy binary to check; either I’ve given the presentation or I haven’t.

Thoughts, questions, ideas? Got your own example TDL assessment (at any stage of revision), or ways to improve the ones above? Holler in the comments.

Know someone who'd appreciate this post?
  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • email
  • Identi.ca
  1. 5 Responses to “Test Driven Learning: setting learning goals for yourself, Software Engineering edition”

  2. I freaking loved that book from my Curriculum and Assessments class! I’ve been struggling to learn TTD and practice it in my day job so it was interesting to see

    I’ve got several UBD lessons locked away in the portfolio site my uni made me use. I’ll have to dig them back out and look at them from a TDD-ish perspective, and maybe repost to my blog… which is long overdue for an update.

    By Tori on Feb 16, 2014

  3. given i had to do 1 and 3 recently, here’s what was extremely effective:

    Python:

    at start: I could google and write basic crappy code that worked, but it was not production quality.

    1) go to Udacity and hit all the quiz questions for intro python. if I got them wrong, I watched relevant videos to debug my understanding. this way, I know I hit a basic level of proficiency in all the critical areas, and I knew the way I was taught to think was extremely effective.

    2) ask a senior engineer to give me a python question. he gave me a very simple task which I spent an afternoon on before submitting. he responded by asking me to revise 4 things and to research and explain why those 4 things he pointed out were critical.

    Databases:

    at start: I barely knew what a database was and used one for an app a while back.

    1) Take a simple but non-trivial data model design question from an interview and do 2 things simultaneously:
    a) Watch Coursera DB lectures from the beginning to understand what a database is, why it exists, and how to think in terms of databases (relational algebra).
    b) Call up a database expert who walked me through how he would solve the problem.
    I would alternate between (a) and (b), ensuring that every time the DB expert said something, I would go back and fully understand the theory behind it. And when he didn’t explain something I learned from the theory side, I would ask him tons of questions to ensure I understood how they tied together. The key was context, because otherwise Databases were boring as shit.

    2) At work, I had to learn Cassandra, which was NoSQL. Here, I was fortunate to get an overview by a senior engineer, to whom I asked a hundred questions to integrate my understanding. He made sure that my questions were relevant and vetoed them when they weren’t (and explained why), so he refined my understanding about what is important.

    3) Then, I had to get Cassandra working on my system.

    …as you can see, I value the theoretical understanding a lot, and I found that the vast majority of that isn’t captured by getting anything working. I could’ve made a data model for a database and written working Python code, but I cared much more about getting to expert styles of thinking, and only experts could assess that effectively. So I guess it depends on what your goal is.

    anyway hope that helps someone

    By hari on Feb 17, 2014

  1. 3 Trackback(s)

  2. Feb 17, 2014: Test-driven learning » sacha chua :: living an awesome lifesacha chua :: living an awesome life
  3. Mar 31, 2014: Mel Chua » Blog Archive » Stephen’s question: how do you tutor fellow researchers in programming?
  4. May 12, 2014: Mel Chua » Blog Archive » What does “becoming a better programmer” mean? – Assessments Brainstorm Edition

What do you think?