[trevyn]

I’ve often wondered about a twisted form of asynchronous “pair” programming: One person codes quickly, creating mediocre code that achieves the goals, the other person cleans the code up and modularizes it.

I’m drawn to this because they are two different mindsets that achieve somewhat conflicting goals, and the tasks can be separated with minimal communication overhead.

Thoughts?

[gurkendoktor]

I just left a project after I was unable to make peace with being the cleanup guy for an endless, never-improving stream of mediocre code. I am convinced that it's faster to write solid code in the first place.

Once there are two or more interacting layers of code, it gets really hard for the refactoring to catch up. If you fix a bug in a basic layer, the leaves of the codebase break. If you fix a bug in the leaves, you never get to refactor the core. If you want to stop the world and refactor everything at once, you get in the way of your quicker counterpart.

Or think of a multithreaded codebase without any synchronization. It definitely works well enough for demoing an "almost finished" product, but cleaning it up requires a lot of time and can introduce temporary regressions (deadlocks) that are worse than the bugs that the cleanup is supposed to solve (very spurious data corruption). It's a bit like the bullshit asymmetry:

https://twitter.com/ziobrando/status/289635060758507521

Ruby on Rails (from the OP) makes it easy to build many kinds of maintenance deathtraps.

[alextheparrot]

I see this often in a slightly different context - people who write libraries well and people who write application code well. One tends to be generalized, focused on end-user ease of use, while the other is first and foremost attempting to achieve business goals with the available tools.

[hinkley]

Eventually you feel like a janitor or a babysitter.

The problem is that the guy making the mess gets credit for things and the guy cleaning it up keeps bad things from happening because of him. If your boss is not just the right type then you will become the bus tribute.

[JoeAltmaier]

I worked like that with a colleague of a decade in a startup environment - we produced tens of thousands of lines of embedded code in a year. It can work with a close understanding between the two people.

[hindsightbias]

There used to be a time where every new coder spent a couple of years learning/maintaining their elders' code - fixing bugs, porting, optimizing, learning about how the environment(s) integrated. The concept of journeyman in sw was a thing, and mgmt/team expectations from the youts was appropriately gated.

Now it's different (outside of HW orgs), but as I look out a decade or so, I'd rather have a part-time retirement job "cleaning up" interesting projects than travel/consulting.

[pavel_lishin]

I've done this very frequently on pet projects - except I'm both people. There are projects I have where I'd grab a drink, and bang something out for a few hours in the evening that works - and then, in the cold, sober light of day make sure the underlying ideas are still sound and refactor it to make it more readable.