Lol yes agreed completely. "Cleaning things up" before you understand the domain, codebase, and gotchas sounds like a highly unproductive way to get onboarded. I think suggesting that a new hire start week 1 by adding a whole bunch of metrics that add unnecessary overhead for the team and all users just to see "if something happens" is pretty bad advice, to the point of being something I'd probably wish I had screened at the interviewing stage.
One thing I like to do is go through everything in makefiles, and any commands in the readmes or documentation. In almost every case there's stuff that doesn't work, sometimes because it's out of date and you can fix it, sometimes you'll be missing some one-time-only configuration that everybody else already did so long ago they didn't remember to document it, sometimes the docs are just outdated so you can ask if it's no longer relevant and clean it up. And if you mess anything up it usually breaks very early the pipeline, the tests won't run against the dev branch or something like that.
"Cleanup tasks" will always be appreciated I am sure, but again I would caution that there is a trap here. It's easy to clean up any number of things as you go, and construct an illusion that somehow, you are being productive.
When I hire people, aside from fixing mistakes in the documentation they encounter, I want them to have all the time they need to learn, ideally with a set of curated onboarding tasks that progressively give them expertise in the system they are intended to operate in. There is a time to "make things better" and, in my opinion, that's after getting up to speed in a sense that lets me collaborate with the team in a productive manner. I won't begrudge someone the opportunity to clean things up, but each individual is the ultimate arbiter of how to be effective at the end of the day.
If you have the time to create a “curated onboarding experience that results in progressively more expertise”, yes I agree please do that instead.
I’ve never onboarded to a team that had such an experience, I’ve never heard of a team with something like it consistently, every time I’ve seen it proposed and tried it takes time away from an experienced person (who could have done those same tasks faster) and goes out of date as soon as one new teammate completed the curated set of tasks.
If you can make it durable, my utmost respect!
In the meanwhile, deleting obviously dead code has never failed me as a strategy for myself or a new hire (typically steered by a simple oncall-type task to start the investigation off).
And best part, there is always more to clean up for the next new hire lol.
I don't mean refactor everything or spend six months until everything is perfect. I've just found it's a pretty reliable way to find low hanging fruit and get an easy first commit in. "Get your feet wet" I believe is the English expression. You have to get familiar with the build process anyway, you might as well improve it while your attention is on it.
If you have a curated onboarding experience that's great, but then you'll probably have good documentation and nice setups, then my suggestion obviously doesn't apply. I wish that was common but in my experience that has been a rarity, not the common case.
