Engage with the syllabus

The ultimate test of understanding rests on the ability to transform one's knowledge into teaching. Those who can, do. Those who understand, teach. ~ Lee Shulman, Those Who Understand: Knowledge Growth in Teaching

Context

A syllabus defines assessment criteria relating to a subject (for example, the Python programming language). CodeGrades provide free syllabi and candidates pay to take assessments by "grading".

A curriculum defines a course of study, educational activities or resources for learning; often used to meet the requirements of a syllabus. That's where you (the teacher) come in.

We appreciate and want to support and celebrate your work.

Let's explore how you might engage with our syllabi, to create and deliver an effective and enriching curriculum for your students, so they flourish and grow as CodeGrades candidates.

In CodeGrades, a syllabus is built from a cumulative series of assessments called grades. The higher the grade, the higher the level of attainment. Grades are defined by core concepts, written and administered by professional coders: they define the knowledge, skills and cultural practices needed to pass a grade. Candidates create and submit a self-directed coding project that demonstrates their grade's core concepts. Once submitted, an expert coder mentors the project while gathering evidence of attainment. You prepare your students, with your curriculum, as candidates for specific grades. Passing a grade means an expert coder confirms and provides feedback on your student's attainment.

Our first syllabus is for the Python programming language (and there are more in the planning stage).

Curriculum

Clearly, your curriculum must: effectively transmit the core concepts, and, engage your students in the creation of their coding project.

But there is more to consider...

CodeGrades's syllabi are framed by three educational practices, embodied in the grading process:

• a journey to experience,
• learn by doing and,
• mentorship.

Imagination is also a key aspect of the journey: It's not enough to show knowledge and skill, a project should creatively demonstrate the grade's core concepts.

Engagement with a syllabus means encountering all these facets of grading; something your students must understand and expect through your curriculum.

That it is your curriculum is of the utmost importance.

We trust you know your students best: where they're starting from, how to engage them, what resources work for them, why they're learning to code, when they're most ready for encouragement or criticism.

As their teacher, it's your privilege and vocation to comprehend such things; and act in their best interests so they learn, grow and flourish.

What might this entail?

Practice

For beginner coders, use Mu for developing Python. It's a feature rich code editor, but written for teachers and learners. Mu has everything needed to start writing Python, be that for games, websites, hardware or anything else. More advanced students should use their own choice of a standard code editor, such as those used by professional coders.

Once you have a development environment, practise the things developers do. (Practise is not the same as rote learning. To practise is to reflect and refine then repeat.)

But, what do developers do?

That's like asking, "what do musicians do?".

Clearly they play music. But style, manner and technique are as numerous as musicians.
Yet family resemblance between musicians is recognizable: these folks rehearse together, she composes in this style, they all sound similar to his playing. Each musician is a unique voice within dynamic and changing musical traditions.

Clearly coders write code. But style, manner and technique are as numerous as coders.
Yet family resemblance between coders is recognizable: these folks collaborate together, she organises code in this style, they all code similarly using his programming language. Each coder is a unique voice within dynamic and changing software development traditions.

Our coding syllabi identify the family resemblances between coders ~ the core concepts define what current software developers think software developers do.

Just as there is no one way to do music, there is no one way to do code. Different approaches each have strengths and weaknesses. Illuminating context, understanding and acumen is key.

Different styles, different manners and different techniques are just that: different. Welcome such diversity (and show compassion and tolerance if difficulties arise). A nuanced approach acknowledges that differences of perspective reflect our varied backgrounds, and welcoming diversity cultivates open-mindedness to the unfamiliar (so essential for creativity).

Pedagogy

What I cannot create, I do not understand. ~ Richard Feynman, written on his blackboard at the time of his death.

What practical approaches can you take and what activities can you plan to reflect the rich, diverse and ever changing world of coding?

As a teacher, we hope you can cultivate and embody certain attitudes:

• Encourage your students to imaginatively explore the core concepts for their grade. They impart and reveal the family resemblances.
• Ensure they add content and updates about their project's progress: evidence of their journey, learning and attainment.
• Enlarge their view of the project: it's a vehicle for exploring, refining and rejecting approaches, not a finished product or right answer.
• Embrace mistakes and work the problems. Students should reflect on and record mishaps. Treat them as evidence of learning, growth and mastery.
• Expect acumen when students evaluate the innumerable resources found online (that explain the core concepts). Cultivate discernment, judgement and analysis.

Didactic chalk and talk or monkey-see-monkey-do styles of teaching are often useful, but for the best results, integrate, adopt and adapt the activities of coders, while emphasising exploration, imagination and creativity.

Why not consider using or blending the following activities in your classroom..?

Pair programming

A "pilot" types in code with a "co-pilot" who watches, comments and checks. The roles are often swapped during a coding session.

This technique encourages analysis, co-operation and sharing ideas. It's a common technique coders use for mutual learning because of its discursive nature.

Code reviews

Read another's code to understand how it works, offer feedback and suggest improvements. Cultivating an appraising eye for your own and other's code is how a codebase and coder improves.

Giving constructive and supportive critique is a valuable (and transferable) skill for affirmative collaboration.

