Voice of the DBA

Category: Editorial

  • The Challenge of Early Tech Decisions

    When we design software or databases, we have to make decisions right now. If you work in as many environments as I have, this means I’m often picking a tool, platform, version, technology, or something else without a complete set of information. In some cases, I’m actually writing code (SQL or C#/Java/etc.) without completely knowing the business problem I’m solving. I do know what someone described, but as many of us find out, those descriptions often prove to be lacking.

    Over time, we refine the code with feedback from users, which is why DevOps has become so popular. We write the best code we can and then quickly alter code if we haven’t hit the mark. We constantly adjust by making small changes and improvements.

    However, changing the code is one thing. Changing more fundamental technology choices is harder. There is an interesting post on the disproportionate impact of your early tech decisions from one of the developers at Stripe. One of the examples given is for the database platform, which was Mongo. The piece notes that once the database platform is chosen, most groups never switch platforms. I think that’s been true in many places I’ve worked. The same thing for languages and cloud providers as well, as once a choice is made, rarely does a team, much less an organization, switch.

    Why is this? Is the cost of switching that high? I think it is. I’ve seen a few organizations want to migrate from a licensed relational platform to one that is free and OSS. However, the time it takes to rewrite code, the time to build new expertise, learn the tips and tricks for a new database (or other platform technology) is significant. A team can make no shortage of mistakes during this process. Is that worth the cost of licensing?  Perhaps. Perhaps not. It’s a hard thing to decide. With the high cost of labor, I think it’s hard to make a good argument to rewrite.

    In many cases, I’d argue that core changes to your technology stack ought to be considered, but understanding that no tech will solve all your problems and you will make lots of mistakes in the process of changing. Does this mean you need to make a great decision when you start working on a project? In my mind, no. Make the decision to use what your team is most familiar with and then live with it.

    And be open to using targeted technology for specific needs. Lots of transient data in a busy workload? Add Redis to your database stack. If you need full-text search, consider ElasticSearch. Maybe add a graph database (not SQL Server) if you need queries in this problem domain. Use what works, and learn to use it well.

    That last sentence might be the most important. Any technology can likely support most workloads, but you need to write good code and learn to use the platform well.

    Steve Jones

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

  • Fixing Impostor Syndrome

    I think that most of us feel like an impostor at some time in our lives.  We will get asked to do something we’ve never done, with others expressing confidence in us. We may tackle the task, or we may not. We may succeed or we may not In any of those cases, we may still feel like an impostor, someone that isn’t really qualified to do this thing. Many of us continue to feel this way in our careers, suffering from impostor’s syndrome.

    While I know that I’m good at my job, good at working with SQL Server and teaching others to do so, I still suffer from impostor syndrome at times. There are periods where my mind wonders if I’ve just gotten lucky and slipped through some evaluation process. Maybe my knowledge hasn’t been well tested. Will someone like my boss, or their boss, question my skills at some point and get rid of me? Will I be able to find another job if that happens? Can I really compete with others out there? This isn’t a constant or regular feeling, but I do experience it at times.

    I work with technology, helping customers better manage their database software. However, I also work in marketing, which is a completely different kind of job. Someone in my company posted an article about impostor syndrome for marketing, which I found fascinating. This could be written for technologists or, perhaps, any other profession. Read through it and think about a few things that I saw in the article.

    If you feel you don’t have the knowledge you need, you’re not alone. I think that’s very true in technology, where it feels that the pace of change from vendors, from peers, and what you might read in the media (including here at SQL Server Central) can make anyone feel as if they don’t know as much as others. I do try to acknowledge to myself that others feel as I though. It’s slightly comforting, but not a lot. Especially when I converse with some amazing experts. Discussing execution plans with Grant or T-SQL with Jeff or HA with Allan can cause me to question my knowledge and success.

    The second thing to think about is how poor the state of the industry can be. Whether this is the skills of others or the architecture of software, systems, or databases. How often have you seen software that’s been purchased or deployed and you question the decisions that got it to this state. Are you amazed at how many problems you see? Do you start to question the skills of others? I know at SQL Server Central we try to help others, but I can also be amazed at the lack of knowledge out there about what I’d consider to be simple topics. At the same time, I recognize others may be in a different place in their journey. Having empathy and compassion keep me answering questions. The need to keep answering them reminds me that I do know quite a few things.

    Lastly, education helps. I constantly experiment and build demos of different things. Often these are learning experiments. I don’t know that I become an expert in many of them, but learning more about how something works, or increasing the depth of knowledge in some area I’ve worked help me to build confidence to tackle the challenges I face (or my customers face).

    The article notes that marketing is an imprecise science. I think software can be that way as well, despite the growing number of “engineers” in our industry. Like marketing, there are no shortage of people who think they know it all, or use boisterous, blustery, loud discussion to convince others that they do. Even hen their choices or design might be suspect or perhaps their approach is outdated. One of the tenets of DevOps is that we continuously learn and experiment. I try to apply that to my own knowledge, and find it can help me feel like less of an impostor some days.

    Not all, but there’s always tomorrow, and I usually find that these feelings pass with time, especially when I apply myself and continue to grown and learn.

    Steve Jones

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

  • Developer Optimism

    Developers, in general, are very optimistic about the code they write. This is likely one cause of their estimates of the time required being low, as well as the various bugs that slip through because of corner cases that appear for the problem being solved. Often developers think they’ve considered the various ways this code ought to work and covered all the possibilities. Usually we find they’ve not thought about the problem from other perspectives and need to adjust their code.

    They often also feel that their code is superior to others, and that they can examine a problem in a new way. One of the reasons that I think many developers want to rewrite systems in some new technology or new way, embracing the Not-Invented-Here way of looking at other people’s code. They want to write their own solution.

    Of course, many developers these days don’t eschew all code from others. Usually, it’s just other people in their organization, as a developer will embrace some random open source project they’ve discovered, sure that using this library/language/whatever will make their code better. While I do think there are examples of some new tech that is better than what’s around, I don’t know that any of them are a panacea. While F# is praised in many circles as better than C#, it’s not widely used, at least according to surveys of the top programming languages in use (IEEE, SO). It must not be better enough to get more projects to use it.

    What is widely used is SQL. In fact, if we look t0 other database languages, nothing else is close. While I’m sure plenty of those C# and Java programmers use LINQ or some ORM to produce the SQL code, I don’t know many competent or highly regarded developers that can’t write some SQL code or don’t regularly write SQL.

    There are some interesting ruminations on the optimism of developers in this piece. It made me smile, and I like the practical ending. While you can debate and discuss things, ultimately we need to ship code. And we are almost always better off using a technology we know rather than searching for a perfect new one to solve our problems.

    When working with databases, relational or even most of the popular NoSQL ones, this means knowing SQL. And when trying to solve our database problems, in many cases, this means learning to better write SQL and build relational entities, not abandoning our platform for some new shiny one that we think will make everything run smoother.

    Steve Jones

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

  • Republish: Learning through Puzzles

    I’m still in Hawaii. Hopefully things are amazing. At this point, I’ll have been on Maui for 5 nights and starting my fifth day in paradise. Possibly I’ve posted pictures on Twitter or Insta, so you can follow along there.

    In the meantime, you can re-read Learning Through Puzzles.