I can't just rewrite it

Until this summer, almost every codebase I cared about was mine.

The code wasn't always good, but I got the final say. If part of a project annoyed me enough, I could delete it on a Tuesday and spend the night building a version I preferred. I never had to explain why the rewrite was worth the risk, and if it went badly, the extra work was mine.

That freedom made me fast, but it also let preference pass as reasoning. When nobody else is waiting for an explanation, "this feels wrong" can be enough to start over. I could rename everything or move half the files because the new version made more sense in my head, and the project would bend around the way I thought, including the parts of my thinking that were wrong.

Joining Orchid put me in a codebase that already belonged to other people. It had users and a history I wasn't there for, with more context than I could hold in my head at once. A small change could reach behavior I'd never seen, so getting the part in front of me to work was only a start.

I noticed this most in review. One change I thought was basically finished came back with a timezone edge case, a validation path I had made too loose, two functions that were almost copies of each other, and a note about formatting noise. The feature worked, and none of the comments was dramatic, but the review made it obvious that my version of "done" was too narrow.

The annoying part is that strange-looking code doesn't always have a good reason behind it. Sometimes it protects behavior elsewhere, and sometimes it's simply bad. If I assume every old decision must be there for a reason, nothing improves; if I assume none of them are, I end up replacing things before I understand them. I used to avoid that uncertainty because I could just decide and move on.

This has changed my idea of being responsible for a project. On my own projects, deciding quickly felt responsible because nobody else was going to resolve the ambiguity. In shared work, the same instinct can become overconfidence. Imagining a cleaner version doesn't mean I understand the cost of getting there, so I have to find out why something exists and explain the problem clearly enough that another person can disagree with me. This sounds obvious written down, but it didn't feel obvious when I was used to making every final call myself.

At first I thought code review simply made me slower. A change can spend longer in review than it took to write, but solo work hides a lot of time by pushing it into the future. A rewrite feels quick when the migration work and future confusion get handed to a later version of me, who I always assume will be more patient than I am. Shared work doesn't let me hide those costs as easily because someone else can ask about them now.

I was less prepared for the fact that the work keeps moving without me. In a personal project, I can become the documentation by accident because I remember why a file has a weird shape and what I meant to clean up later. That feels efficient until another person needs to understand it. In a shared codebase, "I know how it works" isn't a useful guarantee; the work has to make sense to somebody who doesn't share my memory. That bothers my ego a little, but it's also a relief. I don't have to carry every piece of context forever, and the project doesn't depend on me remembering it.

I don't want to train the instinct to rewrite things out of myself. A lot of my own projects began because I looked at an existing way of doing something and wanted to try another one. I just can't use that instinct as proof that a rewrite is necessary.

I also don't want to make this sound like a lesson I've already learned. As I'm writing this, I've been at Orchid for less than a month, and I still see something ugly and immediately imagine replacing it. The difference is that there's now an annoying middle step where I have to find out whether it's ugly for a reason. Sometimes there is one and sometimes there isn't, but I have to look before deciding.

I still don't have a reliable rule for when to push for the rewrite and when to leave a working thing alone. I only know I was answering that question too quickly before.