What are the important things you should know about writing T-SQL code for an organization or on a team? I'm sure that many of you have ideas, and please, feel free to share them with us with a comment. As you think about your answers, think about this as well: what do you wish you'd have known when you started writing code?

I went through university quite some time ago, over 30 years ago, and some things have changed in this industry. Not so much in the way we structure the code we write, though we have gotten much better in some ways. Rather the way that organizations work has dramatically changed. It's not just this new DevOps thing, but more that many organizations are starting to expect developers to do more than sit in a cube and react to a set of tickets or a specification written months ago.

More companies are expecting developers to think and interact with others, knowing more about other parts of their environment and application. More developers work in teams, and perhaps very interesting to me, the once dreaded and heavyweight code review that seemed to die during the middle of my career has become a commonplace, quick task that developers do every day now.

There's an interesting piece, written by Ryland Goldstein, about the things he thinks developers should be learning in college or early on. I thought it was interesting to see him open with lines of code (LoC) as a metric, and show the growth in code for some large applications. To me, LoC hasn't been important at any point in my career, but I know it was talked about while I was in school.

He does talk about some things that good code should have, and I agree that most of the time the language doesn't matter. I do think his points on reading code, and learning to work with other people's code is good. To me, this really means we want to adapt and learn to write code in the style that our team uses. That can have a huge impact on group productivity, when we can write in a similar style, and then also read (and review) code quicker because it's all the same style.

Perhaps the best line is this: " Every single member of our team (including me) would have a full blown panic-attack if someone ever suggested committing un-reviewed code." I think too often the database side of things ends up committing (and deploying) un-reviewed code too often. We could to better, even if we need to teach someone how to review our code. Having a second set of inexperienced eyes might not prevent mistakes, but it certainly might help others learn to write better database code.