Voice of the DBA

Category: Editorial

  • A 2020 Look at Software Developers

    Who are we? I think we often don’t have a good view, since most surveys struggle to get 1,000 responses. I know many surveys think that’s a representative number, but I think it feels low. I wish we’d get more data at SSC, but too few people participate in our efforts. The one place that seems to do a great job of getting responses is Stack Overflow. They released the data on their 2020 survey, and an article at Freecodecamp summarized some things.

    Everyone looks at this data differently. For example, in the top loved languages, I see these: Rust, TypeScript, Python, Kotlin, and Go. Of these, I’ve really only used one. The most dreaded language is VBA, and I’d concur, but the most wanted language is Python. More developers want to use this than any other. Interesting numbers, but these seem more like emotional items, not practical ones. If we look at what pays the best, the Perl is at the top. I don’t know anyone that primarily works in Perl, though to be fair, I’m Microsoft focused. At least in the tech clusters, most have some relation to some SQL technology.

    The database section is very interesting to me. This is my field, and I wonder how developers look at the world. The most loved db is Redis, and I’m not surprised. It’s key-value, blazingly fast, and relatively simple. I went through a couple courses at Redis University and found it to be a neat platform. SQL Server is 7th, with 50% loving it compared to 66% for Redis.  It’s also 8th in dreaded and 12th in wanted. Interestingly, while Oracle and DB2 are dreaded, Couchbase and Cassandra are up there. Redis is the least dreaded, though still 30% of developers dread this. My guess is that developers just struggle with databases in general and get annoyed by having to deal with them.

    The other interesting data point in the results is about searching for a solution online. Just over 50% of the people are happy to find a link they’ve already searched on Stack Overflow. That makes me wonder if we aren’t really learning to code better, or if perhaps we don’t bother because we can just search. For a lot of programming research I do in R, Python, and other non-SQL places, SO is a great resource and often gives me a concise, useful answer.

    Maybe this is the future of programming? Learn to search and what things to use, and don’t bother memorizing deep syntax or pattern specifics? I don’t think that works for SQL. We need to learn to be better. Perhaps this is why developers dislike SQL because it has few keywords and requires more programming skill to build efficient solutions. Those might be harder to search for on the Internet.

    Most developers work overtime, but it’s balanced among the time scales. Only a quarter of people do this every week, which I think is still too much, but at least this isn’t the vast majority. I think 15-20 years ago that would have been different. At last 60+% are slightly or very satisfied. Still about a quarter aren’t satisfied with their jobs.

    There are other interesting items in there, and if you are a developer, or you’re looking to grow your career, it’s worth spending a few minutes with the data, and looking at how you view the world compared to others. I don’t know that I’d try to follow the crowd, but I’d certainly think a bit about how I view the world compared to others.

    Steve Jones

  • No Excuse to Ignore the Database

    I’ve been writing, talking, and practicing DevOps for nearly 20 years. It wasn’t called DevOps back then, but in the early part of this millennium, I worked in a software team that embodied many of the three ways of DevOps.  We made small changes, we worked rapidly in short cycles, we adapted to our business needs, and we released often.

    And we included the database.

    At the time, this was a small team of about 15, and I had good control of the database processes, able to influence, debate, and demand our developers improve their skills regularly. We didn’t think about the database as anything more than one more challenge to overcome in order to build and release our software rapidly. Others feel that way as well and the ACM notes that a SQL database is no excuse to avoid DevOps.

    This articles covers many of the things I’ve been preaching for some time. We use automation, we adopt good techniques, we instill discipline in our work, and we continuously improve. The article provides a few techniques for using deploying database changes. I do think some of these are good ideas, but as with many things, the devil is in the details. This is a high level look at what you want to accomplish, but the actual mechanism for making changes will vary, depending on your environment.

    My employer is constantly searching for ways to improve database development, and we follow many of these techniques in principle. We recognize that testing and deploying changes needs to be easier and more reliable. As we build solutions, I think we’ve helped customers in many ways, however, my fellow advocates and I continue to preach a few things not in the article.

    First, we need to continue to improve our code skills, which include data modeling. Moving faster doesn’t mean we get to shortcut good design principles. Second, everyone working on software touching the database needs to work closely together. The data is the most important part of this process, and we can’t afford to let anything happen to it.

    I implore you to become better code writers, better software developers, and better team players. I also encourage you to look at DevOps as a set of principles, not as something you buy or install. Like much of life, adopting DevOps is a journey, just like your work with SQL. I’m sure that journey isn’t complete.

    Steve Jones

    Note: Podcasts paused this week as I have construction taking place at the house and nowhere to record.

  • A Virtual Trip Down Under

    I had a great holiday last week, getting away from my home for the first time in months. It’s been an extra strange time for me as I usually have a number of personal and business trips I’ve taken by this time, but with the pandemic, I’ve been at home, like most of you. However, we managed to find a campground open, and we packed up the family, dogs, and horses for a week in the South Dakota hills.

    I’m back, and while I won’t be getting on an airplane, I am going to travel virtually to Australia this week for quite an action packed Redgate Streamed APAC Edition. I’m slightly disappointed that I won’t be able to shake hands with Troy Hunt, but neither will Damian Brady, Greg Low, or Hamish Watson. I was on stage last summer with those three, and I immensely enjoyed the experience.

    This year we’re holding the event virtually in the Australia time zone, so I’ll be working late afternoon and evening my time for the event on Thursday, July 2. Time zones certainly get strange when I do things in Australia, and it’s the one place I’ve traveled where I feel really out of place when contacting this side of the world. The last time I was there, I watched my daughter’s evening volleyball game as I was eating breakfast.

    I get to deliver a talk, and then I’ll settle in to watch everyone else and enjoy the other talks. All of these are expert software developers and data professionals, and I learn quite a bit from them on a regular basis. If you want to spend time later this week, register for the event and join me, wherever you are in the world. The one good thing with these virtual events is that we can attend them if they fit our schedule.

    I’m excited to talk DevOps, software development, and, of course, security with the incredible Troy Hunt. This is an exciting week back for me, but also a busy one as I prep for a look at the software challenges down under.

    Steve Jones

    Note: Podcasts paused this week as I have construction taking place at the house and nowhere to record.

  • Moar Azure

    There are a number of choices for working in the cloud, aka, renting resources, but there are three big choices: Azure, AWS, and GCP. These three dominate the cloud services, though arguably AWS and Azure are way ahead. All three have lots of services, and all three can likely meet your cloud or hybrid needs, even if you work in a regulated industry or government.

    This week there was a piece on the work Microsoft is doing to increase their capacity. Between the 0365 Office services, Teams for collaboration, and their regular PaaS/IaaS workloads, they’ve grown quite a bit this year with the COVID-19 pandemic. As they try to increase their resources, they’ve had people working round-the-clock to add new servers. I’m sure they are still using containers, but likely they are struggling to fill these with new hardware.

    They’ve also been adding bandwidth, which is a bit need between the data centers. I had no idea they have their own undersea cables, but apparently they do. I suspect Amazon and Google do as well.  There is a note that they’re also coding, trying to improve efficiency. After all, while you can throw hardware at a problem, many of us know that bad code can overwhelm those efforts. We see it in our jobs every day. I would hope that many of our organizations that might be depending on software more realize that better code is an advantage for us and our customers.

    I know Microsoft runs a lot of their own stuff on Azure, including development work, and they’ve had to reschedule their internal workloads as well as move other work outside of regions. I think that’s fine in many cases, but with different laws in different countries, I hope they’re extremely careful about what moves. Data sovereignty can matter.

    If you read through the article, it seems that Microsoft has learned a lot about adapting their work methods, both with people and systems, to meet the increased workloads. This is one area that I hope we see some detailed technical blogs, which might help others learn how to better manage their own resource challenges, or even learn to code better. While some of this might be proprietary, with the move to having many things open source, why not share ways to improve application resource usage.

    Steve Jones