Be willing to learn

One day we've all written suboptimal code. Maybe it lacked decomposition, maybe there was some misleading naming, or the code was ready to blow up on the first edge case. It usually happens due to a lack of experience. And it is totally fine. What's not fine is when a developer continuously writes this code, applying bad practices to every project he/she touches without thinking something's wrong.

In such a case, every party suffers. The company spends more hours fixing bugs and adding new features. Moreover, other devs may not understand the code if the guy suddenly disappears. The product owner gets a buggy product with vague development prospects. The developer has fewer opportunities to find another good job if the recruitment process is done right during the tech interview.

There might be several reasons for this:
- Developer has never seen good code, and nobody has ever reviewed his/her projects, so a developer doesn't know what good code feels and looks like
- Developer doesn't want to learn new stuff and try something unknown

The first scenario is not that bad. You can always ask your more experienced colleague or some senior dev from the community to review your project. I'm always happy to help and share my approaches with anybody from the community if it'd make their life a bit easier and code - more maintainable.

The second scenario is much worse, but I can understand these people. If you're a freelancer or your company is satisfied with your work, and you're comfortable with your code, then there is no reason to change anything until something blows up (which will be an unpleasant surprise for all parties mentioned above).

So what's the point?
The point is that it doesn't work this way in our industry. If you want to evolve as a developer to have more career opportunities to work on something that matters to you and millions of people => you should always look for ways to improve your practices and make the development process more predictable.