A fun variation is "sabotage", where student A deliberately breaks code from student B, and passes the code to student C who tries to fix it.

Rubber ducking

Sometimes, when working on a project, coders get stuck in a rut and a change of perspective is required.

This is where rubber duck debugging comes into play...

1. Beg, borrow, steal, buy, fabricate or otherwise obtain a rubber duck (bathtub variety).
2. Place rubber duck on desk and inform it you are just going to go over some code with it, if that's all right.
3. Explain to the duck what you code is supposed to do, and then go into detail and explain things line by line.
4. At some point you will tell the duck what you are doing next and then realise that that is not in fact what you are actually doing. The duck will sit there serenely, happy in the knowledge that it has helped you on your way.

If no rubber duck is available, a colleague, classmate or other fellow coder will do just as well.

Lightning talks

Present an idea, project, or technology to others in a limited amount of time (no more than 5 minutes).

Coders often have to present their work to others, and lightning talks are a common way to do this.

Five slides in five minutes is a simple format:

1. Set the scene. Explain the context, actors, situation.
2. Here's the problem. What needs addressing?
3. Our story. Describe engagement, research, encounters and findings.
4. The outcome. A product, solution, failure or lesson to learn.
5. The future. What's next, answer questions or a call to action.

Code dojo

A code dojo combines collaborative programming, code reviews and lightning talks. If done well, they're a fun opportunity for mutual teaching and learning.

Participants work in small groups, for a fixed period of time, on separate responses to the same coding task.

At the end each group: presents their response, explains their code, answers questions, and receives feedback from everyone else.

Taking on a task and then seeing various responses to the same task from others ensures different approaches are compared, contrasted and evaluated.

User experience evaluation

Engage with users to learn if a project is valuable, easy to learn and a joy to use. Do this before, during and after the development process, then revise.

No amount of beautifully written code will improve a project if folks can't use it.

It is a humbling experience and a privilege to engage with the people for whom you write code. Their honest feedback is a gift, and empathy for users is a fundamental attribute of any effective coder.

Kanban / User stories

Organise learning tasks or student projects using common agile development techniques.

A user story describes something that needs doing from a certain point of view ("As a teacher, I can set students homework so that they can read it online").

Stories are often written on cards, assigned to someone and placed in columns on a Kanban board. The column in which the story finds itself indicates the story's current state ~ planned, in progress, in testing, done, blocked. The board gives an at-a-glance view of progress, problems and personal accomplishments within a project.

Planning and writing software is a complicated endeavour, and such techniques are widely used in industry to coordinate, facilitate and track progress.

Tests

Write tests for code, as code. They automatically show your code behaves correctly, force you to think about how your code works and (most importantly), make it easy to change your code with confidence that problems will be flagged.

There are many types of test that can be automated:

• Unit tests exercise small fragments of code (such as individual functions). If you're learning Python, PyTest is a good place to start.
• Integration tests ensure the different individual parts of a project work together.
• Functional tests are used to check code behaves in a way that matches the (often non-technical) requirements.
• Performance tests confirm that code behaves in an acceptable way given certain expected and/or unusual situations.

Some types of testing are manual:

• User acceptance testing checks that the code or project behaves in a way that works well for the end user. This may include checks relating to accessibility.
• User journey checks prove that the core use cases and features function as expected (example).

Documentation

Documentation is written for humans (so, please show empathy to your reader).

It is a fundamental aspect of your project, (and everyone will thank you for it). It's hard to discern use, context or intent, when all you have is opaque code.

Documentation can be (but is not limited to): Commentary submitted by a candidate on CodeGrades. Explanatory prose in code. Files included with code (e.g. README.txt). Technical documentation about the project. User documentation for using the project.

When adding comments to code answer "why?" rather than "what?" (the code tells us that already).

Need more guidance? Connect with a wonderful community of documentation practitioners called Write the Docs.

Gardening

A fertile attitude is to treat coding like gardening:

• Know your aims.
• Have a rough plan.
• Cultivate rather than control.
• You're not the only one in the garden.
• Small changes, carefully taken, soon add up.
• Pragmatic flexibility counters immovable obstacles.
• While you may plant a seed, it might not grow as expected.
• Change is inevitable and never as predictable as you may think.
• Use the right tools for the job (don't do weeding with a lawn mower).

Open Source

Open source means the source code for a project is available under a liberal license approved by the OpenSource Initiative (of which CodeGrades is a member).

When approaching a task, the first thing any good coder asks is, "surely, someone has done this before?" Open source ensures coders can answer this question with example code to re-use or adapt.

But "open source" is also an attitude that values sharing, openness, collaboration and respect for the rights and efforts of creators.

Can we teach such values and embody them as a teacher?

We at CodeGrades believe so.

Why not..?

• Collaborate with colleagues and build a supportive community of practice.
• Reveal and reflect upon your work as a teacher (like these wonderful teachers).
• Share and reuse educational resources (like this music teacher does).
• Ask yourself, "surely, someone has done this before?" (Don't be surprised if you find yourself talking to colleagues who are music teachers, modern language specialists or dance instructors).
• Finally, be open... for together we enrich each other's world. That is the essence of what we do here at CodeGrades.