Voice of the DBA

Tag: career

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

  • Staying Focused

    Most of us know when we’ve been working in the flow. Time ceases to exist, and often seems to have flown by when we stop working. We may not eat or take a break, just focusing on a problem and tackling it in a very single minded fashion. Whether this is a development task or some infrastructure effort, we can achieve flow.

    At the same time, many of us struggle to find the flow in a busy workday of meetings, interruptions, music, slack messages, and more. Attention is a commodity, and one that many of us struggle to focus on a single task. We may find that if we do achieve flow and something interrupts us, then we struggle to get focused again.

    When I give presentations and talk about remembering what code we wrote or changes we made last week, plenty of people will chuckle along with me. It’s a challenge to remember what we were last doing, especially when we move to more DevOps style work with small chunks of tasks being completed. Even coming back to work the next day, after an evening of family or hobby time, can be distracting.

    How do you get back into the flow quicker? There are lots of books and advice around, but I thought this programmer’s look at how to keep himself organized around a busy life was interesting. He uses some tools, primarily based around software coding, to help remind himself quickly of not only what tasks need to be tackled, but where he was in the flow of the work. In some sense, this reminds me a bit of Andy Warren’s efforts at keeping SQL Saturday organized.

    Flow is hard to come by. To me, this is one reason why more workers ought to have private offices and less meetings. A developer or DBA in the middle of the zone, working in the flow, needs to be left alone. That’s the most productive time for them, when they are most efficient and valuable. More organizations ought to try and foster this, not inhibit it.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Growing and Changing

    When I started with SQL Server, I worked on OS/2 and SQL Server 4.2. Eventually I moved on to SQL Server 6.5 at a few places, one of which had heavy workloads. While I liked v6.5 much more than v4.2, there were issues with nested views, and certainly issues with heavy tempdb loads. In fact, at one job, I banned temp tables unless we had no other way to get queries to work. This helped stabilize some of our code, and we essentially had a review group that a developer had to convince to allow temp tables since there were situations where we needed them.

    I was reminded of this recently after Grant published his Best Practices and Band Plans editorial. There was this comment, which noted: ” I have talked to some people that state “our best practices is to never use…” because they tried it when it was first introduced in SQL Server 2005 and it didn’t work for them so now they won’t use it at all. ”

    I’ve encountered this in my career, and I’ve been guilty of it. It took me a few versions, and more complex code, to start thinking in terms of temp tables at times. I still try to avoid them, but I’m not afraid of them, and I know SQL Server handles tempdb loads better with each version. They are a tool I reach for sooner, but not immediately. I still try to get a simpler T-SQL query if I can.

    Many developers and DBAs have plenty of experience with T-SQL, but how often do they update their knowledge? How many people question that the way they first think to solve a particular problem is the best way? The T-SQL language has grown and changed across versions. Some language changes are great, like the OVER() clause for window functions. Some might not be so great (STRING_SPLIT among them) or have limitations that you might not expect. Without questioning the way you write code and periodically looking for new techniques, you might not be aware that the amazing code you wrote a few years ago could be better structured today.

    There is a balance between relying on your knowledge and trying new things. Certainly most of the time I’d expect a developer to write code based on their experience and what works well, but I do think that you also need to periodically investigate new techniques. Regular learning is part of what we hope to help you with at SQLServerCentral, with articles, the Question of the Day, and blogs in our daily newsletter. Maybe you don’t read every article, but go through one once every week or two. Whether it’s something you do every day or have never tried, you might be surprised what you learn.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.