T-SQL Tuesday #182: Personal Integrity

Posted on January 14, 2025 by way0utwest

It’s time for the first T-SQL Tuesday blog of 2025, with an invite from the first non-founder to host a party, Rob Farley. I reached out to Rob and he graciously agreed to host. His invitation this month is on integrity, leaning towards data integrity.

I still manage the T-SQL Tuesday list, and I’m always looking for hosts. I have a few scheduled for 2025, but I can use more. If you’re interested in hosting, hit me up at one of these places:

While data integrity is important, I think personal integrity really matters as well.

Integrity at Work

I used to work for a large corporation, which I won’t name here. This was a 10,000+ person organization and I helped manage part of the data group for the company. I had a number of reports, 10 or 11, that handled different aspects of production operations across a variety of database platforms.

It was a busy job, and our environment was far from stable. As is the case, things get cobbled together, become popular, and then limp along for years. This happens in small companies and large ones, but in large ones, I think it continues because when there are problems, we can throw people at the problem. We could throw resources and fix chronic issues, but that wasn’t the case at this company.

At the time I worked at this company, we had a stacked ranking system for reviews.  Microsoft used to do this (and stopped), but think about ranking everyone in your team from 1-5, 1 being underperforming and 5 being outstanding. The “stacked” part comes from the need to have a certain number of 2s, 3s, and 4s. 1s and 5s were rare (5s more rare). Essentially a 1 meant you were on a performance plan and on the way to termination.

I had to rank my staff, who worked hard and kept our systems running, despite lots of incidents. We performed some large migrations and upgrades of systems where my staff worked multiple weekends, with no comp time, just meals covered.

My first integrity stand was that even though I wasn’t officially allowed to give comp time, I did, working through my staff with extra days off that were unrecorded anywhere. This might be more of a violation, and if my boss’s boss had caught wind of this, I would have been terminated. However,  I felt my staff deserved something, as a few of these long weekends weren’t adding business value; they were things executives wanted to do for optics.

Near the end of the year, we had to rank our workers for annual reviews. I had most of my staff at 4s, with a couple 3s. I put in one person as a 5 for some great work they did. Justifying a 5 is hard and I thought I had a good case.

In a meeting of our IT department, the VP of Operations told us that we had too many 4s and that each director (1 level above me) would get an allocation of rankings and that each manager had to work to fit their staff inside that allocation. Anyone ranked a 1 would be outside the allocation.

My second integrity stand was to argue with my boss on why my staff deserved their rankings. According to their job descriptions and performance, I’d ranked then well, even though his quota meant he wanted me to move a couple 4s to 3s and 1-2 people to a 2 ranking. I refused, arguing with other managers whose staff I had seen underperform through the year. I told a few others they needed to absorb the 2s and 3s and not the data team.

I lost that battle and had some uncomfortable reviews (and the accompanying bonus/salary numbers), but I acted like an adult and told people I had ranked them a level higher and upper management lowered their ranking, not because of performance, but because of a quota.

As we went through the next year, management decided they needed to cut costs. They had managers compile a lot of numbers that were sent to outsourcing companies in an RFP to essentially remove IT from the company’s books. In a meeting, our CTO tried to spin this as good for workers as the winning company would hire our IT staff. The framing was that this outsourcing would save the company money.

My third integrity stand was when I questioned the way this worked in a large meeting of IT management and eventually got the CTO to admit that:

  • a) everyone would have to re-apply for their job
  • b) they might not get the same salary (higher or lower, you decide which is more likely)
  • c) not everyone would be hired

This might work out for some people, but likely those who got jobs at a new company were risking their salary and workload in a new situation. I questioned this as being good for the company overall as we would likely lose lots of knowledge.

I left shortly thereafter, voluntarily, but I’m sure I would have been let go at a layoff that occurred near the end of that year.

I hated that job in many ways and was glad to eventually leave. I decided I would never work for a stack ranking company again.

Posted in Blog | Tagged , , | Comments Off on T-SQL Tuesday #182: Personal Integrity

Grinding Away: Mary Spender

Posted on January 13, 2025 by way0utwest

A few years ago I stumbled on this video and loved it.

That led me to Mary’s page and this cover of John Mayer’s Stop This Train:

Since then I’ve been following her, watching this musician build a life around her music, her videos, and more. Her site is at https://www.maryspender.com/ and I was sad that I wasn’t in the UK during her tour last fall. However, I still follow her videos, where she describes how she approaches the music business, or song writing or her craft, etc.

Making a living as a musician has been her dream and while that slightly pivoted, she still works in and around music. She is making it, though I’m not sure she’s getting rich or living the easy life. My view from the outside is she grinds away every week at producing content and music that will allow her to continue doing so.

This might be a treadmill of sorts, but it’s also the one she chooses and enjoys. Music is her passion and finding a way to make a living doing something you love is admirable.

However this takes work. It’s a grind. Maybe an enjoyable one for her, but still regular work.

Posted in Blog | Tagged , | Comments Off on Grinding Away: Mary Spender

