T-SQL Tuesday #171 – Describe the Most Recent Issue You Closed

Invitation and roundup from Brent Ozar.

Your readers wonder what kinds of jobs are out there in the database world, what exactly it is that you do, and what your daily grind is like. While it’d be cool to cover all of that, let’s start with something simple.

Your mission for this week: write a blog post about the last ticket you closed, and schedule it for next Tuesday, February 13.

It doesn’t have to be T-SQL. T-SQL Tuesday has evolved to cover all kinds of data topics.

The task/issue doesn’t have to be indicative of your overall career. Our database jobs cause us to do all kinds of oddball things through the day. Go into your ticket system, help desk system, list of Github issues, or task list right now, look at the last task you checked off, and blog about that.

Don’t include company specifics or anything that might get you in trouble. Just talk in general terms about:

  • Why the task was created (an error popped up, a user had a problem, your boss had an idea, whatever)
  • General terms about work you had, what online resources you found helpful, how long it took
  • How often that kind of task pops up in your queue

T-SQL Tuesday #158, Implementing Worst Practices

Invitation from Raul Gonzalez.

One of the most repeated answers to almost any question asked within the SQL Server community is that “everything depends”… Can that also apply to known best practices?
 

Furthermore, is it possible that some of the commonly agreed “worst practices” have indeed some use case where they can be useful or suit an edge use case?
 

This month I am asking you to write about those not-so-common practices that you may have implemented at some point and the reasons behind it, I have a few in my pocket that will make more than one a bit uncomfortable 😀

T-SQL Tuesday #157 – End of Year Activity

This month’s invitation and recap from Garry Bargsley.

Welcome to the final T-SQL Tuesday for 2022. My ask is, what do you have planned for end-of-year activities for your SQL environment? Do you have annual processes or procedures you run? Do you clean up documentation? Do you just take time off and hope someone else does the work?

Some Examples:
  • Purge log data
  • Archive databases for long term
  • Look for orphaned data/log files on your SQL Servers
  • Do Security analysis for no longer needed accounts
  • Add new years dates to dimension tables

T-SQL Tuesday #156 – Production Code

Invitation from Tom Zika.

I’m a learner by example, so when I started programming (not so long ago), I tried to find existing solutions on various Q&A sites or blogs, as one might.

After a while, I noticed one sentence repeating often enough that it stuck with me:

“This is not a production-grade code”.

So here’s my invitation: “Which quality makes code production grade?”

You might think: “Production code is code that runs in production, duh.”

But let’s help out the newbies who look for a bit of concrete guidance.
Please be as specific as possible with your examples and include your reasoning.

I’m not limiting the scope to just the SQL; it can be anything.

T-SQL Tuesday #152 – It Depends

Invitation and round up from Deborah Melkin.

I came to a realization lately that I have a few opinions about databases. And I’m pretty sure that you do too. After all, I’ve read your blogs, chatted with you, and seen your Twitter rants.

But we’re database professionals. It’s supposed to depend, right?

Except we all have experiences that shape how we approach our work. One minute your coworker asks you a question about doing X. You reply with “It Depends…” leading into a 5-10 minute rant. This may include some or all of the following:

  • Stories starting with “that one time at that client”
  • References to blog posts you read\wrote\should write
  • Commentary on code – the good, the bad, & the ugly
  • Personal theories and philosophies on the topic

All of this is followed by “Thank you for coming to my TED talk” and a “I’m sorry, what was your question again?

So yeah… this may have been inspired by an actual conversation… or two… or ten. I apologize to my coworkers… again…

So for this month’s T-SQL Tuesday, I want you to give us that rant. Tell us about the experiences, the code, the posts that inspired you, and all the gory details in between. And what is it that makes you so passionate about this topic that “It Depends” gets tossed out the window? Pull out your soapbox and tell us all about it

T-SQL Tuesday #138: Managing Technology Changes

Invitation and wrap-up from Andy Leonard.

One point I make (repeatedly) in my latest book – titled Building Custom Tasks for SQL Server Integration Services – is “software changes.” In fact, software changed on me between the completion of editing and the release of the book! I wrote about the changes in a post titled Building Custom Tasks for SSIS Second Edition Errata, Chapters 1-9. There’s a live stream video at the bottom of that post, as well.

Changing software inspired this month’s T-SQL Tuesday topic:

