"How do we communicate enough for the hack team to know what to work upon but still have free reign to come up with great ideas?"
I may get some disagreements here, but I think there are actually a lot of refactoring approaches that are preferable to be done by people more new to the code. For one thing, naming comes to mind. It's a lot harder for me if I'm so comfortable with the domain to assess whether my classes, properties, etc. are expressive as they could be. I might automatically look at a class like "Notifier" and go..."oh yeah that's the thing responsible for sending out Slack messages", whereas a fresh set of eyes might look at the name more critically.
You also make a great point about professional codebases -- there are certainly diminishing returns if you have, say, a massive 20-year old codebase and you have a room full of fresh devs for 2 days. Perhaps there's a right "type" of codebase where a refactorthon works best -- something that isn't brand spanking new but maybe in an early release cycle or an MVP state. Something that's far enough along to have built some instantly recognizable cruft, but isn't so far along where you'd have to spend weeks ramping up.
As far as what's in it, I think the mere exercise of examining and rehabbing code is most of "the fun". I think everyone would learn a ton in the journey moreso than the end result.
I think more professional codebases will wind up being open source in the future. If your product is not the code itself, and it rarely is, there is little sense in closing it off. In the short term, it still makes practical sense to keep things closed, but I think things will trend towards openness.
We plan to make this website, dev.to, open source, and I'd be game to try something like this even before we get the open source project out the door. I've been itching to get some total outsiders to look at some of my decisions and criticize, ask good questions, and help us clean up the gunk.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great points Charles!
Addressing a few:
"How do we communicate enough for the hack team to know what to work upon but still have free reign to come up with great ideas?"
I may get some disagreements here, but I think there are actually a lot of refactoring approaches that are preferable to be done by people more new to the code. For one thing, naming comes to mind. It's a lot harder for me if I'm so comfortable with the domain to assess whether my classes, properties, etc. are expressive as they could be. I might automatically look at a class like "Notifier" and go..."oh yeah that's the thing responsible for sending out Slack messages", whereas a fresh set of eyes might look at the name more critically.
You also make a great point about professional codebases -- there are certainly diminishing returns if you have, say, a massive 20-year old codebase and you have a room full of fresh devs for 2 days. Perhaps there's a right "type" of codebase where a refactorthon works best -- something that isn't brand spanking new but maybe in an early release cycle or an MVP state. Something that's far enough along to have built some instantly recognizable cruft, but isn't so far along where you'd have to spend weeks ramping up.
As far as what's in it, I think the mere exercise of examining and rehabbing code is most of "the fun". I think everyone would learn a ton in the journey moreso than the end result.
I think more professional codebases will wind up being open source in the future. If your product is not the code itself, and it rarely is, there is little sense in closing it off. In the short term, it still makes practical sense to keep things closed, but I think things will trend towards openness.
We plan to make this website, dev.to, open source, and I'd be game to try something like this even before we get the open source project out the door. I've been itching to get some total outsiders to look at some of my decisions and criticize, ask good questions, and help us clean up the gunk.