Follow Suit

The very best developers always follow suit on any existing codebases.

The expression ‘follow suit’ comes from card games. If the last card was a Spade, you follow with a Spade. If instead, the last card was Clubs, you follow with Clubs.

In coding, it means that if there is an already existing codebase, with a bunch of styles, conventions, idioms, paradigms, and dependencies, then any code that you add will fit in perfectly. That is, it leverages any underlying existing code, looks the same as all of the other code and is in the correct architectural location.

Why is this important?

If the code is a pile of different conventions, styles, etc. it is nothing more than a mess. So, if you go into a codebase and make even more of a mess, although some of your contributions are positive, overall they are negative. You’re not helping.

Messy code is always really buggy code, annoying to the users, and is stupidly expensive to fix or extend.

Now, it is true that if you don’t follow suit, you can save yourself lots of time and get right down to work. But while that is time you saved for yourself today, it is also technical debt that you just dumped on someone else. Professionally, pushing your problems onto other people so you don’t have to deal with them is not acceptable.

The other thing is that if you rewrite 3 months worth of work that was already done, completed, and tested, you have just wasted 3 months of time. You’re not moving the project forward, you’re just making it inefficient.

Now if you have personal preferences for say a particular coding style, it is essentially subjective. Get out of your comfort zone, and at least try the other style. Maybe it’s better, maybe it’s worse, but if you can only code one way, then you are a rather limited one-trick pony, which isn’t so great for your career prospects.

If you are the first coder into the codebase, you have a choice of ‘suit’. But if you are not first, you do not have that choice, so don’t pretend like you do.

It may be that some of the things in the code, like its idioms, are new to you. That is a good thing, a chance to learn, not a reason to avoid it.

Now if you believe the other code is “wrong” then now you are actually obligated to fix it. All of it. So, it’s not a good idea to judge some work if you are not going to have the time or ability to redo it. It’s not “wrong”, it’s just code and it follows a particular convention, and you need to follow suit. If you’ve developed a hate-on for a particular way of doing things, that is your issue, not a coding one, you should try and fix yourself.

In some cases, the codebase does have legitimate issues that really do need correcting. If you set about to correct them, you can’t just do so locally, that creates a mess. You have to do so for the entire project, across the whole codebase. Not only is that a lot of work, but you also have to get agreement from any other coders on the project, and management, to back the time necessary to do the work. It is entirely possible. it is good practice, and while it is often mundane and boring, that type of refactoring is a very strong skill. In most large codebases, there is a lot of cleaning up that really should be done, but people are avoiding it. Obviously, it can’t just be a subjective quirk, you need to have solid reasons why spending the time to make these changes is worth it.

In the case where the code is just an unrepentant mess, the best practice is to pick one of the many suits that are already there and get everyone to agree that it is the best one. Then, wherever you go in the mess, if you touch a file, you are now responsible for updating it. Slowly, that will bring down the degree of messiness, until the last bit of effort is finally tangible. While it takes a long time and is slow, you are not avoiding it, so you are still acting professionally.