The goal of every Hacker Schooler is to become a "better programmer." Given that I last wrote on Test-Driven Learning, and how could you assess yourself on it?" (Another wording, from Dave's post: "What qualities of being a 'good programmer' could you aim for, and how would you know if you had them?")

There is no one-size-fits-all assessment that would work for every Hacker Schooler -- everyone has such different interests, learning styles, experience levels, and a wide splay over every other type of spectrum imaginable for learning programming. (Typing speed. Language preference. Shoe size.) Making a single pre/post test and foisting it on everyone would (1) fail miserably at assessing anything and (2) work against the intentional self-directedness* of Hacker School.

So during my Hacker School residency, several Hacker Schoolers and I sat in Hopper (the big glass-walled room at the end of the space) and brainstormed on exactly that question. Here's what we have for starters, totally unsorted and only edited for spelling and clarity of terminology.

  1. length of  Hacker School bio page
  2. number of git commits
  3. number of "merits" (a currently nonexistent, hypothetical arbitrary credit) given by other students
  4. list of acquired skills
  5. contributions to FOSS
  6. number of pairing experiences
  7. lines of code per project
  8. list of completed projects
  9. total lines of code blogged
  10. number of roadblocks overcome (subjective)
  11. happiness/satisfaction (subjective self-report)
  12. lines of code written without needing to consult external references
  13. how fast can you make this deliberately slow code?
  14. Project Euler time trials
  15. persistence
  16. number of job offers
  17. number of friends referred
  18. ability to explain concepts to novice coders
  19. number of people helped
  20. understanding of software docs
  21. number of blogs
  22. hackathons attended
  23. number of followers in (git) repositories
  24. time wasted browsing other stuff
  25. length of time paired
  26. number of presentations
  27. ability to improve own code
  28. usefulness of programming blogs
  29. refactoring time trials (rewrite code to run faster, as fast as you are able to rewrite it)
  30. how many lines of code produced
  31. number of projects done as an individual vs collaboratively
  32. assessment from peer partner
  33. ranking of comfort with (programming) languages
  34. number of times you had to use a search engine to complete a task
  35. cups of coffee
  36. number of tweets on technical topics
  37. how many ways you can think of to code the same function
  38. total time spent with facilitators
  39. presence of test suites with code
  40. number of keystrokes
  41. hours slept
  42. debugging time trial
  43. results of code reviews
  44. number of git commits
  45. number of presentations delivered
  46. number of seminars attended
  47. number of seminars given
  48. number of new tools learned
  49. reading pseudocode
  50. ability to follow directions
  51. writing a program from scratch
  52. alum application reviews vs facilitator observations
  53. average length of (git) commit
  54. number of alumni contacted
  55. independent rating of CV by HR people
  56. can someone else independently compile & run your project?
  57. on a scale of 0-5, how confident do you feel as a programmer?
  58. number of interviews
  59. frequency of git commits
  60. number of questions asked of residents and facilitators
  61. frequency of code revision
  62. how many errors can you spot and fix in this deliberately broken code?
  63. time to fizzbuzz solution implementation
  64. how many technical words on this list can you explain
  65. grade on open courseware CS class final exam
  66. Zulip (Hacker School internal chatroom) lines with ? (question marks) in them
  67. heart rate/stress response during Jess McKellar's most technical talk

Further ideas quite welcome.

*Tom also pointed out that a pre-test would "prime" students to learn certain things and could dramatically affect their pathway -- for instance, if the pre-test had a bunch of CS theory, students would think "oh, I should learn CS theory!" and veer off in that direction, which could be positive or negative (but would most definitely skew the study results). He wondered if we could make pre-assessments that "primed" for certain... habits of mind, for lack of a better term, rather than content.