Voice of the DBA

Author: way0utwest

Changing the Origin in Git–#SQLNewBlogger
I needed to show a customer how to migrate from Azure DevOps to GitHub recently, and to smooth this process, we needed to repoint the origin remote.

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers. You can see all posts on Git as well.

Changing the Remote

When you want to see remotes, you run this code:
```
git remote –v
```
As you can see, I have my origin pointed to Azure DevOps..

Now, I can delete and add back the origin remote if I want, but there is an easier way. I’ll use the set-url parameter with this code:
```
git remote set-url origin https://github.com/way0utwest/DatabaseDevOpsMS.git
```
This points the origin to my new remote in GitHub. Once I run this, I’ll set the branch and push, as the GitHub repo is empty. This pushes everything to GitHub and voila, I’ve got code there.

You can see this online

SQL New Blogger

I had to write this up in more detail for a customer as documentation. You might do this at work for someone, but I grabbed this focused, small piece of this and created my own blog, reusing a few screenshots.

Note: Don’t reuse screenshots of company assets. Recreate this in your own space.

This took me only about 5 minutes to write up after the other work was done. You could easily do that.
January 3, 2024
Fixing Poor Programming Practices

I see a lot of poor programming practices in real-world code. I’m sure I’ve written a few myself. I’m also sure that many of you see the same thing and sometimes wonder how that code got deployed.

One of the things I told myself over the last few years was that I had to accept the reality of situations. It’s easy to complain and say that code should be written differently or entities should be modeled in another way, but I (or you) can’t change that situation today. And it ignores the fact that we are stuck with this environment and we have to move forward from here, not try to rewind the clock and go back in time to design things better at the start.

Today I’m wondering how you’ve adapted to poor practices and fixed them. Do you have stories to share that might help others deal with their situations? Post comments below, and to help, I’ve got a few stories from my past. Both of these deal with third-party software products that (poorly) use a SQL Server database.

One company purchased a new accounting package with very poor security practices. The installation noted that the software needed to use the sa account. I couldn’t think of a reason why an accounting package needed sa on an instance, especially as we were installing this on a production server with another database.

I called the support line and we discussed what was happening. They said that for the accountants to add new users, they needed to add a login and thus needed sa. This was in an older version of SQL Server, but that still didn’t make sense. It was lazy developers not understanding the security model and wanting sysadmin to make things easy. We showed them that we could add a login ourselves and a public user mapped in the database, which the software would pick up and allow finance people to assign rights. Poor practice mitigated.

In another piece of software, we found a view being used that was querying other views and tables. As you might expect, performance was poor. We decided to “fix” the view with better code, but first, we created a new schema (with our company name) and added their view to this schema. That way we kept their code around. We rewrote their view to run more efficiently, and if we had a support call, we’d replace our better view with the original one from the previous schema. We even had a proc in our schema to do that for us. Of course, our view was kept in our VCS, as it should be.

If you’ve got stories, let us know in the comments today.

Steve Jones

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

January 3, 2024
Career Plan for 2024
It’s a holiday today, but I’m dropping this as I spent last week working on it. I wrote about having a career plan on Friday, with a few notes in there on how I was viewing my career in 2024. This post will cover a little more of my thoughts on the future (for me) and my plan.

Note: I’m mid-50s, and my career is closer to being over than beginning, so take this with a grain of salt if you’re in your 40s or younger.

Thoughts on My Career in 2024

I tried goals for a number of years, but those are hard for me to work on through a year for a few reasons. One is that my view in Dec/Jan is not always one that continues through the year, at least not with my job. Second, I start to get focused on the goals and it creates stress and pressure that I don’t need. Rather that improving in an area, I’m driven by the goal.

I don’t like that.

I also find my career is evolving more rapidly in the 2020s in the past, with each year moving me in new directions that are tangentially related, but hard for me to build goals in since both me and my employer are learning new ways to use my talents throughout the year.

I’m closer to the end of my career, with roughly 10 years—ish left. I’m also doing more work with customers as an architect and advisor rather than a marketer. I find my time is spent more with sales than marketing or engineering, and I both need new skills there, but I also have to focus my time in different areas.

Lastly, a portion of my job is still journalism, running SQL Server Central, so I need to remain aware and learning about the state of the data professional in the world.

With that in mind, I’m setting plans in motion to help me in those areas, without goals. Just a direction. I think that’s a new approach for me, where I look to find time to grow in a direction, but without the pressure of a goal. If I have to skip some sessions or alter the direction, I can do that easier by altering the direction rather than trying to abandon one goal and find a new one.

Think of this as finding a new route while on a road trip rather than being driven by the time of arrival.

The 2024 Plan

Where do I want to be in a year? Here are the things that come to mind:
- Produce a specific content on Redgate technical issues or architecture recommendations that I upload to our Seismic site.
- Learn how to use all the Flyway commands well from the CLI so I can make good recommendations for flow and using them
- Learn to use static code analysis tools and create custom rules in a pipeline
- Be comfortable enough with AI to use it every week
That might be too much, but the first 3 are really related to my job, so I’ll be getting career growth out of them and I can spend some of my time at work focusing in this direction. These are areas I’m interested in and having a direction to produce these learnings as documents shared within the company will force me to learn them a bit better.

The last one about AI is not because I think AI is great, but because I’m still unsure of how or where to use it. I have some coursework on AI from Microsoft that I’m going to go through and try to better understand what’s happening, what’s involved with training, and how I can prompt better. I think this will be a good tool at some point, if not for writing code, perhaps for other things.

That’s my plan, now, what’s yours?
January 1, 2024
Happy New Year 2024

We start the New Year on vacation, at least, I hope most of you are relaxing today, spending time with family or friends, and getting a break before we go back to earning a living.
If you didn’t read Friday’s editorial, you should, and spend part of today getting your 2024 plan together.
For me, my 2024 plan is to work on growing more of my skills with my employer’s products. While I’ve been at Redgate for 16+ years, we’ve had a lot of rapid change in the last year with Flyway and TDM, and I need to make sure I can help customers with the best recommendations on how to implement the products. I still expect our Solutions Engineers to know the ins and outs of switches, options, and parameters better than I do. However, I need to ensure I’m not too far behind them and know all the capabilities as they’re added. And with weekly DevOps releases, they’re being added quickly.
I also want to spend more time experimenting with and learning about AI. I don’t know I want to make that my career area, but I do think it’s a tool that will help me in my career, and so I’ll be spending my 10% time there.
Lastly, the overall framework for my career in 2024 is balancing life with travel. 2023 was hard and I want to be sure I don’t overload myself.
Happy New Year, and work on your 2024 plan.

January 1, 2024