Path To Becoming a Better Programmer

I’ve had a craftsman awakening over the last few weeks. After reading So Good They Can’t Ignore You, Quitter, Deep Work, and Extreme Ownership, I realized the only way I’m going to accomplish my goals is by focusing on my craft and that getting better is my responsibility and no one else’s.

Here’s my current plan:
1.) Focus on Ruby and Rails in my free time. Rspec too

2.) Sign up for Upcase.com to learn what I don’t know. Learn what I don’t know I don’t know

3.) Contribute to open source to get feedback from code when possible.

4.)  Refactor and write better object oriented code at my day job as a PHP developer.

5.) Attempt to find a job where I can be mentored by better developers than me.

Every time I come across a book that someone recommends or is interesting, I buy it on amazon.  Ruby Programming, Dessign Patterns by the Gang of Four, Clean Code, and Code Complete have arrived over the last few days.

The greatest resource, by far, has been Upcase.com (a thoughtbot project).

I’ve learned so much from them after the last few days.

Here are a few things that stand out:

What a smell is

• A smell is something in your program that is an indicator of a problem.  A class having more than 1 responsibility is an example of a smell.

Single Responsibility Principle

• Each class should only have a single responsibility.  This comes from the “SOLID” programming method and is the “S” in “SOLID”.  If a class has more than one responsibility, you will typically want to refactor it.  For example, if you use the word “and” when describing a class, it’s usually an indicator that you will want to refactor that class.

The Law of Demeter

• Joe Ferris has my favorite summary of this principle.  “You can touch your privates, and you can touch your friends, but you can’t touch your friends’ privates”.  Examples of this rule have typically involved too many chainings in active record ruby development.  You typically shouldn’t see more than 1 or 2 “chains” when traversing across active record instances.

The Importance of Test Driven Development

• Ben Orenstein is a huge proponent of Test Driven Development and I’m starting to become a convert.  When you write classes that are easier to test, you are typically writing better classes.  I’m starting to see this is something that works.  If a class is hard to test, it’s a class that should be refactored.

 

I hope to blog more about my progress over the next few weeks.  This is not an easy quest.  I’m on a journey to become a great ruby developer from a spaghetti code PHP programmer.  If you have any thoughts, feedback, or nice things to say, you can find me on twitter at @cavezza