I heard a comment recently - somewhere on the internet - that if you want to get better at programming, you need to write less code and consume more information.
That idea makes sense, because you can only output code based on your level of knowledge. Sure, after a lot of practice one might realize that they shouldn’t write duplicate code. However, it would be more cost effective to read a blog post that tells them not to duplicate code.
Lately, I’ve been trying to consume more, read blog posts, listen to podcasts, watch conference talks, and scour YouTube for videos explaining higher level concepts.
During my adventures I ran accross a talk Sandi Metz gave on code smells. I’d heard of code smells before, but I couldn’t name any if I were asked. And to be entirely honest, I didn’t even know code smells had defined names. I figured it was an ambiguous term software engineers used to describe code style they didn’t like.
I recommend watching the talk. It’s damn good.
If you don’t want to watch the talk, here is the important bit (in my opinion):
Sandi shared a resource called Smells to Refactorings Quick Reference Guide.
The guide is a list of all code smells along with references to pages in Refactoring: Improving the Design of Existing Code that provide tried-and-true methods of refactoring the code smells.
At the end of the talk Sandi says:
If you’re waiting to move yourself up to that next level of programming - to move yourself to that next level of proficiency - the way to do it is to go learn code smells, and to learn those recipes for refactoring.
I’ve already purchashed my copy of Refactoring, and I’m going to start working through the code smells. I’ll try to share explanations, in future blog posts, of each code smell as I work through the list.