How we will evaluate our success of failure?

I consider it’s important to measure our progress, so how could we measure our progress on:

  1. Daily task or exercises?
  2. At the end of the 30-day challenge?

My work quite often consists of facing a huge existing mess to make it suck less.

Here are typical signs that I consider to be progress in right direction:

  • less code, code is liability, the less code there is the less things go wrong with it;
  • less bugs, volume of bug/issue tracking is strategically going down, not up;
  • smaller pieces, smaller files/components enable easier and faster workflows;
  • solid APIs, internal implementations should use same facilities as third party extending the code base (if relevant).
2 Likes

If you’re working on the same code base all month, maybe keep a tally of how many times you go “huh?” in a day. With any luck, that should plot a nice downwards graph.

3 Likes

I’d say it depends pretty strongly on the task itself. Something like increasing code coverage has a very direct metric that it can be measured with, but something like an updated README doesn’t. I would say this might shape the form of tasks we take on specifically for this reason, as a task that cannot easily be measured is a bit more tough to do. Some metrics I can think of:

  • Code Coverage %
  • External services depended on during tests
  • Classes / methods with documentation
  • Project build / test suite execution time

Can you please clarify this question?

Do you mean your success or failure at the entire challenge, a specific exercise, or more generally?

Friend I also didn’t understand your question :thinking: