Someone else has to maintain your code in the future. Do them a favor.
When you’re supporting your team’s codebase, you become a little blind to some of the problems that exist. Because you have been a large part of the application’s history, you know all the system’s ins and outs. You know where to look to find any given piece of logic. Most importantly, you understand why the team made their decisions and what needs to change if new requirements come in.
Unfortunately, the person in the future who has to maintain the code doesn’t have any of these advantages. They get this crazy application dumped on them with no warning, and now they have to support it and add new features to it. For a complex codebase, this can be very difficult.
There are some things you can do today to help this future person out. Avoid writing spaghetti code. Keep things simple. Each method should have one purpose; break more complicated methods up.
Follow standard conventions as much as possible. Everything should have a standard place and programmed in a standard way. Follow coding standards and style guides. Use the most popular libraries and frameworks. Avoid tools built in-house when there are widely-used open-source alternatives available.
Document the reasons why functions exist. Write up why the team used one approach over other alternatives. These are the most valuable kinds of comments you can have in an application.