Priorities and Productivity

Time is a resource for all of us, both at work and in our lives. As I get older, I think time might be the most valuable resource I have, the same amount each day, but an ever decreasing set in my life. As a result, I try to avoid wasting time and taking advantage of what I have when I can.

At work, we often have more tasks than we can complete in any point in time. I have rarely been without work, though certainly there are slower times when deadlines aren’t providing pressure to get things done. For many of us, we can struggle to manage our work, especially without strong management to help us.

There was an interesting blog from Trainline, from a technical worker that was promoted to manager and had a whole new set of tasks and responsibilities. He decided to adopt some of the same agile principles he used as a developer to manage his time. It’s an interesting read, and perhaps one that might help some of you better organize your own work.

The principles of Lean Thinking and visualization are two of the items he used, along with building a Customer-Value map. You can read the basic descriptions, but to really understand how these concepts work, you will want to do more research and spend some time practicing the concepts. However, there are a couple of other techniques in the post that I think are worth pointing out.

The idea that work has an effort and value you can use to help determine which tasks are worth tackling is important. I think sometimes we consider value without effort, but organizing tasks into grid is useful. There is also the concept of important v urgent tasks, and how these two may or may not be related. As I read about these, I realize that I often do this internally with my work.

I know there are important things to do, many of which aren’t urgent. Finding time to get those done is useful, not only because they get off my plate, but the more often I can avoid creating urgency, the less stress I have. I also find that urgency can sometimes be my own fault for procrastinating a task.

There are certainly many times when managers will prioritize work for us, but I often find for developers and DBAs, that we have a fair amount of autonomy. Many of us also have a known backlog of work. Developing some skill and techniques to manage your own workload will serve you well, and you might consider adopting some of the ideas in the post in your own career.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Posted in Editorial | Tagged | Leave a comment

T-SQL Tuesday #119–Changing My Mind

After missing the last T-SQL Tuesday, I’m back for the latest invitation from Alex Yates. In this one, Alex asks us to write about something in IT where you changed your mind. Some belief you held, and then decided to go a different way. It’s a good topic, especially as the world has both dramatically changed and also stayed the same in many ways.

A Strong Belief

As a young man, I used to think strongly about lots of technology topics. Many of those have been argued about on the Internet in forums, chat boards, and even at times at events. I had my own thoughts, and often argued my own views.

As I’ve gotten older, I’ve started to hold those strong opinions a little looser. I still have them, but I also know that sometimes things might not be as clear cut as I imagined. I also have learned that my own knowledge is often incomplete, or my application of a technique might be more narrowly focused than I assumed.

I change my mind constantly, but I’ll give you a relatively recent one that has started to move my career.


I’ve been learning and talking about containers with people for nearly 10 years. It was in 2010 that I met a company using them extensively, and while enamored by the technology, I wasn’t sure how useful it was for me. This company uses Java, where versioning is an issue. In .NET, it’s less of a problem.

When Microsoft started to work towards containers in the 2015 timeframe, I had a change to take part in early discussions with program managers. These were casual, but I wasn’t convinced that this would really make a difference in SQL Server. I kept an open mind, but most of their arguments and thoughts felt self serving for Microsoft’s business rather than good technical arguments.

That changed sometime late last year. The work that’s been done on SQL Sever 2017 and 2019 to allow upgrades/downgrades, the scale out capabilities coming in 2019 (and with Hyperscale) and the possibilities of Kubernetes (or some other orchestration tech), make me rethink containers.

Containers are the future of SQL Server. I’d bet on it, though it’s going to be 5 or 10 years for most of us to get there. However, I’m spending more time learning and working with them because I think this is where databases will move.

I wouldn’t have said that two years ago, but my mind has changed.

Posted in Blog | Tagged , | Leave a comment

Very Hot Patches

“At best it would crash” is not a phrase I’d like to have to use as a data professional. That’s a quote from an article that the Azure team wrote about hot patching SQL Server. While this sounds very scary, it’s actually something being used now to patch the SQL Server code running Azure SQL Database.

Years ago I read a book where the hero was a programmer that had to alter and hack into live code on a mainframe, making changes to thwart the villains. It was a neat concept, and certainly daunting. As someone that had to write assembly code at one point, I had trouble keeping track of instructions when I could map them out on paper. Doing this on live code would be very scary.

The SQL Server code is not being changed live by a human, but code is being patched without stopping the sqlsrvr.exe process in Azure. There is a blog on the hot patching process, which I appreciate, though I’m not completely sure I get the minute technical details. Still, it’s an impressive feat of engineering to me, and this does make me wonder to what extent platform engineers might structure their code to allow more of this in the future.

Deploying changes is already a challenge for many of us with database code. Making changes, evolving our schema and adding functionality without downtime or excessive blocking is a challenge. Many customers that look to move to a database DevOps software development process often assume that our tools will just do this for them. They won’t, because any DevOps tools that help with automation don’t magically get around the limitations and restrictions that Microsoft has built into the platform.

Making changes in real time, without interrupting workloads involve some engineering challenges, but whether at the SQL Server platform level or the database code level, they are possible. It takes some work, some flexibility, and more importantly, some understanding of how changes can be made and the patterns that enable uninterrupted changes. There is often a space and time trade-off, and certainly no magic, though to our customers, it might appear that way if we do our jobs well.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Posted in Editorial | Tagged , , | Leave a comment

A #DevOps Discussion on Thursday with Abel Wang

I’m hosting a webinar later this week with  Abel Wang, one of the talented members of the League of Extraordinary Cloud DevOps Advocates at Microsoft. This Thursday, October 10, 2019, at 3pm UTC we’ll be discussing DevOps, and how this can both transform your organization as well as improve your career.

Microsoft has had an amazing transformation in the last few years, and I was fascinated by a few items recently when I watched Damian Brady (another League member) talk about the changes inside the company. I’m really looking forward to hearing what Abel has to say with all of his work with customers looking to build better software.

Register today and join me Thursday, October 10.

Posted in Blog | Tagged , , , | Leave a comment