• Stairway to Advanced T-SQL Level 9: Compare, Modify, Derive and Validate Date and Time Values
• CRUD Operations in SQL Server using Python
• Managing database changes using Flyway: an Overview
• From the SQL Server Central Blogs - Server Review Essentials for Accidental and Junior DBAs—Setting Up (Part 2)
• From the SQL Server Central Blogs - One Chart at A Time Video Series

• The preloaded data in R

Daily Coping Tip

Challenge negative thoughts and look for the upside

I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate.

For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours.

Artist or Scientist?

Today's editorial was originally published on 19 Aug 2014. It is being re-run as Steve is on vacation.

Which are you, an artist or a scientist? If you automate, you're the latter. If you are a scientist, you can go on vacation. You can be more productive. People can count on you. You get things done quickly, consistently, and reliably. Everyone knows what to expect when you're done with a task. They can expect things to be completed a certain way.

If you manually run installation programs, click GUIs to configure options from memory, and customize each system you work on, you're an artist. Artists build works of art, each of them unique. I know some incredibly talented artists working in technology, people who duplicate their work over and over extremely consistently. However at some point they'll make a mistake, and then I'll never know what state the system or code is in.

While we need artists to push boundaries and experiment with new techniques, we don't want them managing production systems or writing production code.  I want production code to use well known and proven techniques, best practices, good error handling, application of standards, logging and more. I want production systems to be stable, not with a lack of change, but with a lack of issues. I need scientists that produce work that can be counted on.

Don't build works of art. In development you must be an artist at times, but when you solve problems, ensure that the code contains best practices (secure coding and error handling among them), and make sure that your team understands and can reproduce the code later. In production, ensure you learn automation (PoSh, scripting, templates) and can build, or rebuild, your systems quickly and consistently. Deploy your builds to QA and development so that all the environments are the same.

Become more of a scientist and not only will people depend on you, they'll be less worried when you go on vacation because there will be fewer surprises for the person covering your work.

Steve Jones - SSC Editor

Join the debate, and respond to today's editorial on the forums