Voice of the DBA

Category: Editorial

  • 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.

  • The Tech Blame Game

    Last year Solarwinds was hacked and blamed an intern for a security lapse. When Equifax was hacked, in testimony to the US Congress, the former CEO blamed a specific, though unnamed, person for not patching a system. British Airways blamed their USD$200+mm IT issue on an engineer that rebooted a system too quickly.

    I don’t know that any large company from my younger days, say before 1990, would have blamed a massive failure on a single person. While any single person can influence more systems in the age of technology, no one should have the power to cause such a massive failure. If they do, I think I’d look towards poor system design, rather than individuals.

    These aren’t the only examples of management trying to scapegoat an IT worker, and I suspect we’ll see more examples in the future. However, I hope that governments and shareholders start to demand better management from management. If you don’t understand how IT works, get auditors or consultants to evaluate things and explain them to you. If you don’t think that your systems are well put together without single points of failure, address that. If you worry about security, make that a priority. Microsoft did after the Slammer worm, and arguably they have a difficult job where most employees want to control their laptops and workstations entirely and run them in their individual manner. Microsoft built better controls into infrastructure and software development, and everyone else should as well. Management needs to own their responsibility for failures.

    We should expect mistakes in security, in design, in coding, and more. We should also be placing guardrails, tests, and limits inside our environments to ensure that we catch most of the issues. Software development and system design have improved dramatically the last decade to help us improve quality and security, but we have to embrace the knowledge that’s been gained, as well as ensure we have circuit breakers to prevent runaway failures. If a sysadmin can alter a Chef script to set the max memory in SQL Server to 1MB, this shouldn’t get deployed to all instances. Moreover, we ought to be testing for all sorts of potential changes that can cause issues.

    To me, this is the area that DevOps, GitOps, anything Ops, automated, or at scale, needs to mature. We need to allow for, expect, and assume mistakes and failures will happen and build in controls to our build and test systems. Once we start to better understand how someone can make simple mistakes, we can attach more checks and balances to ensure that we continue to improve quality, without sacrificing speed, or lowering security.

    Steve Jones

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