Evangelism Reps Training Program/Trainings/Good-code-examples-and-posts

From MozillaWiki
Jump to: navigation, search

Training: Writing good code examples and posts

This training is meant to teach the Evangelism Reps the skill to write good code examples and posts. The way to explain that is to prepare a post that is bad and let the group find the issues with it after defining what they consider good posts and examples.

Promise:

"By the end of this training you'll know five things to avoid when writing code examples and posts"

Materials:

  • Demo post with errors in it
  • Presentation screen (if done in person)
  • Two whiteboards with pens (or MoPads if online)
  • Pens and paper for everybody
  • Final test materials

Timing plan:

0 - 5 min: Introduction, explaining what the training is about

Explain the time frame and what the outcome will be.

5 - 15 min: Whiteboard walkaround[1]: Collect what you like about good posts and about good code

Have two whiteboards on both sides of the room - one with "what do you like about good technical blog posts" and another with "what makes a good code example"

15 - 20 min: Looking at a post example

Show the post example you want them to analyse and re-write. Point out how many flaws you have in there and explain that you want each member of the group to re-write the post.

20 - 35 min: Re-writing the post example

Split the group up into twos and make each group re-write the post, one of them doing the code examples and the other one doing the writing around it.

35 - 45 min: Presentation of code examples - showing the differences

Ask for volunteers to present their post and explain what they changed.

45 - 50 min: Quick test [2]

Hand out a quick test asking for five things to avoid when writing posts with code.

50 - 00 min: Break / Material handout [3]

Materials

  • Flawed blog post and code example
  • Top 10 of mistakes to avoid when writing technical posts

Notes

[1] In a Whiteboard walkaround you have different question on whiteboards in the room and you split the group up into as many sub-groups as you have whiteboards. You let each group work for a while on each and then make them switch - adding to or amending what the other group has collected

[2] The test can be a simple paper test or a Google doc that allows people to answer a few things about the course. Make sure people are not scared of the test and tell them this is only for you to make sure that people did understand what was being shown. There is no point in training people when you don't make sure they got it.

[3] People should get materials to take away - this could be a URL. The point is that in this kind of training people learn on their own and can then look through the materials at their leisure.