The 6 Month Rule

A common saying that I have at work is that if my name is attached to a git blame and that line of code is older than 6 months, it is no longer my code, that is the teams code. Aside from it being a humorous way to respond when somebody asked "WTF were you thinking at the time", it has a deeper meaning.

Your skills should significantly improve every 6 months. Stagnation in your skill set is a sign something needs to change. The tech field is changing rapidly, very rapidly. Remember when GPT 3.5 was released? That was November 2022 . Now this model is absolutely horrible compared to the latest generation of models.

I often go back and look at my own code and sit back and reflect "What could I have done better with what I know now?". If I can't think of a better way to implement the feature or project that I created then something is wrong (I have not ran into this yet).

The drive for continuous learning is what attracts me so much to this field. It's infectious. There are an insane number of different subsets of software development and an even more insane amount of resources for you to learn more. Knowledge is free and people love to share their knowledge.

• Read a book
• Read the documentation
• Watch YouTube tutorials
• Talk with your coworkers
• Just build

This principle doesn't apply just to individual developers. If you are at a company that refuses to evolve, jump the ship, you're hurting your career (I've been there before). Look at companies that failed to evolve - Blockbuster didn't adapt to streaming, Nokia missed the smartphone revolution, and MySpace couldn't keep up with social media innovations.

Of course, there is a balance to maintain. You have to deliver. You can't hole yourself constantly rewriting what's older than 6 months. The key is to recognize when something is going to be a burden in the future and start there.

Focus on the results of your refactor and not just how old it is. Could you be doing something more efficiently and it's holding you back? Refactor it. Does this block of code just look ugly and you can clean it up? Leave it alone. You should've cleaned up that code in the first place. Looks are not comparable to efficiency.

How do I measure my six-month growth? I look for these indicators:

• Problems that used to take days now take hours
• Architectural decisions that account for edge cases I wouldn't have considered before
• Recognizing anti-patterns before they cause production issues
• Being able to mentor others in areas where I once needed help myself

Go back and look at an older project and reflect on what you were thinking at the time. Has your skill changed? What could you have done better now with what you know? It's not a failure to look back and realize that you might've had a few screws loose in your head at the time you first implemented that project, you've improved. Keep improving.

"When we strive to become better than we are, everything around us becomes better too." - Paulo Coelho