Computer professional resume

Don’t bother breaking through the door

I remember learning a few weeks ago that folks who professionally break into buildings (firemen, thieves, etc.) never use the door anymore.  Doors are simply too fortified.  Instead, one of the best ways to gain entry is often to attack the wall next to the door, which is usually a little weaker because of the door frame, and much weaker than strong fortified door locks.

I can’t help but think of that fact when I glance over the list of statistics compiled from the 450,000 leaked yahoo passwords today.

5% of folks used 12 or more characters in their password, which is really commendable when you’re trying to prevent folks from guessing your password.

Unfortunately, when your passwords are stored in plaintext, the way that yahoo did, it’s kinda like adding extra locks to your door when someone else has left a window open. :(

Build an instructor community

Last week a bunch of us MoFos had a discussion about how to build out our instructor community.  How do we find folks out there who are teaching this stuff, or similar stuff, and how do we “bring them into the fold”?  How do we measure success?

The more I thought about it, the more I realized that there are still some big questions out there about what we mean by “instructor community”, and why we want them, and why they want us.  Here are my rough notes while thinking about this.  (Including some thoughts by Mark Surman.)

Three classes of instructors:

  • 1) Already teaching “web making”
    • help guide their content to stuff we find important, via tools/curriculum/teaching culture that lean in that direction
    • help them expand?
  • 2) Already teaching folks, maybe not web making. (eg: camp instructor)
    • inspire them that this would be fun to teach
    • make it seem easy to teach
    • help them learn it themselves
    • provide tools, curriculum, etc.
    • success stories?
  • 3) Second-generation teachers: folks we could teach how to teach, and then they might. (ie: the learners becoming the teachers)
    • encouraging existing instructors to identify these stars
    • and providing a single pathway once they’ve been identified
    • lower barriers to teaching
    • teaching the teachers
    • how to host events, etc.
    • hooking them up with existing teachers to learn from

That first-touch experience:

  • Meet an instructor at a conference, they “want more info” about teaching webmaking.
    • Where (URL) do I send them? How do we follow-up?
    • What do we offer them when they get there? What might they do w/ what we offer?
  • We discover someone already doing this stuff.
    • What is our ask / offer re: doing ‘our stuff’ in addition to ‘this stuff’?
    • How do we tap them in? (mailing list, call, etc.)
    • How do we keep them engaged? why bother with us, rather than going alone?
  • Instructor finds us via our tools, search engine, or media, etc.
    • How do they discover the instructor community from there?
    • What are the asks / offers? What can they DO right away?
  • Instructor identifies a star pupil who’d make a great future teacher
    • How can we help turn that into a conversion?
    • How do we pipeline / onboard the potential teacher?

Providing them with things they find useful

  • Inspiration
    • …?
    • point at each other / a peer group (mailing list, calls, MozFest)
    • mozillawebmaker.tumblr.com (feature good teachers / students here)
    • have dedicated folks (volunteers?) welcoming new people
  • Content / curriculum / tools
    • webmaker.org, but where on the site?
    • email newsletter or just our mail list, regular ‘curriculum highlights’ or ‘try this’ tips
    • Teach them (so that they can teach others)
  • …?

Providing them with reasons to contribute back

  • [what are the reasons? :)]
  • How can we help make this feel like a movement that they are a member/hero of?
    • Showcasing other folks’ work, their own work, etc. Showcasing metrics.
    • Make them want to be a part of it, and able to see how their contributions matter.
  • Lowering the barrier to entry for contributions
    • We shouldn’t need to be directly involved. Make clear processes. Then make those processes scalable, etc. Eg: “So you want to localize Thimble! Awesome! Here are the steps.”, or “Anyone can reply to #webmakerquestions (or whatever)!”
  • If they do contribute back, making it a positive experience
    • Have a time-to-reply on all github issues as a MoFo standard
    • Have dedicated folks thanking them, keeping them engaged, etc.

These are important questions because I believe they should shape our goals.  For example, if we believe that what we’d be providing instructors with is A, B and C, then we should make sure to actually do A, B and C.

Lots of open questions, though.  I’d love any thoughts that you might have!

Teach a man to teach fishing

“Teach a man to fish and you’ll feed him for a lifetime.

Teach a man to teach fishing, and you won’t have to go around teaching fishing for the rest of your life.”

… okay, it’s a little less catchy than the original.  And, honestly, we already have so many overfishing problems in the world that this probably isn’t the right analogy.  But you know what I mean!

We’re at an interesting point in the Mozilla Foundation.  We’re in the middle of our Summer Code Party, and we’re starting to look at the roadmap for our tools like Thimble.  And, of course, there’s a million things we want to do with it.  From enabling javascript, to internationalization, to badges, to a gazillion other things, there’s a lot we want to do, and easily enough work for several developer-years.

There’s sort of two solutions to this problem.  One is to scale our engineering efforts: become a software company with tons of developers, engineering managers to manage them, product teams, UI teams, managers for those teams, etc.

The other solution, and one that feels more Mozillaey to me, is to use the developers we do have to build tools / processes / etc. that empower everyone else in the world to do the fishing.

For example, one of our top feature requests is to create a simpler version of MDN (the definitions we link to in Thimble) that would make sense to novices.  This seems like a great opportunity to create a quick interface to allow anyone out there to provide/edit the definitions.  If we open it up to the world, then not only can it evolve at the speed of the web, but we can also get things like localization.

There are often lots of folks who want to help and participate, but like all of us, they don’t want to do it if it’s going to be a lot of work to just get started.  These things have to be easy, designed processes.  That’s not to say that they have to be complicated.

Compare and contrast two tech support systems.

1) A form that you can fill out on a webpage somewhere to ask questions.  It emails an internal list, and someone there answers the question.

2) A twitter hashtag where you can ask questions.  Suddenly not only can internal people answer the questions, but maybe you know the answer too.

It’s a good example of how designing for community participation doesn’t necessarily mean creating a complicated tool or program.  It just means including participation as a first-order design principle.

There’s absolutely no way that the Mozilla Foundation can personally host events to teach web making to the world.  But I do think that if we do this right, we can build a movement that others build on, and make their own.

We can teach people to teach people to teach people to fish.  And soon there will be no fish left in the sea.  (But in this case, that means “everyone learns web making” so it’s not quite so ecological disastery.  … I hope.)

What do you think?

Teaching JS: results

Last week I tried an experiment of teaching Javascript by diving straight into jQuery, animations, and API calls, without going over the fundamentals.

The big caveat here was that the students already had:

1) Two days of Python.  (In other words, programming wasn’t brand new.)

2) Two days of HTML/CSS.  (So writing for the web wasn’t brand new.)

Overall, I’m going to say that the lesson plan was a stunning success.  The kids picked it up remarkably quickly.  There was enough open-endedness in the activities that the faster kids had stuff they could work on, and most of them managed to get their very own image search engine working by the end of the day, which is awesome.

Some of the kids had questions that indicated that they wanted to better understand what was going on under the hood.  One example of this was I got two questions about how Javascript’s passing-a-function-as-an-argument worked, though nearly everyone else was happy to just accept it as “you put a name of a function as the third argument, and that’s what’ll get called later”.

There’s only three big things that I’m going to change when I run this next time in August:

1) I don’t think they reeeeally understood how APIs work; at least not deep in their bones.  What I mean by this is that they were able to rattle off the definition back to me, but further probing revealed that I don’t think they actually understood that when they called the flickr api, flickr was giving them information that they did not have hardcoded anywhere.  They were talking to a different computer.  They were one half of a two-computer conversation.  That said, they’ll be writing their own backend later this week, so by then I’m sure they’ll understand it better.

2) I relied pretty heavily on “this works just like foo in Python”.  While that’s fine for teaching these kids, it means that the curriculum isn’t reusable with a group that doesn’t have those two days of Python experience, so I want to re-think this a little.

3) A few kids were pretty confused at the end about best practices in terms of when to use HTML versus CSS versus JS.  This is a reasonable confusion since it is confusing. :)  But I want to give some thought to how to better break down some rules of thumb for them.

So there you go.  One student later blogged:

Today we worked on JavaScript, using the JQuery library. Though I do know some JavaScript through Codeacademy […], I never really formally learned it like Python or Java. It was nice to learn all the things that make like easier. Like how […] importing the library was inside the html. I really like JQuery.  We made some cute animations and then an image search engine for flickr. We also looked at lots of cat pictures. That made me happy. This class made me hate JavaScript a bit less now that I’m not frustrating about using a language before getting to learn it.

Hating Javascript a bit less?  That’s all any of us could ask for! ;)

Learning to code is hard

Source: Abstruse Goose

Summer Code Party kicks off this weekend!

The Mozilla Summer Code Party kicks off this weekend, and look at the huge number of awesome events that are planned:

Want in on the action?

  • Find an event near you, or
  • Create your own <– It’s easy, and can be as simple as gathering a few friends in your living room this weekend.  Which you were gonna do anyway, right?

This huge convergence of awesome has been the work of sooooo many people.  Big shout outs and twinkles to all of them!!

Make sure to get plenty of sleep tonight, because the party’s just gettin’ started.

Follow

Get every new post delivered to your Inbox.