I came up with this list:
- Language agnostic (equally applicable to people using a variety of programming languages).
- Completable in ~20 minutes.
- Improves the quality of the codebase.
- Fairly easy to understand.
Do you agree with this list? Should something be added or removed?
These are good. You had another one I thought was interesting: “Make something immutable.” I liked that one (and ended up applying it by chance later that day, because I was thinking about it), but it might help to give a direction, such as good candidates for immutability. Something like, “Turn off your WiFi and see what tests fail” is good because it’s clear and actionable. “Make something immutable” is super interesting, but I’d have to think a lot about which data structures might be good candidates.
The ability of receiving and giving feedback would be much appreciated.
I think the exercises should have a clear reasoning behind them. Perhaps that’s covered by ‘Improves the quality of the codebase’ but I would like there to be a clear-cut ‘why’ to them
I really enjoy exercises that can be used in the real world. This is a terrible example but I would rather build a credit card validator as an exercise than a tic-tac toe game. In terms of how the exercise should be layed out…No thoughts or opinions. Really curious to see what you come up with.
Outside the scope of this topic. But the idea is in my head now. A video course where you can pause the video and can view the current transcription of the speaker but also the current code written on the screen at that exact pause moment. Would have to write some type of program to save checkpoints every few seconds to make this work efficiently. Would change the game of video tutorials in my opinion.
Gotta say I agree with Charles. One of the nicest things about Clean Code was the reasoning provided behind the code style recommendations. Made it a lot easier to present to your team when you can say “methods with fewer than 40 lines have 86% fewer defects than those over 80” or what have you.
I, too, totally agree with @charles.bandes about the reasoning. A task can be very easily apprehended by the team if you serve it not only as a task, but also with an explanation of why this task would benefit all ("win-win"strategy).
I agree with @charles.bandes as well. The “why” of something is huge. Also really like @nick’s suggestion about refactoring something to be immutable. Maybe combine those two thoughts, and explain that we want to make something immutable because…and then go do it!
What would make a good exercise for someone like me, working for a company, with a team, and a roadmap to stick to, would be for the exercise to be small and simple.
I tend to work using the Pomodoro technique. Having exercises that can be tackled in 20-30 mins would be the best.
I’d be happy with exercises that highlight areas of improvement even if they don’t really act on them. @nick suggests to use linters like Rubocop, and later on to fix a single class of violations. That sounds great to me.
When working in a team this kind of exercises identifying areas of improvement could be great to share ownership and passion for improving the quality.
+1 to @charles.bandes’
I work with a team of other 8 developers, and we do code reviews. If I were to push a PR that makes changes to the codebase without making the reason why, and the benefit we’ll get out of it clear, it would probably be rejected.
Also +1 to @nick’s
In the context of having exercises/challenges that don’t take up too much time, so they can’t be postponed with the risk of not getting to them, being actionable would be key.
but it might help to give a direction, such as good candidates for immutability.
Either the exercises or the forum could give concrete things to choose from.
For the example of “Make something immutable”, that may be enough direction for some to go after. Others could come to the forum, where folks could post specific, concrete actions that are ideas they have or things they’ve done. For this example, folks could post “Looked for code where we reassigned a variable and split it into 3 separate variables.”