So I was back on-site at IGT for a couple of months in the summer of 2012. It was one of those crunch-time projects where all aspects of development would be done in a “war room” — where we could collaborate in the most efficient manner possible. We created a clubhouse-like atmosphere, and it was one of the most enjoyable experiences of my career.

One of my colleagues would often ask me to assist on troubleshooting some of his SQL Server stored procedures. As .Net is his specialty, his T-SQL skills needed sharpening. Deciphering his code was usually more difficult than solving the problem, so I would end up breaking apart the SQL to make it more readable.

To my colleague’s credit — he took notice! Instead of sticking to his old approach, he started adopting my style (a composite of my own ideas blended in with the best I found in others). Each time I took a look at his work, it became easier to spot the problem.

But the pinnacle of the point came one day when another .Net colleague assumed that I rewrote a procedure because he knew my methods. I said, “No, I didn’t — [the other guy] did that.”

For the same reason that naming conventions are key to quality coding, so too should style be considered in the same light. My colleague didn’t conform to “my way” — he acclimated to what made the most sense (which is precisely how I developed my style in the first place).