Voice of the DBA

Category: Editorial

  • Tracking, Privacy, and Lots of Data

    Half of all advertising dollars are wasted. We just don’t know which half.

    That’s a common view from people purchasing advertising, and it’s why I expect that this saying is what has led to complaints from Google, Facebook, and other large firms that track people across different sites and apps. They have built frameworks that make it easy to add metrics to other software and derive advertising revenue for a vendor. As a result, many people building mobile apps use some framework from a large vendor.

    Apple has been fighting back a bit. I don’t know Apple is terribly altruistic here, but I do think their changes to implement some privacy controls for users are good. The article linked here talks about some of their recent changes in iOS and the complaints from vendors. There are also some notes about the way this impacts everyone.

    There is an Apple white paper about why Apple is changing, and its story is a bit disturbing, showing how a few common daily actions result in data being tracked. It certainly is something I know happens as I’ll see ads for Redgate products on a volleyball site or ads for the bike in which I was interested on a technical database article. It’s annoying and frustrating. I get the idea of making many advertising impressions to influence me, but it’s also distracting when I’m doing something unrelated. Maybe more annoying is that once I buy something, I’m no longer interested, but I still see the ads.

    I don’t mind a company tracking me on their site and showing me something that is possibly related to what I am doing. I do mind having apps do this across apps, and companies aggregating and selling this data. I know this has happened for years, but the scale of today is more problematic. For me, this truly is an issue that needs to be addressed with more control and respect for the human rather than the organization.

    I loved my iOS devices for years, until they removed the headphone jack. I switched the Android, and I’ve been happy, but now I’m in the same situation as the last few Android phones don’t have headphone jacks. I like the choice I get, but that freedom comes with a price in this space. I’m not sure I see Google, or really most manufacturers using Android, making a good choice here for humans. I’m not sure Apple is a lot better, but this is a little better.

    I’d like to see more platforms open, but with also some accountability and responsibility from vendors that doesn’t just make the customer the product. Instead, let the customer choose what data to allow, and then you can adjust prices accordingly. If someone wants to give up all their information for less cost, fine.

    However, let me also choose privacy if the value is there for me. I’ll happily pay for it in many places.

    Steve Jones

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

  • Useless Hackathons

    I participated in a few coding competitions in high school, where we got together for a day with a team and tried to build software to solve a problem. They were challenging and exciting, but exhausting. Not something I’d want to do often.

    A number of corporations have tried something similar with internal hackathons as a way to find internal innovation and inspire employees. Getting a day, or a few days, to build some software that might change an organization can be exciting, but the events are not without some drawbacks.

    I’ve liked the idea of us doing this at Redgate, with our Down Tools Week, but the CIO of TD Ameritrade finds hackathons useless. The reasons he gives makes sense, and they are problems I’ve seen in various organizations when employees want to build something new, without necessarily understanding the problem or having the resources to complete their work. I mostly agree that unbounded hackathons are problematic, and having some evaluation of ideas is important.

    It’s hard to be innovative constantly in an organization when you have pressures and deadlines to complete work. At the same time, it can be easy for an entire development department to stagnate because writing software to close out tickets someone else has submitted. That’s boring, uninteresting work in many cases, and it can reduce incentives to build great software. The ideas in the TD Ameritrade piece are good, allowing a team to be sure developers aren’t solving a problem that’s been evaluated, or choosing a solution that is impractical. I like the idea of funding ideas and increasing that over time if ideas show potential.

    Ultimately there are often lots of ideas on how to solve a problem with software, but we rarely work in a vacuum. Our solutions have to fit within an existing structure and have a ROI that makes sense to the organization. Whether we sell software or support some other business, we are trying to achieve those goals, not just solve the problem in the most satisfying manner. Too often I think software developers sometimes forget there are goals other than just producing code that completes a task. Usually those goals are furthering the organization in some way beyond the software.

    Steve Jones

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

  • Beer Mode

    David Perell has an essay on the different ways that creative people work. He calls these “beer mode” and “coffee mode”. When you are in coffee mode, you are getting things done. You have a list, and you work towards accomplishing the items on your list. Lots of us spend time in this mode every day, and often our bosses expect us to spend more of the time here. This has also been described as “closed” mode.

    Beer mode is different. This is an open mode, where we are not focused on solving an idea, but rather playing with something. We are thinking widely, investigating, and not necessarily planning on getting something concrete completed.

    For much of my career, I was in coffee mode. I think my ability to take a list and get things done contributed to my success in various positions. I could grind through a set of tasks, even repetitive ones, and show my boss what I’d accomplished each day. Going through a list quickly, even if slightly inefficiently, was often rewarded.

    These days, I spend more time in beer mode. Not actually drinking beer, but rather experimenting, playing, thinking, and trying to find new insights into the database world, into how customers might re-imagine their use of our products, and how computing and technology can inspire the world. Those are the fun times. I still get a fair amount of coffee mode in editing, scheduling, etc., but I get more playtime than I ever expected in the past.

    We need both types of working. Often we do want focus and concentration. This is where we build skills, develop strong habits, and produce something valuable. This is steady growth. However, we also need creative time. This is where we expand our minds, think outside the box, and how we grow in leaps and bounds. At least, we may. We can’t predict when we have a breakthrough or find an “aha” moment, but all of us have them, even when they are not life changing.

    Some organizations are better than others at allowing some “beer mode” time at work. If your boss doesn’t think there is a need for unstructured work, maybe send them the essay above and see what they think. There might be all sorts of reasons why this doesn’t make sense every day, or every week, but I do think that having some experimental time is important for anyone doing creative work. This includes the DBAs and sysadmins trying to get your system to run better without a large budget.

    Steve Jones

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

  • Titles and DevOps Confusion

    Alex Yates has become quite the DevOps consultant in the last few years. I used to work with Alex at Redgate before he left to start his own consulting firm. I hear nothing but good things about his work, and if you are looking for someone to help guide your database development team, he’d be a good choice.

    He wrote a piece on the Octopus Deploy blog about the title of DevOps Engineer and why that doesn’t quite make sense. He essentially notes that this doesn’t really describe what a person does and it might not be a good title. I tend to agree, since DevOps isn’t a thing, per se, but rather a set of guiding principles. While this might include building software, or deploying it, there are titles for those things (build engineer or release engineer). It could include Infrastructure-as-code, but that’s the domain of sysadmins.

    There are any number of titles that have come about in this business, and likely more being created all the time. If you have a new job, often you can finagle your way around some pay structures because after all, if you invented the term, the HR department doesn’t have a pay scale to limit you. I suspect that’s part of the reason someone started calling themselves a DevOps Engineer in the first place and got someone to hire them under that title.

    I suspect titles used to be more descriptive and important in the past, when we had fewer of them and the work that each of us did was more tightly scoped. Throughout my career, I’ve started to see more people doing more types of work all the time. Especially in technology where we usually do the work that needs to be done, often crossing over the duties between job titles when something is broken. Getting a system working often takes precedence over any claims of some task being “my work” or “your work.”

    Titles ought to be somewhat consistent, if for no other reason than to easily allow us to compare the work we do in different organizations and allow us to easily promote ourselves to a new employer. If every organization had different titles, we’d waste a lot of time trying to decide if we wanted a position, as would hiring managers trying to decide if we could do the work. Certainly the we find that a DBA or a Developer moving organizations might have some different tasks, but we have a general idea of what work they should be able to complete.

    I’ve never been too concerned about my titles, though I have worked to become “senior” at different employers. That’s usually a function of proving you can do the work well, across a period of time. Of course, if you get work done effectively and efficiently, the title likely doesn’t matter. Someone, likely many someones, will want to hire you.

    Steve Jones

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