What you coded today will most likely be part of a different library. It might be part of a shelved feature. It’s probably had a few bigs fixed against it. Perhaps there has been some heavy work done on it by a different developer. In short, it would have changed, maybe it’s doing more, maybe it’s doing less, but it’s not what it was when you released it a year ago. So stop worrying about…
Is it getting the release out the door on the date defined? Is it reducing bugs? Is it that the UX is smooth and simple? Is it that no one burned out getting it out? Shipping code is one aspect of a release, it doesn’t mean it’s the most definitive version of success.
Do you deliver quality work? Do you deliver code? Do you deliver articles or books? Do you deliver leadership programs? Do you deliver people growth? Do you deliver sound architecture? Do you deliver systems? Do you deliver honesty and integrity? Do you deliver empathy and support? Knowing what you deliver is how you’ll be able to figure out how you deliver it and then how it filters down into everything that you.
I can’t say, I have always been someone that has followed patterns and framework implementations to the letter, rather using their approaches to development work. But there are some that I lean on heavily and come back to when thinking about building solutions, no matter the purpose; Leverage queues where possible – offload your work into bite-size deliveries that take the work off the middle-end. Scale out your Databases – you don’t need one and…
Plants Grow. People Grow. Teams Grow. So why would you think your code can never be improved? Never get better and never grow. It doesn’t mean your code was bad, it means it’s simply time for it to move on, grow and become something else.