I think this kind of thing makes so much more sense than hackathons in just about every way. It encourages truly positive habits that are, as you described, easy to let fall off without peer reinforcement. Refactoring is also probably the part of programming where peer involvement can have the greatest impact. The nascent stage of a project kind of seems like the worst time to get so many people working together. It's often a better outcome with just one or two people hacking away at something in relative solidarity at the beginning.
When time is scarce, it also seems to make a lot more sense to hack on existing projects where the first hours are not going to all go towards configuring Webpack. Most of the best time will be spent on the most important part—writing maintainable code.
Great point -- "The nascent stage of a project kind of seems like the worst time to get so many people working together. " Agreed. Devs need time to formulate their own opinions and approach especially when there's nothing running yet.
I think peer involvement is particularly important in refactoring as a way of helping each other validate their approach. Also, like "normal" pair programming, it's a way to keep each other on track at the task-at-hand. It's really easy to get into rabbit holes as you refactor and suddenly have a whole bunch of things in a half-refactored state. The social aspect can mitigate that.
Oh yeah, definitely. One frustration I run into with pair programming on feature building is that we often hit a wall where there is some research that needs to happen or some issue that is more comfortably worked out in solitude (depends on your personality, of course). With efforts of pure refactoring, everything is already "done" in a sense, so there is less likely to be that progress wall that has lead me towards the tendency breaking off and working through issues on our own.
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.
I think this kind of thing makes so much more sense than hackathons in just about every way. It encourages truly positive habits that are, as you described, easy to let fall off without peer reinforcement. Refactoring is also probably the part of programming where peer involvement can have the greatest impact. The nascent stage of a project kind of seems like the worst time to get so many people working together. It's often a better outcome with just one or two people hacking away at something in relative solidarity at the beginning.
When time is scarce, it also seems to make a lot more sense to hack on existing projects where the first hours are not going to all go towards configuring Webpack. Most of the best time will be spent on the most important part—writing maintainable code.
Hey Ben,
Great point -- "The nascent stage of a project kind of seems like the worst time to get so many people working together. " Agreed. Devs need time to formulate their own opinions and approach especially when there's nothing running yet.
I think peer involvement is particularly important in refactoring as a way of helping each other validate their approach. Also, like "normal" pair programming, it's a way to keep each other on track at the task-at-hand. It's really easy to get into rabbit holes as you refactor and suddenly have a whole bunch of things in a half-refactored state. The social aspect can mitigate that.
Oh yeah, definitely. One frustration I run into with pair programming on feature building is that we often hit a wall where there is some research that needs to happen or some issue that is more comfortably worked out in solitude (depends on your personality, of course). With efforts of pure refactoring, everything is already "done" in a sense, so there is less likely to be that progress wall that has lead me towards the tendency breaking off and working through issues on our own.