Bob Cavezza's Blog

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 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 (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

§504 · February 17, 2016 · Software Development, Writing Better Software · · [Print]

1 Comment to “Path To Becoming a Better Programmer”

  1. Rida says:

    Interesting post. I’ve had similar eienrxepces when working with ZF over the past 3 years. Since looking and moving to Symfony2 over the past two months, it has really hit me. Zend’s licensing is very restrictive in the fact that you must sign a contributors’ license agreement, and you cannot re-use any code. Symfony’s community is a lot closer to the Ruby / Rails community where you end up with tons of 3rd party libraries integrated and managed by a few key players, but everyone is still able to contribute via Github. Things progress very quickly and it’s exciting to be a part of it.If you don’t want to learn a whole new language, but want to dive into OSS, I highly recommend checking it out. I’d even be glad to give you an introduction to it one day if you’re up for it.

Leave a Reply