I like most of you can't pronounce, spell, or remember any of the words above. I don't expect you to get your index cards out and memorize them. Too many people try to get better at coding by simply reading a blog. I challenge you to read this, and then over the next 5 weeks pick an S and practice it.

Step 1 to being a better coder is the desire to be a better coder.
Step 2 is to develop a belief system.
Step 3 is to constantly learn and challenge that system.
Final Step stay true to your system.

Those 4 steps are what make me an okay craftsman. I recently learned of the 5s / TPM (Total Productive Maintenance) via James Coplien in his forward from the amazing book "Clean Code: Handbook of Agile Software Craftsmanship". I was shocked/happy to learn, besides being a slob, I practice & believe in all of them.

Some quick context(sorry for the low-res image):

TPM (Total Productive Maintenance) is a maintenance philosophy engineered to stop failures of process due to equipment breakdown. It also was designed to ensure that a maximal product was being produced in a fast reliable manner. They inspect the machines daily, replace wearing parts before they break, and have a zero tolerance for breakdowns.

Sounds great doesn't it ? Why hasn't anyone thought of this before!

The 5S (my interpretation):

Seiri (sort/organization) - Remove and eliminate waste.

Ability to find things easily.

James references that when coding naming is one of the most important decisions you make. The book brings up the 90/10 rules. 90% of the time you are reading code 10% of the time you are adding to it.

But it's not just about code. Cleanup your environment and free yourself from disruption/disturbance. Make sure things don't get in your way when you are trying to work. Remove clutter from your workplace and evaluate the items around you for worth.

Seiton (set in order) -

"A place for everything, and everything is in place."

Everything has its appropriate place. Code should be where it is expected to be, and if not refactor it to the right place.

Seiso (cleaning) - Keep your workspace (laptop and physical area) clean.

Two parts to this one is physical. Make sure your environment isn't messing with your ability to think or do work. Clean your desk so you can write. Clean the whiteboards so you can draw. Print out requirements so you don't have to lose context to see them. Make it easy to think.

In code, remove clutter, delete dead code, remove low value comments, consistently format & document. Allow time to refactor, and cleanup code whenever you can.

Seiketsu (standardize) - Set high standards and stick to them.

It's one thing to "talk" standards its another to actually set them. It takes about 10-15 minutes to get your team in a room and set some rules for the sandbox. After those 15 minutes everyone now follows the same rules.

Shutsuke (sustain) - Do without being told.

It's one thing to set standards, but it's a giant leap to live by standards. It takes energy and desire to become great at what you do.

When was the last time you saw someone great at what they do, but didn't work hard to develop and refine their talent?

It's equality important to challenge your beliefs/standards and constantly evolve them. I always want to be the dumbest person in the room so I can learn and become even better at what I do. I love reading, but I learn so much more through others. It's easy to read, but battle scars come from application.

When you have fully succumbed to shutsuke you will find yourself not willing to cut corners. While coding you might type alert('failed') but by the time you commit you will have leveraged some fancy notification system... growl.alert('Failed to save', 'error'. You wont accept entropy. When you see a system out of balance you want to make it right.

Lastly, once your team has setup standards make sure you create a community that fosters enforcement. Setup paired programming and code reviews. These are easy techniques that help enforce and develop developer's skills.

In Summary..

All of my life I have lived by what I thought was a belief of my creation:

Always leave places better than you found it. Doesn't matter what you change just make it better.

In the book they talk about the Boy Scout rule:

Leave the campground cleaner than you found it.

Strikingly similar and a great rule to live by. I'll end it with one more blurb from the book:

If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn't have to be something big. Change one variable name for the better, break up one function that's a little too large, eliminate one small bit of duplication, clean up one composite if statement.

Can you imagine working on a project where the code simply got better as time passed? Do you believe that any other option is professional? Indeed, isn't continuous improvement an intrinsic part of professionalism?” ~Bob Martin