This month’s T-SQL Tuesday (#080) is being hosted by Chris Yates (B|T) (Happy B-day Chris!).
He decided that this month’s theme was to be a gift to the community of something you had to offer that someone else may find as a gift. Or maybe it isn’t. That’s my interpretation. You can figure it out for yourself here.
Anyhow, here’s my short story about what I never thought would be a gift, but turned out to be a good lessson for myself as well as those it impacted.
The Story
This story starts with a large project I was working with that had a relatively large data team. Things had been progressing, and we managed to keep our data team out ahead of schedule. Part if being able to do this was having weekly code reviews of all T-SQL that would change the database structure at all. A lot of work had to be done in these reviews as we were in the middle of redesigning the entire database and always breaking things.
We created a documented guidelines for coding in the SQL databases and used our code reviews to enforce those criteria.
One of the criteria we had was to have code that was clean and straightforward. We knew there would be a potential for an extended maintenance period once the project went live, and we didn’t want to over-complicate the code base.
There was one person on the team, a younger SQL developer, that had years of experience and was always trying to use the newest features and ways to code what was needed. They got so wrapped up in the new shiny methods that their foundational code base got weak.
The poor code became more and more evident in every week’s review.
Their code would consistently be pushed back for improvement and cleanup, proper documentation, etc.
It was harsh, brutal even. I know this person felt singled out, but they weren’t. Heck, I would even reject my code in reviews 1/2 the time.
We continued working the project as a team and then, one day, they pulled the plug on the project.
Honestly, it was not a surprise. If you try to push a deadline for a major project more than 5 – 6 times there are good odds the client is not going to be happy. Regardless everyone was told to pack up and get out of the building.
During the packing process, the younger coder came over and thanked my profusely.
They mentioned how they had been coding for six years and getting better and better, but by pushing them back to basics during our reviews, they realized their code performed better and was much easier to understand and maintain.
They had lost sight of those basics, and by pushing them back through the review process both the code and them became better.
It was a nice gesture for him to mention that to me, and that ‘gift’ has stuck with me ever since.
Wait, what was the gift?
The gift was the reminder to stick to the basics and the roots of what you are doing. The basics skills are always essential. You don’t have to use the latest and greatest techniques or code just because it is new.
Use what is best for the job.
Sometimes just the basics are enough.