Voice of the DBA

Category: Editorial

  • Location Data Is Not Anonymous

    We are truly in the era of big brother and 1984, where any of us can be tracked if we use a mobile device. That’s a scary thought and one that many people might not like. There are plenty of people in management that want to increase revenue or profits from the use of data, even if we might think their decisions are unethical or immoral. When there’s money to be made, often they ignore other issues.

    There was a post from Bruce Schneier earlier this summer that noted various public data, some sold by brokers, was used to track location and usage of a device by de-anonymizing aggregated data. The post ends with these statements:

    “Location data is not anonymous. It cannot be made anonymous. I hope stories like these will teach people that.”

    That’s a somewhat scary thought. While I like knowing where my loved ones are, I’m not sure I want any random person to be able to track me with public information. Unfortunately, that is unlikely to be the case in the future. Lots of the data we have rarely worried about being public is much easier to access when records become available digitally to anyone. They ability to work with large amounts of data allows anyone with a connection to gather information that might be used in ways we never imagined.

    For me, public records of property at the most annoying, as I constantly get unsolicited real estate offers to buy houses. For others, there could be concerns about safety, stalking, or other nefarious purposes. Swatting and other forms of harassment are far too common in the modern world.

    While many might see the GDPR, and similar laws, as too restrictive for businesses and government, I think privacy is more important than ever. We ought to have more strict regulation on the use of data about humans, and force companies to obtain consent, allow it to be revoked, and be forced to properly manage and secure our data.

    This doesn’t just apply to location data, but any data about humans. I hope the future becomes a place where we globally consider digital privacy a human right.

    Steve Jones

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

  • What Do You Want to Know Before Negotiating Salary?

    Many of us are employed, and while we might have a salary review each year, we often don’t get to negotiate much about the amount. We might periodically ask for a raise of some sort, but what should we ask for? Most of us have accepted employment at some point, responding to the offer of a job. Do we know what a fair salary is for our position, in our location, with our experience?

    Human Resources and Personnel departments use surveys and information to set ranges of pay for different positions. They come to a salary negotiation with some idea of the market, which is a generalization of what an employee is worth. This could be quite different than what you specifically feel you should be paid. However, do you have any rationale for your demands?

    Every year Brent Ozar runs a salary survey. He gets lots of responses and does a better job of this than most other places I’ve seen. Including me. I’ve done this a few times, but I’d rather just let Brent run this and view his data. This year he asks you to look at the list of questions and give feedback.

    I think Brent has a good list of questions, but perhaps there is something you wish you’d have known before you last negotiated salary. Is there something that might help you decide if an offer (or raise) is fair? Perhaps you want to add a checklist of responsibilities (BI, DBA, dev, etc.).

    Maybe you think it would be interesting to know if there is on call work, or even the number of hours your employer expects you to work? Given the pandemic I might ask if the company is allowing remote work or expecting people to come back to an office. Some people have suggested these in the comments, but read Brent’s answers. He’s looking for a indicators or features that affect salary, not necessarily how you feel about the environment. I added one about non-monetary compensation like training, but feel free to comment on other suggestions as well.

    What’s really important here is that you take the survey when it comes out. Even if you don’t like the questions, getting this data compiled for our industry helps us all, so keep an eye out for the survey and fill it out to the best of your ability. Then get the results when they are published and use them to try and evaluate if you’re being compensated fairly.

    Steve Jones

  • Do You Have a Talent Gap?

    I have seen articles over the years that talk about a talent gap in companies, similar to this one. For a long time early in my career, it seemed anyone that went through a boot camp could get a job, and we had lots of unqualified people earning lots of money. I know I’ve run into my share of paper-CNE’s, paper-MCSE’s, and more in my career that took advantage of that talent gap. Over time it seemed that many companies stopped relying on certifications in hiring, but this didn’t seem to help us find more qualified workers. We either were short of staff or still had plenty of people that couldn’t do the work that well.

    During the last year, I have seen lots of articles about companies that are struggling to find workers at all levels, even though the pandemic has broadened the search space. Companies learned to work remotely and many started to hire people in different cities. I know a lot of people that changed jobs in the last year. Many landing a remote position at a company they would rarely if ever, drive to visit. I still hope the pandemic repercussions will include hiring more people in different locations, though that may not be the case for all organizations. Many managers seem to assume they will bring everyone back into an office at some point.

    However, the talent gap is real, and it’s existed for years. There has been a concern for many years from managers about their staff having the proper skills for the future. I hear constantly from customers that they don’t have enough trained people that understand some of the modern tools available. This is especially true for those technologies that are DevOps related. This includes version control, which I think is a basic skill. There are plenty of people that don’t understand the basics of writing code and committing it in Git.

    I do think some talent gap of this is the result of technology changing so fast, with new options and products to learn. Many of us feel we can’t ever keep up. I know I do, though I think that’s both true and not something to worry about. If you don’t use tools at work, you might think there’s no point in learning about them. If you are excited about technology, you can still be intimidated by all the choices out there. Do you look at Jenkins or Azure DevOps? We email scripts around, so is there a point to git? I even feel that way with Redgate products. They update every week or two and I’m always behind in trying to learn about them and decide if I need to worry about a specific feature.

    I think the talent gap is real, but I also think that learning to be comfortable with being a little uncomfortable is important. It’s unlikely you will be an expert with a tool anytime soon, so learn to be productive and effective. Maybe, more importantly, learn to learn. Spend time going through a tutorial or tackling a walk-through and get some comfort with technology. If you do need to learn more, then you can ask for resources.

    The talent gap is real for many of us, and certainly for many organizations. That’s not likely to change, so learning to adapt to the situation is probably best for all of us.

    Steve Jones

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

  • Incident Review

    Something will always go wrong with our software systems. Issues might happen regularly or rarely, but something is going to go wrong at some point and a client will complain. Often the way we handle these situations determines whether our customers continue to do business with us or look for an alternative.

    In my career, I’ve been a part of many incidents, lots of which were service outages for customers. I’ve attended some incidents as a technical person working to diagnose the issue. In other incidents, I’ve been a developer that has to fix code. During many, my role was as a manager trying to ensure information moves smoothly between resources, ensuring people double-checked that our “fix” wouldn’t cause another problem. After a problem, I’ve also had to take part in a post-incident review. Unfortunately, this has happened far less often than it should.

    When I read this description of a post-incident review, it is unlike many of the after-action meetings I’ve attended. In my experience, there is one meeting and someone is being blamed. Senior management is often there, putting pressure on everyone in attendance to “never let this happen again.” I haven’t known anyone that wanted to go through another outage or a post-incident meeting after an incident, but with complex systems, and humans managing them, something is bound to go wrong. We should expect to have incidents in the future.

    What we want is this same type of incident to not get repeated, which comes about if we learn from our mistakes and design better protocols that help us catch mistakes.  Often to ensure a human doesn’t make a simple error. We should accept that mistakes will happen and try to find ways to detect the problem quickly, limit the scope of impact, and provide a way to share this knowledge with other workers. Depending on humans to be more perfect in the future isn’t likely to be successful.

    These days I read post-incident reviews that my company will publish after an outage, I find them fact-based, focusing on what things went wrong without blaming a person. They include analysis not only of the actual issue but the conditions that led to the hardware/software failure or decision that was made. There are learnings about how we might have prevented something with a time machine, while still assuming that humans would make mistakes or a component might fail. There are also suggestions for improvements in hardware, software, training, or monitoring that might assist in quicker recovery in the future.

    Coming out of an incident with a positive mindset is the best way to try and prevent a repeat of the same incident in the future. This requires that we not only avoid blaming someone for an error but that we also take steps to limit the potential for future errors. If the issue is someone clicking the wrong selection in a drop-down or pressing “OK” when they meant to press “Cancel”, there are limited ways to prevent those issues. However, we can adopt the mindset an outage is a team failure and build a habit of double checking each other. That’s much better than blaming one person, giving the job to another human, who might easily make the same mistake.

    Many humans struggle to avoid placing blame on others and just accepting that some mistakes will happen. A DevOps mindset, with blameless reviews instead focuses on how we can do better as a group, rather than how we failed as an individual. This little change helps us build a better team, one that often performs better in the future.

    Steve Jones

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