I've just left a project after working on it for a bit over 2 years. For my former employer this project represents a significant investment and will be probably their most critical business system when it goes live. There's a lot of stuff I like about what I achieved on that project. However when I think about the system what I am generally considering is what could have been done better and how I would approach a similar problem is asked to do so again. This can appear quite negative at times which is never my intention. It's only by critiquing what you have done that you can hope to improve.
Being critical of something you have built doesn't preclude having pride in your work. All software systems are terrible in some fashion. Yet software delivers huge value to people and organisations every day. Ultimately many concerns of developers are of no interest to the end users. Indeed developers exist to be concerned about a lot of things that end users don't want to have to care about. Software that doesn't deliver value to end users should not exist.
Critiquing your work ultimately helps you deliver more value to end users (and hence means you're more likely to stay employed/get promoted/get a better job). Identifying the pain points in your system means you can consider whether there's value in resolving them. Knowing where to do better means you can deliver more value in future. Being aware of potential risks means you can manage them appropriately. This gives end users better outcomes and likely reduces your own stress and workload.
I'm sometimes surprised by how many developers keep doing the same things over and over even though their approach is painful, slow and risky. My favourite small example of this is one company that was using a CMS product that required full paths to particular directories in its configuration files. Unfortunately different developers on the team had different paths for these directories and the nature of the hardware meant this couldn't be standardised. The result was if you modified the configuration files (a semi-frequent activity) you had to be careful not to overwrite these paths and there was a constant risk that if you pulled the latest version from source control an incorrect path would break your environment.
This was an obvious pain point with a clear solution. A relatively simple script could be written to customise the configuration files for each developers machine during the build, ensuring they had valid configuration files. This is a fairly simple thing to do but I faced a surprising amount of skepticism and had to do rather more arguing than I should have to fix this rather glaring hole in the development process. Indeed the arguing took longer than the initial version of the script took to implement. But once done that problem never reoccured. This reduced the risk of builds and saved small amounts of time for each developer every day. This change more than paid for itself within a couple of weeks and made additional things easier in future. Yet it was only because I was willing to be critical of what we had created that it happened.
This is not to suggest that I was a star developer working with incompetents. It's just in this case I got sick of the extra work and decided to be proactively lazy to eliminate it. The result was better for me, better for the team and through increased productivity better for the client. You won't get this outcome if you berate people for touching "your" code (I've had this happen, I don't think I've ever been angrier in a professional context). It's not your code, the code exists to deliver value to end users. Critiquing your own code is the first step on the path to realising that.