Simple(r) Coffee

Posted on January 13, 2025 by way0utwest

Starbucks has too many order combinations. This article about the challenges for their new CEO notes there are over 170,000 combinations of things customers can order. As someone who has visited a store often and stood behind someone placing an order, that sounds like an accurate number. Sometimes I hear people order things to drink that I had no idea were even possible.

When there are too many choices, sometimes there can be a delay as the person tries to process the information and make a decision. Some people can’t make a decision. Others enjoy the variety and keep making different decisions each time. That’s fine if you’re visiting a restaurant, but it’s less useful if you’re building software.

I have worked with people who struggle to decide on an approach to solving a problem. In the C++ world, I’d see people struggling to organize classes and members, sometimes spending too much time researching and comparing different methods. They debate when is private or public appropriate, when do we need a superclass or subclass? We would see some paralysis by analysis from certain developers who are endlessly searching for the optimal approach.

Other developers might change their approach constantly, resulting in a lack of consistency across the codebase. In the modern world, I sometimes see users experimenting with different libraries or packages (or data stores) with each new project. They might be consistent within a project for a period of time, but since many teams often shift to different projects over time (or maintain them), how helpful is this? If each new project looks different, we spend a lot of time on developers getting familiar with the technology.

I have tended to adopt the philosophy of strong opinions, loosely held. In other words, I’ll pick an approach/platform/technology/etc. and stick with it. Moreover, I’ll ask everyone on the team to stick to a similar method of coding. If we need to change, then we can evaluate the proposed change, performance test it, and if we decide it’s better, we all adopt this and slowly work to refactor old code as we have time. We never have time, so we only refactor when we have to touch old code for some fix or enhancement. However, when we do touch old code, let’s improve it.

My preference is to allow a limited set of technologies in our company at any point in time. We need a process to add or remove something, but this ought to be a decision made to limit our range of technologies and required expertise. I’m not against Python or PowerShell or MongoDB or any other technology, but I don’t want things adopted because an individual prefers that technology or thinks it works better. They need to prove that there is a good reason to others, and as a group, we agree that the value of adding a new technology is worth the burden.

Otherwise, we end up in the situation I see often in job descriptions: with a requirement that new hires know dozens of technologies at an expert level because we don’t have that person on staff.

And we’ll never find them.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | Comments Off on Simple(r) Coffee

Friday Flyway Tips: Chaining Commands for State-based Deployments

Posted on January 10, 2025 by way0utwest

One of the cool things I’ve seen with the new Flyway CLI is that I can combine multiple actions together in one call, which can make the process of writing automations streamlined.

I’m not sure I love this, but I’ll show how this works.

I’ve been working with Flyway Desktop for work more and more as we transition from older SSMS plugins to the standalone tool. This series looks at some tips I’ve gotten along the way.

Making a State-Based Deployment from the CLI

In a previous post, I showed how to use the new prepare and deploy verbs to create a deployment script and then apply it to a database. This is a great way to handle simpler deployments if you want to work in a state-based fashion with Flyway.

That post showed two different CLI calls, which are shown below:

flyway prepare -prepare.source=schemaModel -prepare.target="env:qa" -prepare.scriptFilename="deployments\FWState__deployment.sql"
flyway deploy -scriptFilename="deployments\FWState__deployment.sql" -environment=qa -executeInTransaction=true

Easy enough, and I like this structure as I’d likely build a pipeline that looks like this, where I prepare the script, then have a manual approval step to check this before deployment:

2024-12_0228

However, you might argue that someone would check the script in a QA or other deployment, so maybe you streamline things later, or you use this as a QA/test deployment and want everything to run smoothly after a PR.

In that case …

Chaining Commands

I can run this code instead.

flyway prepare deploy …

Let’s see this work. If you look, I have a couple of changes that I can see in Flyway Desktop. There is a table alter and a new stored procedure.

2024-12_0232

I can streamline the automation of these two changes in the CLI with the code style above with this code:

flyway prepare deploy -prepare.source=schemaModel -prepare.target=”env:qa” -environment=qa -executeInTransaction=true

Here is the pre-execution look at my database:

2024-12_0233

The execution, which didn’t use a transaction. I’ll have to figure that one out:

2024-12_0234

And the post database view with the table and proc changes deployed.

2024-12_0235

I built and deployed the script in one command, and it also appeared to have added my script to the deployments folder. No idea why that happened either.

2024-12_0236

If you want commands chained, you can do it.

Summary

This post showed how you can chain your prepare and deploy commands together in one command, which might be preferable in some situations.

I don’t know if I like this, or would do it, but it’s not a bad idea. Ultimately, I’d really like this deployment script to be saved back to the repo so I could track it, but that’s going to be some work, and likely that means not chaining commands.

Flyway is an incredible way of deploying changes from one database to another, and now includes both migration-based and state-based deployments. You get the flexibility you need to control database changes in your environment. If you’ve never used it, give it a try today.

Posted in Blog | Tagged , , , | Comments Off on Friday Flyway Tips: Chaining Commands for State-based Deployments