Author: way0utwest

  • Under the Bus

    I’ve had a good career in database work. I’ve had success, and I’ve had some failures, fortunately the former far outpacing the latter. In my career across many companies, the code I’ve written has tended to work well, or at least well enough. I’ve managed systems and ensured a high uptime, and solved issues quickly. I have left quite a few jobs in technology, some because I was unhappy, some for better opportunities.

    I was asked to leave one job. I disagreed with my boss, thought he was a jerk, and our CTO told me this person was more valuable than I was at that time. The CTO suggested I move on, so I did. That day.

    I’ve been a manager of both development and operations groups at different positions. I learned as a manager that I praised my staff publicly and criticized them privately. That included taking blame for issues, but passing our kudos for success. A leader is responsible for the team, and that includes accepting the failures of individuals below them. That’s what I believe.

    In the last few years, there has been a bit of a trend where managers blame individual contributors. The Equifax ex-CEO blamed a single person for not patching their servers prior to the attack. Solarwinds CEO blamed an intern for an issue with posting a password to GitHub. There are other examples, but in many cases, senior management is blaming someone far below them for a mistake.

    I know technical people sometimes make decisions that are poor, they click the wrong thing, adjust the wrong server, or make some other mistake. However, in many cases, managers know about the work their people are doing. If they don’t, then isn’t that a management failure? While a manager might not know about patches, they know patching is important. It’s a manager’s job to place a priority on patching systems if this is important, and then ensuring someone verifies patches.

    I don’t expect managers to check repos for passwords, but certainly there are tools to help detect his. I certainly get alerts about a few passwords in my test scripts posted to some repos. Again, a manager should ask that controls, checks, verifications, etc. are a part of any processes that need security.

    I know that often the paychecks of senior managers are far above those of technical staff. I know it’s easy to blame someone making $60k a year and not accepting blame as a VP being paid $400k a year. I know that manure rolls downhill, but it’s disturbing that these executives aren’t being held accountable for the mistakes of their staff. It’s up to them to ensure that staff prioritizes what’s important, security, maintenance, whatever.

    As an individual contributor, I find this behavior is a symptom of a poor culture. We’re not a team when upper management throws people under the bus. To me, it’s a sign I need to seek new employment.

    Steve Jones

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

  • The London Redgate Summit Comes on Apr 17

    I’m heading to the UK in a few weeks for the London Redgate Summit. This starts a wild period of travel for me, but I’m excited. This is the second Summit of 4 this year, and it’s a great chance for Redgate customers and prospects to learn about our three pillars of a better database environment:

    • End to End Database DevOps
    • Test Data Management
    • Monitoring

    The schedule is out, with lots of great speakers on a variety of topics. We will have lots of other Redgate engineers and others. I’ve got a few sessions that day:

    • The New Database Landscape
    • Panel: Next-Gen Database DevOps: Introducing Platform Engineering
    • Essential Practices for Seamless Database Deployments
    • Panel: Why the database is increasingly important to the boardroom

    However, there are three tracks running together: New and Future Tech, Deep Dives, and Thought Leadership. Bring a colleague (or two) and attend some different sessions and compare notes during the breaks. We’ve got a lot of info and experts, and this is a great chance to have a team outing. Or maybe a manager/technologist learning day.

    The Redgate Summit is the best chance to interact with the company and learn how we want to partner with you. And that’s what we want to do.

    We’re successful when our customers are successful.

    That’s been an internal theme at the company as we’ve moved to subscription software. We are partners now with all our customers.

    Join me at the the London Redgate Summit for a great time.

  • Off to SQL Saturday Salt Lake City … on Friday

    I’m off on Thursday for Salt Lake City and a SQL Saturday on Friday. SQL Saturday Salt Lake City 2024 is happening, and I’m glad I get to go. I was looking forward to this last year, but it got postponed with venue issues. This year, the timing worked well since I am coaching Sat/Sun/Mon already, so this was an easy trip for me.

    I’ll be presenting my Architecting Zero Downtime Deployments session, looking at splitting up deployments and coordinating with feature flags in your application.

    The schedule has some great sessions. A mix of SQL Server, PostgreSQL, design/modeling, and more.

    If you’re in/near/willing to go to Salt Lake City, come join me Friday, Apr 5. You can register here.

  • CosmosDB APIs Inside SQL Server 2024

    CosmosDB has been a great data platform in the Azure cloud that helps companies deal with disparate types of data. The CosmosDB APIs include those for MongoDB, PostgreSQL, Cassandra, and Gremlin. These wire-level protocols let you work in a way that is compatible with those systems for storing data.

    That’s coming to SQL Server.

    For the last few years the engineers at Microsoft have been working to separate query processing from storage, and they’ve used this to build products like Hyperscale. That work is being added to SQL Server 2024, so that you’ll be able to add a separate storage engine that doesn’t use the same RDBMS/extent/page structure, but instead is optimized to let you store documents, JSON, and other structures. In addition, there will be new query processors that can run queries from your MongoDB, Cassandra, and Gremlin graph clients.

    Like CosmosDB, however, you can’t have relational data and say, MongoDB data in the same database. You’ll need a separate database, and at least initially, you won’t be able to make cross-database queries. However, you will be able to store your relational and NoSQL data inside the same instance. This will make life easier for developers, who will be able to use one server for all their data.

    Of course, this is an April Fools joke and there are no NoSQL enhancements coming to SQL Server. Not for now. I’m not even sure if SQL Server 2024 is a thing.

    Hopefully, you’re dreaming and smiling. Maybe the engineers at Microsoft are as well.

    Steve Jones

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