I think a good exercise (the task we tackle as a group each day) has the following characteristics:
(Don’t agree with this list? Chime in here: What makes a good exercise?).
Given the above, what are your ideas for good exercises?
Here’s one idea: Choose a community-supported code quality tool and/or linter (such as Rubocop for Ruby), and apply it to your codebase, or a portion of your codebase. Pick a single file (preferably one with good test coverage), and fix all the errors.
I can imagine an exercise around adding/updating documentation for a package’s public classes and functions.
Maybe tasks that apply design principles (or even just identifying them in your codebase, with the “exercise” more about one’s justification for needing to apply it in the first place)?
Alternatively, you could just fix a single class of errors (hash rocket syntax); I’ve run into long legacy files with > 1k Rubocop violations. 
You could maybe write 1 new test for your application that were not there before. Or maybe start testing your code.
Add an automated check for code quality to your pipeline. It could be git hooks, CI steps, test suite specs, automated linter enforcement, etc. These kinds of additions can typically be easy wins that can provide long-term leverage over specific quality issues one by one. You can start with basics and proceed to more advanced rules as the project/team grows and matures.
For example, once I was on a team with a fresh bootcamp graduate who used binding.pry for debugging and would often forget to delete those lines before committing and pushing the changes. After about a week of this I wrote a git hook for him to install that would grep the project directory for lines containing binding.pry and fail if any were detected. He stopped committing debug statements and was able to get more meaningful work done faster from that point on.
Recently, we standardized adding some general code quality checks like rubocop linting and brakeman security analysis, as well as dependency scanning for CVEs, as steps in our CI process. Now we don’t waste time nit-picking code style issues in code review, we get early detection of potential security mistakes, and we automatically get persistent notifications across several projects when a ruby gem needs to be upgraded for production security.
Pick a project dependency (Gem, Node package etc) and update to latest pre version, filing bug report(s) or pull requests as necessary. Development only of course, no need to deploy live.
I like this suggestion. Something like creating a set of tests for a class or module or method would be a solid improvement.
Find one implicit input in a function and make it explicit.
Make a function side effect free or stateless.
Completely remove one dependency (might be too hard?)
Find a flaky test and open an issue or PR to fix it.
Find an old language feature and replace with a newfangled one.
Make one old file pass your linters.
Document something that needs documenting.
Replace some giant if/else logic with something better.
Make a vague method name clearer.
Write a test for something that needs it.
Take a 30 minute walk outside.
I like the ideas of creating adequate tests for some code and I also want to add the proposition of a task to optimize a particular functionality (speed, memory, etc.)
I 'd like specific exercises or missions, and I imagine them related to:
A few random ideas:
Something that is super useful is to setup a script to plot the complexity / Git churn of a codebase.
The process is describe [here]https://www.agileconnection.com/article/getting-empirical-about-refactoring) by Michael Feathers, author of Working Effectively With Legacy Code. A book that every developer working in a team should have, imho.
There are different ways to define complexity. A super simple starting point could be lines of code. You could then build on top of it adding number of dependencies, cyclomatic complexity, etc.
Thanks for this comment; it motivated me to go install a pre-commit hook to run PHP_CodeSniffer on my app 
You could try to find unused files, classes, or methods and remove them. There seems to be tools or IDE supports (vulture, PurifyCSS, IntelliJ IDEA) to find unused classes or functions. You could also remove chunk of code block that has been commented out.
You could try to remove warning at compile time or on runtime.
I like the idea to play with design patterns. For example, find places with many if statements and replace them or, at least reduce the amount. Or split code into modules/services for better testing.
If you don’t do caching already, set it up so it’s easy to do later. This should only take about 20 minutes if you’re using a library like Rails, Django, or Laravel. If you already do caching, find an area of the app that isn’t cached well and improve it.
Do you have resources that are being cached separately for each user or for different parts of the app? Find a way to share the same cache key by hiding buttons with CSS and localising dates and times with JavaScript.