It’s handy to know a lot about programming langauges, patterns, “best” practices, and anecdotal experience in applying those ideas. But premature application of ideas can lead to its own bad experiences and new anecdotal evidence. How can you apply ideas without falling into the premature architecture/optimization trap?
Follow the smells.
You know what a bad method looks like. You know what slow code looks like and how to find it. You can tell when a class is doing too many things. Follow those smells.
Once you’ve smelled it, you’ve dealt it. Kidding!
Once you’ve found a culprit that is imminently making your life as a developer harder, you have to explain it to someone else. Tell them why it’s slow, badly coupled, or too much architecture. Once they’re convinced, then you can reach into that deep knowledge of languages, patterns, practices, and experience to fix the problem.
You commit the code, push it to production, and do a happy dance. You’re not done.
Now you need to share it. Write down what you did and share it with your team, lest the problem happen again. Show your co-workers how to find the problem elsewhere and quickly dispatch it.
If you do it this way, you’re helping yourself three times:
- You fixed the original problem
- You showed your colleagues how to fix the problem or how to avoid creating the problem
- You showed your colleagues how to make measurable, if minor, progress in making your application better without the need for drastic projects
Follow the smells. Fix the smell. Put the fix in everyone else’s brain. Repeat.
