One bit of programming advice I would give myself is, on large projects, ensuring that appropriate constraints are in place is more important than functionality

One bit of programming advice I would give myself is, on large projects, ensuring that appropriate constraints are in place is more important than functionality. You want to be able to come back to an area of code after a few years (without looking at it) and everything that has been added should still make sense. Patterns that you don't want to see should be hard to do - the natural inertia will stop it from happening. Designing things that "allow people to do anything", while seemingly a benefit, end up causing a lot of problems in the long run. A reasonable argument might be that it should be watched / policed but this is harder in practice than in might seem. A lot of orgs are fairly decentralized, meaning that no central entity can make the call (probably a good thing imo). If appropriate constraints are designed into the system this kind of energy sapping discussion will not even need to happen in the first place. Essentially, adding constraints at t0 adds degrees of freedom in the future. Coding is a bit like a garden - you need to ensure that the garden makes sense as it grows.