Learning How to Stop Changing Software

I’m tired of pull requests with ten thousand lines of code changed

I’m sure many people have this thought about wanting to change X, Y, and Z on top of their current work. Even though it’ll be beneficial, it’s not a great way to write software. I mean fuck, we all advocate for iterative development, so why are we creating multiple significant changes in one step.

It pains me to say, but at some point, you have to cut losses and let it be. Don’t upgrade that library. Don’t refactor that code. Don’t do it, and stay a bit on track.

Take a win for relevant parts of changes.

I’ll state the obvious before I advocate not improving your code base.

I’m lazy as fuck.

However, engineers fall into the trap of changing everything that bothers them instead of letting it go. The problem is you increase the chance of something going wrong with every change made.

And it’s not always obvious what ends up being wrong, but it makes things painful.

For example, let’s say you release a new feature while upgrading a library with an unexpected error that needs to be rolled back. Well fuck, now you have to roll back and change something. You may lose the X feature unless you…