How is progress defined?

On our software development course, we set milestones along the way so everybody knows what is expected and how to meet those expectations. Volunteers and trainees should use milestones as an opportunity to check in and self-assess progress at key points in the course.

We set these milestones by looking closely at successful and unsuccessful graduates and making guesses about measurable factors in that success. (See the term definitions to understand what we mean by success.) They are informed guesses and we test and revise them a lot based on new information, which we share as much as possible.

What is a milestone? A milestone is a point on the course. At that point, we check a series of milestone factors.

Milestone Dates

We set ten milestone dates on our course.

  1. Start

  2. HTML-CSS Week 1

  3. JS1 Week 1

  4. JS2 Week 1

  5. JS3 Week 3 <= specialisation

  6. React Week 2

  7. Node Week 2

  8. Databases Week 3

  9. Final Projects Week 2

  10. Post Graduation


We currently check these five factors:

  • Attendance - as shown

  • Codewars - Rank as shown

  • Codility - 1 for a test being issued, 2 for taking the test, 3 for scoring

  • Pull Reqs - rounded to 1 per week

On each milestone date, we check a trainee’s numbers against each milestone factor. Each check returns a value:

1 - behind milestone

2 - at milestone

3 - beyond milestone

We sum (add up) those returned values and check it against the milestone sum.

If the value is lower, the trainee is behind the milestone. If the value is the same, the trainee is at the milestone. If the value is greater, the trainee is beyond the milestone.

That’s how we measure.

As for why we measure, it’s so we can help everyone in the right way for them. We work with each trainee as an individual on their own journey towards a good job in tech. Milestones are to help everyone understand our progress. All trainees agree to meet their milestones as part of their Trainee Agreement, so it's important we all know how that is going.

If you’d like to read some more about this, I’ve included a story below, and defined some terms.

Case Study

‘Greg’ is on Week 3 of Javascript Module 3 in 2021

He has just reached 6kyu on Codewars, with 110 points. He completed around 28 kata, mostly level 7 and one or two level 6 to get to this rank. He has been set two Codility tests. He took the first one and felt he got most things wrong, so he didn’t take the second one. He has attended every class. He has submitted a pull req every week except this week - he hasn’t done that yet!

Let’s score Greg’s engagement against the milestone at this point in the course.





Pull Reqs











Codewars = 2

Codility = 1

Attendance = 3

Pull Reqs = 2

Greg scores 8, which is the milestone score, so he’s met his milestone. Well done Greg!

This model is not about being perfect, and it’s not about doing everything right every time. It’s not about competing against colleagues. It’s about Greg, and how he’s doing. It’s about showing up and taking part. Greg should have taken his second Codility test, particularly because all we ask at this point is that he takes the test, not even that he passes it. But he’s showing up to class, he’s submitting his coursework, and he’s managed his time well on Codewars so he’s in a good position to make his next milestone. So he’s looking like he’s coping on the course, and that’s what we’re measuring here in this automated way.

For more individual/personal progress in things like code quality or personal development, trainees work with mentors on their own development plans, of which this is just one factor.

Over time, we might be able to develop more factors that tell us more things to help everyone succeed. Watch this space!

Sub-term definitions: How is success defined?

Success Criteria

Last updated