Voice of the DBA

Tag: career

  • 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.

  • Searching for Answers Inside

    How easy is it for you to search your codebase, especially across projects, and find out if there are dependencies, similar code solutions, or even other incidents of similar problems? Do you feel comfortable that you can find out what you need to know across and throughout your organization?

    Or is it cumbersome for you and others?

    In the 2019 State of DevOps report, one of the important areas that designated high and elite performers was their likelihood to easily find internal information. Those users were more productive when using internal sources of information to find knowledge related to their work. They also know how to, and are able to use external sources as well. I certainly know that if I needed to write T-SQL everyday, having access to the SQLServerCentral forums would be invaluable for me, and I’m sure it is for many of you as well.

    I think one of the very hard things for inexperienced people in any organization to do is find information. So often knowledge is gained over time by employees that have spent significant amounts of time working on systems. No matter how much we might preach and mandate documenting things, many items won’t be written down. Over time, many of us internalize lots of information that might seem obvious and unimportant to us, but is necessary for more inexperienced people to succeed at different tasks. If you doubt this, just look at any DR test where someone tries to follow the directions written by experienced pros. They’ll fail almost every time because we don’t document every step.

    I’m not sure we should even try. I think the idea of trying to help others more easily find information is a better solution. Having tools to enable this can certainly help new people get up to speed quickly, as can group programming (or administration) efforts like pairing or mob style work. We might not easily ensure someone could pick up the pieces if no staff were around, we can make it easier for those that want to learn and succeed to seek out the knowledge they need.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Working in Smaller Teams

    I don’t know what the average size of a team is, but I know I’ve worked in all sizes in my career. I’ve had teams of 1-3, which is common in database work, but I’ve also been on a 20 person Ops team. I’ve been in 2 person development teams, 25 person teams, and everything in between. At Redgate, it seems most of our development teams are less than 10 people, but I’m sure we’ve exceeded that at times.

    I do think smaller teams are better, and they are certainly easier to keep track of what everyone else is doing. Once a team becomes large, even with regular status reports or meetings, there is too much information to easily hold in one’s memory about tasks other than our own. Knowing what others are working on can be invaluable in coordinating and avoiding conflicts. This also ensures that the team can more easily ensure code is written in a similar fashion and knowledge is easily shared.

    There is research that seems to indicate that smaller teams are better. This article talks about some of the reasons small teams seem to perform better. These all seem to intuitively make sense to me, and I’ve certainly experienced people behaving in these manners. In the second piece, there is advice on how to get teams to be more effective. The biggest advice seems to be a lot of what we do at Redgate. We empower teams, give them tools, and don’t manage them in traditional ways. We hold them accountable to get work done and meet goals, and we challenge them, but we want them to move forward, not work in a particular way.

    Building a team is hard, and getting a team to perform at a high level is very hard. I do think that the internal talent and motivations of individuals can make a big difference, but I also think that management can bring out the best in people, or it can ensure you never get anywhere near the potential of team and encourage under-performance.

    It constantly surprises me how often I find managers and their organizational culture built to control and not inspire employees to do their best. I think it’s a holdover of years of working a certain way, rather than supporting and encouraging each person supervising others to get the best from others. I hope this changes, but it’s certainly something I try to detect in interviews before I ever commit to a new position. I hate working for micromanagers and never want to do it again.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • What You Should Know About Coding

    What are the important things you should know about writing T-SQL code for an organization or on a team? I’m sure that many of you have ideas, and please, feel free to share them with us with a comment. As you think about your answers, think about this as well: what do you wish you’d have known when you started writing code?

    I went through university quite some time ago, over 30 years ago, and some things have changed in this industry. Not so much in the way we structure the code we write, though we have gotten much better in some ways. Rather the way that organizations work has dramatically changed. It’s not just this new DevOps thing, but more that many organizations are starting to expect developers to do more than sit in a cube and react to a set of tickets or a specification written months ago.

    More companies are expecting developers to think and interact with others, knowing more about other parts of their environment and application. More developers work in teams, and perhaps very interesting to me, the once dreaded and heavyweight code review that seemed to die during the middle of my career has become a commonplace, quick task that developers do every day now.

    There’s an interesting piece, written by Ryland Goldstein, about the things he thinks developers should be learning in college or early on. I thought it was interesting to see him open with lines of code (LoC) as a metric, and show the growth in code for some large applications. To me, LoC hasn’t been important at any point in my career, but I know it was talked about while I was in school.

    He does talk about some things that good code should have, and I agree that most of the time the language doesn’t matter. I do think his points on reading code, and learning to work with other people’s code is good. To me, this really means we want to adapt and learn to write code in the style that our team uses. That can have a huge impact on group productivity, when we can write in a similar style, and then also read (and review) code quicker because it’s all the same style.

    Perhaps the best line is this: ” Every single member of our team (including me) would have a full blown panic-attack if someone ever suggested committing un-reviewed code.” I think too often the database side of things ends up committing (and deploying) un-reviewed code too often. We could to better, even if we need to teach someone how to review our code. Having a second set of inexperienced eyes might not prevent mistakes, but it certainly might help others learn to write better database code.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.