Voice of the DBA

Category: Editorial

  • T-SQL Context Switching

    Studies have shown that reading someone else’s code can be both stressful and time consuming. Developers that pick up unfamiliar code find themselves spending much more time comprehending the code than with more familiar projects. I think this might be one of the reasons that so many developers want to build things themselves from scratch, or in least build new things in their team. They find their own code easier to understand.

    This might be less of an issue with SQL code, which is often more straightforward for simple queries, but I  do find that complex queries can be confusing to many developers if they didn’t write the code. This can especially true when another developer has used some rather uncommon trick. I’m also sure that plenty of people will cut and paste solutions, from places like SQLServerCentral, without understanding how the code works, but even decoding the answer to a question you’ve asked can be hard, even if another poster tries to explain how the code works. Hopefully most developers make an effort rather than coding a poorer solution or deploying code they don’t understand, but I’m sure some don’t when facing their own pressures to get work done.

    With staff turnover and the need for developers to work on multiple projects, time spent interpreting code can be a drain on the efficiency of all developers. In addition, since individuals often find code easier to read in certain formats, tools like SQL Prompt can help, but there are plenty of easy ways to keep your codebase readable for staff. Dr. Greg Low has written a nice post on standards, which I think outlines some of the things I like to implement in a team. Having a known way to structure our code can help us communicate intuitively in a group, rather than require extra communication.

    Actually, I don’t care what standards exist in a company. I don’t have strong feelings about any particular way to structure code. I prefer spaces, but if we decide on tabs, I think that’s fine. I’ll work within the framework we’ve built. What I do think is very important is that you have some standards. They don’t have to be perfect or exhaustive, but they do need to be followed.

    If you don’t have standards, I suggest you start creating them. Add them as needed, when a developer finds a reason to make a decision, get consensus from the rest of the group and document the standard. Like other things in DevOps software development, we can grow these over time as we need them.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Republish: Documenting with Tests

    I’m at SQL in the City Summit – Sydney today, likely loaded on coffee to get through 2 days down under. In any case, you get Documenting with Tests

  • Live and Learn

    I love this quote from Randolph West: ” Listen to people. Have strong opinions, but loosely held. If you are wrong, admit it and move on. Learn from those around you.”

    This is from his blog on diversity, which I support and agree with. He has some great thoughts and the post is worth reading. Maybe you appreciate diversity, maybe you don’t, maybe advocate for or against it, but in all those cases, I think his message is worth reading.

    I am not going to talk about minorities or ethnic groups here, but rather diversity of thought. That first quote could apply to software development in general, and certainly the idea of a DevOps process for building applications. It’s good to have strong opinions, and good to be able to debate and argue them, but it’s also good to keep those strong opinions loose. Many of us find as we get older and more experienced that we often have a huge gap in the things we don’t know that we don’t know.

    These are the unknown unknowns, as opposed to the known unknowns, which are things I know I don’t really understand. I’ve remarked to a few people that learn new things every week, and I feel stupider every week. Why? I learn things I never knew existed, so I constantly expand the knowledge of my own ignorance. It feels like I learn two things and then realize there are nine more new things I don’t know anything about.

    Today’s software requires a team. Maybe more importantly, today’s software requires a team of both application and database developers, as well as infrastructure staff, that can help put together an entire system. We need to work together, not independently with hopes of efficient integration of our ideas later. We want to shift left, and coordinate and communicate earlier. That needs strong opinions on how to best do a job, but a loose grasp on those as we might need to adapt to work with others.

    Read Randolph’s blog twice. Once thinking about the topic of human rights, and then once more thinking about teams and our opinions on building software. It’s thought provoking and worth a few minutes of your time.

    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.