“How Do You Respond When Technology Changes Under You?”

T-SQL Tuesday #107 – Death March

The invitation and roundup is from Jeff Mlakar.

The Death March

There is a famous book in our field written in the 2000’s by Ed Yourdon called “Death March“. In it he details the phenomenon in project management of death march software projects. He observed a trend in organizations who plan software projects to estimate so poorly that completion becomes overwhelming and unlikely.

More companies than ever before could be considered “software companies”. Project planning hasn’t gotten much better over time and we still have terribly managed projects. The best reason to explain this I found on Quora – Why are software development task estimations regularly off by a factor of 2-3? In particular, read the answer by Michael Wolfe midway through the page. It is both a humorous and scary analogy.

On this month of Halloween we are going to discuss our death march project horrors!

Mission Directive

Ed Yourdon's Death March

I invite you to share a story about a project you worked on or were impacted by that went horribly wrong. You do not have to have been a developer. Any role you played whether it was a sysadmin, DBA, business analyst, systems analyst, project manager, consultant, QA, etc. is entry requirements for this.

A word of advice – please change the name of the company unless you want to burn that bridge. For example: instead of saying “I worked for IBM…” you could say “I worked for a large technology consulting company”. I’m not trying to get anyone fired here!

Tell me your project horror stories – the worse the better.

T-SQL Tuesday #105 – Brick Wall

Invitation and WrapUp from Wayne Sheffield.

Brick Wall

Tell me about a time when you ran up against your own brick wall, and how you worked it out or dealt with it. Did you start working on a project only to find a brick wall that had been hidden? Was your brick wall:

  • A technological hurdle to overcome?
  • Brought about by your not having sufficient knowledge of the product?
  • A person?

Whatever you choose, tell us about a brick wall that you ran into and how you dealt with it (did you get help from someone/someplace? Wake up in the middle of the night with the solution?).

Most importantly, publish your post sometime on Tuesday, 2018-08-14 UTC time.

T-SQL Tuesday #099 – Dealer’s Choice

Invitation and roundup from Aaron Bertrand.

Aaron is offering a choice.

Behind door #1:

In the spirit of my revelations about still being a hockey card nerd after all these years, and after seeing Drew Furgiuele’s great post on #sqlibirum, I would love to hear about something you are passionate about, outside of the SQL Server or tech community. Bonus points if it’s a passion that might surprise the rest of us. Play the Zeusaphone? Forge Samurai swords? Coach a chess boxer or extreme ironer? Maybe you dabble in toilet seat art? Tell me about it! Show me proof! If you choose door #1, I hope your post is full of pictures or other media, and not just a wall of text. Let’s keep it PG, though, OK?

Behind door #2:

Since many of you might be uncomfortable talking about your non-technical passions, I’ll give you an escape pod back to the more familiar. I have a long laundry list of T-SQL bad habits (there’s a big index here). What’s your favorite one? Which one do you disagree with most vehemently? What bad habits are missing from my list? This is not entrapment; I promise I’m not going to bait you into writing something just so I can argue with you. I’m really interested in reading your opinions and, also, to have more material I can point to when I talk about bad habits and/or best practices.

T-SQL Tuesday #091 – Databases and DevOps

Invitation  and roundup from Grant Fritchey.

Implementing DevOps with databases presents a unique set of challenges. However, just because something might be hard doesn’t mean that it shouldn’t be done.

I had the opportunity to work with a team of developers, database developers and DBAs under a management team that all agreed on the common goal we had, delivering more, better performing applications, faster. We didn’t know it at the time, but we were doing DevOps.

DevOps gets a bad name because, well, the problems that DevOps sets out to solve, poor communication, bad teamwork, dysfunctional development and badly configured and maintained processes, are  done by the same team that attempts to implement DevOps. However, they look on it as a purely mechanical switch that they throw, assign some poor person to the role of DevOps Coordinator (or something) and then maintain the status quo in regards to their culture and approach to software. Shocking that implementing this doesn’t work.

Then, toss in databases with the whole issues around persistence, and things go nuts.

This then, is my choice for T-SQL Tuesday. How do we approach DevOps as developers, DBAs, report writers, analysts and database developers? How do we deal with data persistence, process, source control and all the rest of the tools and mechanisms, and most importantly, culture, that would enable us to get better, higher functioning teams put together? Please, tell me your DevOps stories.