Tag: career

  • Back at Small Data SF in 2025

    Today I’m in San Francisco at Small Data SF 2025. I went to the conference last year and thought it was a great event. Watching people talk about data and how we might look at managing smaller systems, at dealing with the challenges of exploding volumes by querying, storing, and handling less data was fascinating. The event had me me really thinking about ways in which we can build better performing (and cheaper) systems.

    To be clear, small data isn’t very little data. Often this is still 100s of GB, perhaps low TBs, but it’s getting away from the idea of thinking we’ll be working on PB-sized big data systems, or that we even need to.

    Last year there were lots of talks on data analysis, querying, and even AI, but using smaller sets of data in practical ways that provide value to organizations and individuals by judiciously choosing data sets. Either recent or representative data.

    This helped me think of new ways for subsetting, which is something I’ve been pushing at Redgate for our TDM product.

    I’m looking forward to the talks. This is a quick trip. I skipped the workshops yesterday since they weren’t that great last year (too many product/company pitches from Silicon Valley) and flew out last night after coaching kids in their first practice. At the conference today listening to talks and doing networking get together after before flying back early tomorrow.

    A quick trip, but I’m sure I’ll lots to write about (and think about) in the future.

  • Can/Can’t Do/Don’t

    The other day, I asked my daughter if she wanted me to make her some eggs. She responded with a “Yes!” in text and came to sit up at the counter while I cooked for us both. We chatted a bit, and at one point she said, “Thanks for cooking, but it’s not that I can’t cook.”

    I laughed a bit and responded with “this isn’t a can/can’t situation, it’s a do/don’t or will/won’t one.” I know my girl can cook; I made sure all my kids learned how to cook. It’s that they often choose not to, hunting for leftovers, going for takeout, or skipping meals.

    I’ve never been one who likes to hear “can’t” from anyone. Even today, when I coach kids and one say “I can’t do that,” my response is “yet. You can’t yet.”

    It’s easy to think that because you don’t know how to do something, or don’t have confidence, or you’ve not done it well (or right) in the past, that you can’t do it now. That could be true, but often I find people default to “can’t” when they really mean they don’t want to do something or won’t do something. Easy to confuse those, and easy to brainwash yourself when using the wrong words too often.

    There are things I can’t do. For example, I can’t run a 10.0s 100m dash. I can’t dunk a basketball, though there was a time I could. However, on the ranch or at work, I rarely find that I can’t do something if I apply myself with a little curiosity, effort, and experimentation. I can learn most things and do them well enough to meet a goal. Someone else might do them better, but I can learndo them.

    I see too few people in the world who aren’t curious at work, aren’t willing to put in extra effort to get a task completed, or don’t feel an urge to tackle tasks outside of their comfort zone. I see fewer people dedicated to making an effort to learn outside of work time, whether on their own or at an event like a SQL Saturday.

    Most of the people I see succeed and thrive in jobs aren’t smarter than others. They just do the work. And if they don’t know something, they teach themselves what they need in order to get the job done. They drive themselves forward.

    Life is hard, but it gets easier when you want to put in effort to make it better.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • The Journey to PostgreSQL (or anything)

    Most of you reading this work in technology, and I assume that you’ve had to learn something new on the job. Technology is constantly evolving, even on our existing platforms. On top of that, we are regularly given tasks that are outside of our current skill sets. Maybe not far outside, but to meet the changing demands of our jobs, we need to learn new things.

    I ran across an interesting post (on a new site) from Brent Ozar. I think that guy writes as much as me, but he wrote this one: Why I Started Using Postgres (And You Might Too). It’s a little provocative, but there are good posts on the site about things Brent learned in PostgreSQL. I won’t go into whether learning PostgreSQL is a good idea.

    The thing that struck me in this post is that Brent knew that this move was a risk. He was worried about moving to a new platform, despite all the reasons he had for doing making the change. I would bet a lot of us are in similar situations. It might not be PostgreSQL we are being asked to learn, but it could be Fabric, Databricks, Python, PowerShell, CosmosDB, or whatever other thing someone in our organization thinks is cool.

    The best sentence in here is this: “I gambled that I’d be able to learn how to do performance tuning quickly enough, …, in time to head off issues.” That’s the attitude I’ve often had in my career when I get requests to do something new.

    I’m willing to bet on myself.

    You should be willing to do so as well. Not bet on me, but on yourself. I know you don’t want to work 80 hours a week to learn, or get stuck trying to solve problems every weekend with new tech. However, I hope you are willing to do that for a week or one weekend. You’re willing to do some reading at night or experimenting during lunch in order to make something work.

    You’re going to have tough times. You’re going to question if you can make something work. Getting comfortable with being uncomfortable (for short periods) is how we grow and learn. It’s how we take leaps forward.

    It’s how we take advantage of opportunities that are in front of us.

    There are always opportunities to make a difference, to effect change, to build something you are proud of or that your organization values. Those stressful times when you drive to make something new succeed and have to learn a new skill in the process, these are the times when you can take advantage of an opportunity.

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

    Note, podcasts are only available for a limited time online.

  • The Improvement Limit

    I caught a short post from Gary Bargsley on LinkedIn that had this quote: “Many people do not believe this is true. If there isn’t a fire to put out, then you are not doing a good job.” He included a repost from Shaik Ashraf with that quote and an image that explains better what things a DBA is doing because they aren’t always busy.

    I would say that by busy we think of a DBA as rushed and always trying to fix something that isn’t working well. I’ve certainly walked into operational positions where this was the case. Things weren’t working smoothly or breaking regularly. My phone was always ringing, as I moved from crisis to crisis. For some systems, rebooting them regularly was the fix, not because I didn’t want to determine a root cause and fix them, but because I had too many other priorities. A reboot at least recompiled plans, cleared caches, and got the system working for a few days.

    In those environments, it often took me about 6 months to make changes, implement some standards, find root causes and fix them, and change the way others worked. My approach was to find a problem, consider a solution, and present it to others in a rational way with evidence. I could almost always get approval to start making changes. Or I could convince a manager/director to get others to make changes to stabilize the environment.

    Almost always.

    Not always. And I’ve had a few jobs where things were broken, but everyone else wanted to keep their existing process and keep adding new features/apps/database/etc. and let the DBAs deal with the instability. After all, if I’m working for a salary, does my boss care how much I work? If he/she doesn’t, then I have learned I need to find a new job.

    After 6 or so months, I often find that I’ve reached an improvement limit of some sort. There isn’t a lot I can continue to change and fix, usually because of dependencies and a lack of desire by someone else to change. New work can often be built better, but I’ve often found that I have to live with anything else I haven’t been able to change. Even something as simple as adjusting a query can be a problem when the app developers don’t have an incentive to help.

    Have you reached an improvement limit in your job? Or maybe you have reached a limit to what you are willing to improve, given the environment in which you work.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.