Voice of the DBA

Category: Editorial

  • Working in a Distributed Fashion

    Recently at the Redgate Summit, Kendra (b|t) noted that all the developers working for her are doing so in a distributed fashion. She is a product manager at Redgate, and her team uses git to move source code around and share it with different members for the applications they work on.

    For database work, I often see people using a shared database, which can create issues between developers, though many teams accept this as a part of working on the same project. We often just expect that our code is in the shared database, which means we don’t need to actually move it around. Hopefully, we do put it into version control.

    Has anything changed during the pandemic for how you work with your team? Or with other teams? I assume you don’t see people, but you do need to share things, or maybe you’ve moved away from shared databases. In that case, you might have some tricks for sharing technical code or other things that are a part of your work.

    Most of our work in this business is digital, so we likely adapted fairly easily to remote work. However, it might not have been completely seamless, and if things have changed, maybe you want to leave a comment on what’s different.

    For most of the work I typically do, it was always remote. While I miss collaborating with people in person, something I used to do regularly, the actual bits I need to move and share work in the same way. Actually, they work in more ways, as we’ve found new and interesting ways to share things outside of email and chat. Mural, Kanban boards, and even more video recording and posting have become more a part of my work day than they ever were before the pandemic.

    Steve Jones

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

  • Tool Limits

    In many jobs, there are a variety of tools that people use on a regular basis. Chefs buy knives, mechanics buy tools, doctors buy stethoscopes, etc. While many of us in technology don’t always have to buy tools, some of us certainly do. When there is value and it makes sense, many of us have purchased IDEs or add-ins or a utility that makes our work easier.

    Our tools are different than physical ones. We need a place to install them, but we often have employer-owned workstations, which complicates matters with licensing and rights to install. Bringing tools with you, or taking them with you, is often a strange situation, especially as our tools often need “privileges” to connect to other systems, which may be a problem for many employers.

    Many organizations do provide some tools, and we can certainly build others. We know how to write scripts, utilities, code generators, and more. We may get an IDE or some other commercial tool, which often ensures that all team members work in the same manner, though we may find a need to extend or configure how it works. My employer, Redgate Software, builds tools like this for database developers, and we strive to ensure that our tools make your job easier, and we try to ensure you can extend or integrate our tools into your work.

    Forgetting the hassles of purchase and installs, today I’m wondering what you think about the tool you do use. What tools do you use, and what are the limitations or hassles you find? Are there issues with your tools that inhibit productivity? These might be ones someone in your organization has written, or those they’ve purchased. Or maybe you’ve extended some tools to work in a different way and you’re proud of your work. Let us know about how tools might dramatically help or inhibit your efficiency.

    Steve Jones

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

  • My Time is Valuable

    In most of my jobs, I’ve been given tasks to accomplish, often without a lot of my own input. Someone triages work, or develops a project plan and then assigns me things to do. Often these are fairly narrow pieces of work, but with some latitude on how I might actually complete the task.

    Over the years, I’ve been asked to do things that weren’t a part of my job. At one small company, I spent an afternoon making Ethernet patch cables because we needed them, I knew how, and my boss said it was a good break for the two of us. At another job, I was asked to help go through the separation process when employees left, zipping up files, archiving mailboxes, etc.

    At the same time, I recognize that for my salary, neither of those were a good use of my time. At least not from an ROI perspective for the company. Those are simpler, low value tasks, and for someone that is paid above a beginning level, these were expensive resource costs.

    As we look to improve how software is built *and* managed, we want to take away low value tasks that don’t require human intervention. We want to use computers to do as much of those tasks as we can. That’s a lot of what DevOps tries to get us to adopt as part of our daily work.

    However, this can even include tasks where we might think a human is needed. I heard someone say recently that they shouldn’t be spending time with auditors walking through logs or looking up process documentation. That stuff ought to be produced and available automatically or in a a self-service way.

    Improving the efficiency of our workforce should mean that we don’t spent time doing simple things that can be handled by computers. Sometimes it’s not easy to decide if the automation or tooling is necessary, but at each point we ought to consider the cost of building and maintaining some solution over the cost of an individual spending time there. Often, though not always, we can find a little software development saves a lot of future costs.

    Steve Jones

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

  • Every IT Organization is a Snowflake

    I was listening to a presentation on IT organizations and how they can change and improve in the future. At one point the speaker said that “every IT organization is a snowflake.”

    Is this true? Do you think that each place you’ve worked is completely unique? Certainly the names of servers, IP addresses, and plenty of technical details differ. The internal applications are coded differently, colors, shapes, UX, all could vary.

    But do you think that your IT group is a snowflake? That term in some sense means unique, but in a derogatory way. It is used to represent people who are easily offended by something different. While I’ve not always been pleased with the way an IT department is structured or managed, I’m not sure I’ve been offended.

    I do think that every organization has some assembled its staff, process, technology, and more into a unique set of resources. However, I also think there are many commonalities between how the departments are run. After all, managers change jobs as often as technical people, and they will bring their processes and habits with them.

    While every situation is unique, I don’t know I think that many IT departments are snowflakes. As I work with customers, both in development and operations, I find many of them fall into a few broad categories in how they run their business. If you disagree, leave me a comment today.

    Steve Jones