Most mature teammates have this understanding where the author of a piece of code should be able to tell you how it works. In fact, sometimes changing that code might even require collaboration between the original author and the person requesting changes. That's how important it is for you, the author to remember what your code is about. That's also why when developers leave a company, it's a big deal. When people who worked on large or important parts of the code base leave, the organization that owns the code base is in a risky position.
Now that I've explained the importance of knowing the intention behind the code, we can try to diagnose why you can't hold onto the understanding the next day. I can see a few likely reasons:
- You wrote way more code than you should have. I have a friend who tells me that 4 small tickets a day is a good pace. I can't imagine that's more than 200 lines of code a day.
- That part of the code base is particularly complicated, either because of existing patterns in your code base or because it could be properly described as a complicated sub-system.
- You didn't actually understand the code you wrote in the first place. You may have pushed code, but you didn't think through what you were doing.
- There are other things distracting you, either on the job or in your personal life. Stress can reduce your effectiveness at work.
Is there other information you can provide that will help you narrow the problem?