Some of the "best practices" that you learn in school aren't practical or cost-effective on real-world projects. One of the biggest changes I noticed was in formatting and comments. Most of my professors stressed the importance of extensively documenting your code, but in the real world, good code is often self-explanatory, and more importantly many bosses don't want to pay for you to spend extra time writing comments.

You'll sometimes see programmers who are pressed for time using shortcuts and anti-patterns that require less boiler-plate than quality solutions.

However, one of the biggest problems I've noticed on many teams and projects is an unwillingness to learn new things. Many of the older programmers I've spoken with got their careers started in a 'Wild West' period of software engineering when qualifications started and ended with willingness to write code. They often majored in completely different fields, and jumped into programming with little or no formal education when an opportunity arose (e.g. their employer didn't have a programmer and needed someone to learn in order to build in-house software). Some of these old-school self-taught programmers never make the effort to learn modern coding practices, and continue to code in roughly whatever style they learned decades ago. When they end up in charge of new projects due to seniority, they tend to hold the projects back and harm overall code quality.

Of course the above does not apply to all older programmers, and newer-generation coders can be just as guilty. I've worked with many younger programmers who picked up a few tools and libraries fresh out of college and then stopped learning completely. They'll download an IDE or library once and never update it unless their company requires it (you can sometimes guess what year a programmer graduated based on how out-of-date his libraries are). They don't keep up with new features in their language(s) of choice, and never learn new languages. They don't learn new programming strategies, and may misuse patterns or paradigms because they don't know more appropriate alternatives (oh MVC, how heavily thou art abused). As time goes on, their workflow becomes more and more outdated, and they become more of a liability than an asset.

In summary, two of the biggest causes of messy codebases are rushed deadlines and programmers with outdated or incomplete knowledge. Unfortunately, responsibility for both issues can fall heavily on the boss or CTO, who must ensure that deadlines are realistic and that staff are up-to-date on their knowledge and skills. If the boss doesn't know anything about good programming practices, the best you can do is try to suggest changes and hope they are open to suggestions. Unfortunately, they may be inclined to trust the word of a more senior programmer who doesn't understand OOP and likes to write 10,000 line classes.

Some of the "best practices" that you learn in school aren't practical or cost-effective on real-world projects. One of the biggest changes I noticed was in formatting and comments. Most of my professors stressed the importance of extensively documenting your code, but in the real world, good code is often (not always!) self-explanatory, and more importantly many bosses don't want to pay for you to spend extra time writing comments.

You'll sometimes see programmers who are pressed for time using shortcuts and anti-patterns that require less boiler-plate than quality solutions.

However, one of the biggest problems I've noticed on many teams and projects is an unwillingness to learn new things. Many of the older programmers I've spoken with got their careers started in a 'Wild West' period of software engineering when qualifications started and ended with willingness to write code. They often majored in completely different fields, and jumped into programming with little or no formal education when an opportunity arose (e.g. their employer didn't have a programmer and needed someone to learn in order to build in-house software). Some of these old-school self-taught programmers never make the effort to learn modern coding practices, and continue to code in roughly whatever style they learned decades ago. When they end up in charge of new projects due to seniority, they tend to hold the projects back and harm overall code quality.

Of course the above does not apply to all older programmers, and newer-generation coders can be just as guilty. I've worked with many younger programmers who picked up a few tools and libraries fresh out of college and then stopped learning completely. They'll download an IDE or library once and never update it unless their company requires it (you can sometimes guess what year a programmer graduated based on how out-of-date his libraries are). They don't keep up with new features in their language(s) of choice, and never learn new languages. They don't learn new programming strategies, and may misuse patterns or paradigms because they don't know more appropriate alternatives (oh MVC, how heavily thou art abused). As time goes on, their workflow becomes more and more outdated, and they become more of a liability than an asset.

In summary, two of the biggest causes of messy codebases are rushed deadlines and programmers with outdated or incomplete knowledge. Unfortunately, responsibility for both issues can fall heavily on the boss or CTO, who must ensure that deadlines are realistic and that staff are up-to-date on their knowledge and skills. If the boss doesn't know anything about good programming practices, the best you can do is try to suggest changes and hope they are open to suggestions. Unfortunately, they may be inclined to trust the word of a more senior programmer who doesn't understand OOP and likes to write 10,000 line classes.