Voice of the DBA

Category: Editorial

  • A Great Place to Work

    I have had quite a few employers in my career. Of the ones that paid me for computer work, I’ll say that there were 3 great ones (1 I owned), 2 average ones, and 3 poor ones. I’ve had a few other minor times or contract situations where I didn’t really judge or care one way or the other. A lot of time is spent at work, but if it’s days/week/(few months), I can deal with most situations. That being said, even at the poor places, I learned a lot and I grew, so I don’t regret them or wouldn’t want them removed from my past. There are always good and bad things about any job. As I tell my kids, every job is a job some days, even my amazing position at Redgate.

    Recently my employer, Redgate Software, was on a number of Best Places to Work lists in the US. We took 28th in the US (5th in Austin, 4th in LA, 10th in NY) with higher rankings when you filtered to mid-sized businesses. While I don’t work in those places, I do go to our offices, and I think we have an amazing culture, workplace environment, support, and training for staff. We’re a mid-sized company now with a bit over 500 people, which is amazing. I was person 146, but I’ve known the company since it was 8 people. As it’s grown, I think Redgate has done a great job under Simon Galbraith’s leadership of building a place to work that is productive and profitable, but enjoyable and interesting. Our current CEO, Jakub Lamik, has continued to help Redgate thrive, both as a business and as an employer.

    Many of you reading this are data professionals in some way and likely work for someone else. Do you think you have a great employer? Are you happy with the workplace, be it in an office, at home, or some combination? Would you vote for your employer as one of the best places to work in your city? I didn’t here, but I would. We’ve regularly made similar lists in Cambridge, UK, where I’ve most often visited an office.

    I worked at home for 5 years before I started at Redgate, and since then I’ve mostly worked at home. I regularly visit offices 4-10 times a year, mostly in Cambridge, but also in Pasadena, Austin, and New York. I appreciate that we built offices that are comfortable to use, with plenty of tech that makes life easy for employees. We are flexible with hours, and even the rules we set in place can flex or bend for individual situations. We hire smart, motivated people, and everyone learns how to both be supportive and accommodating while holding themselves and others accountable for work. I think we are sometimes too nice, but that might be my cut-throat US business upbringing compared to the UK style of work.

    To be fair, Redgate isn’t for everyone, and we have had no shortage of people leave in our 25-year history. We’ve also had quite a few people leave and come back, realizing not only is the grass not greener elsewhere, there are plenty of worse places to work. I don’t love everything about Redgate, but I do enjoy working with a diverse group of people from many different countries and backgrounds, with a very wide variety of experience relating to databases. I learn from many, get ideas from different viewpoints, and get the chance to try and better explain databases (DevOps, monitoring, etc.) from my point of view and experience.

    I loved working at JD Edwards, and I really enjoyed my partnership with Brian Knight and Andy Warren at SQL Server Central. Redgate is up there with those organizations as a great place to work and one I enjoy almost every day. Can you say the same thing? If not, hopefully, you find your situation more positive than negative.

    Steve Jones

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

  • Take A Vote and Accept Your Loss

    I feel differently today than in the past about many of the things I’ve seen technical people argue about. I’ve written about Tabs vs. Spaces and Singular vs. Plural, and others have debated commas before or after among other topics. While these might be interesting sidebars at lunch, I see them sometimes devolve into time sinks with teams revisiting the issues over and over during their daily work.

    These types of religious wars stifle a lot of productivity and often can linger for years. However, in many cases what I see is debate across weeks or months and then time spent to shift the way that large groups of people work inside of a company. In the last few years, I’ve seen customers argue about which VCS to use, which new CI tool to choose, or even about which secret store to use for their database credentials. Often these debates happen when there is already a technology in use.

    In most cases, the differences between many of these arguments are negligible. Lots of teams fall down on either side of a debate and find themselves very productive. Or not productive, but it often seems the difference is the staff, not the tool, platform, language, or style. Good people are productive no matter which way we choose to work.

    My view is that for most of these items, we ought to have a (relatively) short meeting. Give each side a few days to prepare, but then one spokesperson for each side gets 5 minutes to present their case on why the group should adopt their idea. Once everyone has presented, we debate for a limited time, maybe 15-20 minutes, vote, and then move in that direction. Ultimately, we’re trying to get software written (or deployed or managed or something) and not trying to decide the best way to format that code or choose a tool for CI/CD.

    This teaches people to communicate and learn to present a rational, coherent, succinct idea, which is a valuable skill. This also teaches us to work as a team and learn to accept decisions that don’t go our way. None of us wins 100% of the time in life, so make a good effort to lead others in your direction, but accept that they might choose a different path. In that case, learn to support the team in their efforts.

    The caveat to all of this is that inside of an organization, we often want a standard, so if something is already heavily used, just adopt that pattern or technology.

    Steve Jones

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

  • Hire Well

    In the last few years, I’ve noticed that the quality of technical workers can vary quite a bit in many organizations. I think most people get things done, but often not at a high-quality level. It’s one reason that I write, speak, and try to motivate more of you to work on your skills and your career. I want to see better software being built.

    I tend to work with more database developers than application developers and I tend to see more SQL code than C#/Java/etc. And I see a lot of poorly written SQL Code and poor data models that seem to have been built without a lot of thought put into them. Whether this is because of ignorance or just poor skills is hard to know, but I see a lot of code that makes me slightly cringe.

    Over time, many of us see that this technical debt limits our ability to improve things or make changes. Often these systemic issues linger because the development staff a) doesn’t know how to fix them, b) has other, higher priorities, or c) is afraid to try and make changes. Often it’s a combination of all three, which further limits the agility of the database and application teams. We end up struggling to keep up with customer demands, or we may pile on more and more technical debt. Often this leads to increased performance problems in the database.

    I was reading about development and staffing in this piece, which had an interesting quote: “I currently believe that there’s only one way to buy yourself out of technical issues and bad data models, and that’s buying a really talented engineer whose sole focus is fixing the problem.” Essentially, you need to do two things here. First, hire a smart engineer, and second, empower them to effect change. In many cases, I think you actually need two smart engineers: one database engineer and one application software engineer. Those people have to focus on improvements, refactoring bad data models and the code that depends on them, and slowly raising the level of quality.

    The piece gets a little sidetracked with the way vendors promise their products will fix your problems. In general, that’s not true, at least not without you adapting your process to their software. In my role, I’m careful not to promise more than I can deliver, and not try to minimize the effort required to change. I know it’s somewhere between using 10% time and a major overhaul, and I hope I convey that to clients.

    Ultimately, I think that we haven’t commoditized lots of software development, which is the point of the piece and the quote above. We need to get talented people, or we need to train them, or both. We need people that enjoy their jobs and find some purpose or satisfaction. Part of that is making their jobs more interesting and enjoyable.

    That also means there are many opportunities if you learn to be good at your job. Learn to build good data models. Keep up your skills that write efficient code, learn how to troubleshoot, and learn how to work well with others. None of those are easy skills to develop, nor are they quick to learn, but they can be learned with some effort. Document your progress, blog/write/speak, and I bet you’ll find your career prospects improving.

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

  • Learning NoSQL

    It’s a good idea to learn more about different technologies. I’ve been amazed throughout my career, and even now as someone working for a software vendor, how many different technologies I run into. I’m also amazed at how little bits of knowledge comes in handy, either to help me understand a problem or to help guide others with a recommendation of how to proceed.

    Many of us have experience with relational databases and tabular data. We are comfortable with it, even if we might struggle with a packing problem or using a tally table. However, do you understand how a NoSQL database might be different? Can you even name a few types of NoSQL databases?

    I find it valuable to know a bit and experiment a bit, as your devs may ask you if it’s suitable, or even how to work with one of these databases. They might even start using one and expect you can take responsibility for managing it, backing it up, securing it, and more.

    I wonder how many of you know MongoDB? What type of database it is or how it stores data?  What about Cassandra? Neo-4J? CosmosDB? I haven’t done much work with any of these, but I’ve learned a bit about them. I even spent six months digging into graph databases and learning how they work, how to model data, and how to query them. Part of this was SQL Server’s inclusion of graph structures, but part of this was a customer looking to add graph capabilities to their application. I learned a lot, and even delivered a few presentations on how they work.

    I’m not an expert, but I can have a rational, reasonable, informed debate about the good and bad things with graph databases. Enough to help provide an opinion on whether they might suit a problem. They solve some complex things well and I think they might be a good platform to add to some applications. I wouldn’t get rid of the RDBMS, but supplement it.

    This year I’m going to dig more into MongoDB and Cassandra. We have more customers asking about these platforms and we’re working on Flyway support for both of them.

    If you have any thoughts on NoSQL, or experiences, or even want to write a bit about them, let me know. I’m always looking to learn more, and I always need good authors.

    Steve Jones

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