Most teams find it hard to “do DevOps” in the DB for several reasons. This talk summarizes what I’ve learned over the last decade, studying teams that succeeded as well as those that tried. I’ve distilled it all into concrete, practical steps you can take to improve.
QCon is one of my favorite technical conferences. The content is unbeatable—it’s curated and sourced talk-by-talk by experts who chair each track. The experience is top-notch for speakers and attendees, and the conference is structurally inclusive and welcoming. I spoke at QCon San Francisco last year, and I was slated to speak at QCon NYC this year—but I’m not able to. Instead, I reached out to my network (thanks!) and was introduced to a talented speaker I want you to know about.
Applying DevOps principles and practices to the database can make software development processes faster, better and cheaper. Yet most companies do not include their databases in their DevOps initiatives because they face a variety of challenges to make it work.
Why is it hard to apply DevOps to databases? How can we get better at it? This talk addresses those questions (and more) by exploring the real-life stories of teams that successfully changed their entrenched culture, workflows, and tooling—and others who tried.
It’s easy for modern, distributed, high-scale applications to hide database performance and efficiency problems. Optimizing performance of such complex systems at scale requires some skill, but more importantly it requires a sound strategy and good observability, because you can’t optimize what you can’t measure. This session explains a performance measurement and optimization process anyone can use to deliver results predictably, optimizing customer experience while freeing up compute resources and saving money.
Over the past few months, I’ve been invited to be a guest on several podcasts that focus on DevOps and software engineering. I’m posting links to those below, for those who are interested.
I bought a Mighty Vibe, which is like an iPod Shuffle for Spotify. It’s a small, simple, easy-to-use music player that downloads music from your Spotify account and frees you from your phone. It supports wired and Bluetooth headphones. In my testing it’s easy to set up, works well, and sounds great. It’s much nicer than the mp3 players I’ve bought to let my children listen to music.
Does EXPLAIN confuse you? You’re not alone. This talk will help you understand what EXPLAIN output means, how to interpret it, what’s good/bad in a given EXPLAIN plan, and how to change queries, indexes, or schema to get better query execution plans.
Last week I “finished” a new medium-sized book (an ebook—that is, a PDF). But even as we downloaded the final PDF from Google Docs and uploaded it to our company website, I already had a file full of errata and omissions. Some of these are substantial problems, but my opinion remained almost unwavering: ship it.
I was raised in an environment where feelings were minimized, denied, brushed aside. In some circumstances, acknowledging feelings could even be risky. As a result, I adopted a mostly unconscious perspective on feelings which didn’t serve me very well. Recently, however, I’ve become more aware of my feelings, and I’ve been surprised and pleased to learn what they have to teach me—and to rediscover thoughts, which I now also see in a new light.
I’ve written a new 65-page ebook, titled DevOps for the Database. Drawn from what I’ve observed over the last 15 or so years in my own experience as well as that of many others, it tries to answer why and how some organizations deliver value to customers fast, run data-intensive applications with high quality, and have great engineering cultures—and why some don’t.
Do you know how to be a great conversation partner? I know I’m making progress, but it still feels like I have a long way to go. I’ve had a lot of teachers—my uncle, great books, friends, my spouse. But Celeste Headlee has earned a place high on my list of influential teachers of conversation.
This is the last in a series of scheduling- and calendaring-related topics. This one’s about my overall strategy of using scheduling as a tool to manage my time. Clearly, managing my time isn’t the same as managing my calendar, but managing the latter does help with the former. The essence of my strategy is this: I care about my time, but others care about my calendar, so I can forestall a lot of intrusions on my time by using my calendar intelligently. To do this, I block off time, keep an eye on how many meetings I’m in, schedule my work when I need to, and tell people how I prefer to use my time.
Today’s blog post is about—you guessed it—more calendaring and scheduling stuff. This time I want to focus on one of the most unbelievably wasteful uses of time: time spent scheduling meetings. It’s a necessary evil, but can we at least optimize it, and get the lesser of the evils?
Following up on my post about the benefits of speedy meetings, here’s a collection of tips that I think improve calendaring etiquette. Some of these are personal preference, but all of them feel like genuine improvements to me in real life.
Having recently written quite a bit about email and communication, I want to turn to some of my backlog of thoughts on calendaring, scheduling, and meetings. I have learned a lot of techniques that I believe make me and my colleagues more effective and efficient, but there’s one simple tip that rules them all. It’s this: don’t schedule things back-to-back—leave gaps. The reasons why are a lot more important than I thought at first, and I encourage everyone to do this.
After writing a series of posts on various email clients, it should be clear that I’m still an email user. But I am doing my best to move as much communication from email to Slack as possible. I like to have as few “systems of record” and “official communication channels” as possible, and when I can, I’m making Slack my preferred one. Why do I want to do this? How is Slack better than email? There are actually a few fundamental differences; it’s not just the same distraction in a new place.
