What should I do when my co-founder's code makes me want to refactor?

Hey man, this problem is so real; I'd estimate over half of all tech co-founders have encountered it. You're actually in a better position, at least you're thinking about refactoring; some might even want to rewrite it entirely (just kidding).

Handling this requires a bit of tact. After all, this person is a co-founder, not just a regular colleague, so the relationship is more important. Directly saying "your code is terrible" definitely won't work; it'll hurt feelings. Secretly changing it yourself is even worse, like a backstab. That won't work either.

Here are a few suggestions you can try:

Step One: Calmly assess first – is it "can't stand it" or "truly broken"?

• Just "can't stand it"? For example, their coding style, naming conventions, or implementation logic might be different from yours, but the functionality is normal, and there are no performance issues. If this is the case, I advise you to "bear with it." In the early stages of a startup, survival is paramount. As long as the product works and can iterate quickly, that's what matters. Inconsistent style is a minor issue; you can unify it gradually when you have time later.
• Truly "broken"? For example, the code has obvious logical flaws, performance bottlenecks (it lags when too many users come online), or extremely poor extensibility (adding a small feature requires changing a dozen files and is prone to errors). If this is the case, it absolutely must be changed, otherwise, you're just planting landmines for the company.

Step Two: If it's "truly broken," find a "legitimate reason" to communicate.

The key is to address the issue, not the person. Don't point the finger at your co-founder; instead, point it at the "problems" caused by the code itself.

• Under the guise of fixing a bug: "Hey, I noticed that recent XXX online issue seems to stem from this piece of code. See, if we restructure it, not only can we fix it completely, but we can also avoid similar problems in the future."
• Under the guise of launching a new feature: "Aren't we building the YYY feature in the next version? I looked at the current code, and adding it directly would be very awkward and prone to new bugs. How about we spend some time refactoring this part to pave the way for the future? What do you think?"
• Under the guise of performance optimization: "Recently, that backend API feels a bit slow. I analyzed it, and the bottleneck is mainly here. I have an idea; we could change it to the XXX pattern, and performance would likely improve significantly."

See? The entire conversation revolves around "product issues" and "future plans," not "your code has problems." This makes it much easier for the other person to accept.

Step Three: Let facts speak for themselves, "show off a little" on a small scale.

Talk is cheap. You can first refactor a small, critical piece of code on your own branch according to your ideas. Then, present the results to him, for example:

"Look, I refactored this piece of code with a new approach. The lines of code are reduced by 30%, unit test coverage increased to 90%, and it runs 20% faster. How about we proceed in this direction from now on?"

When he sees tangible benefits (more stable, faster, easier to maintain), any reasonable engineer would find it hard to refuse.

Step Four: Look to the future, establish "team rules."

This is the most crucial step, as it can solve the problem at its root. Find a time to calmly discuss together:

"To ensure smoother collaboration between us in the future, and also for any new colleagues who might join to get up to speed quickly, should we establish some 'code standards' together? For example, uniformly use a code formatter (like Prettier, Black), and agree on some basic naming rules and directory structures. This way, everyone's code will look like it was written by one person, and it will be easier to maintain."

Elevate the "your style" versus "my style" debate to the level of "team engineering standards." This way, it's no longer a personal conflict but for the good of the company. Once standards are set, everyone follows them, and no one can criticize anyone else.

In summary:

When co-founding a startup, people are always more important than code. The core idea for handling such problems is: address the issue, not the person; communication is paramount; unity trumps everything. Don't let a few lines of code damage the camaraderie between partners; that would be the greatest loss.