Voice of the DBA

Category: Editorial

  • The Work of Work

    I saw a short post on meetings, which made me chuckle. The post said that meetings are work, and sometimes they get in the way of other work. I think that’s a sentiment that many people have, especially when they are pressured to write code or manage systems and their daily calendar gets cluttered with meetings.

    I find meetings to be very hit-and-miss for my job. Some are valuable and helpful, with plenty of others being unnecessary and an impediment to getting things done. It is hard to know when a meeting will be helpful or a waste of time, but often I find status meetings to be not worth the time required to attend. They very often are not worth the amount of attention they require, which has me wishing that I could just update status in a system or email rather than listening to others and presenting my own report.

    That being said, meetings aren’t likely to completely disappear for any of us. Whether manager, developer, administrator, or anything else, it seems that getting together is still a regular part of working in an organization. While I do think the remote meetings result in more targeted meetings, focused on a particular topic, they also seem to be more jarring to me. The context switch is jarring, going from some piece of work to immediately being around other people. I find myself missing the pace of walking to and from a room and chatting with others. It’s a good way to get prepared before and decompress afterward.

    Too many of us, do a poor job of accounting for the impact meetings have on the work we need to get done. Whether we are estimating our own workload or trying to manage others and plan for what they will accomplish in a week, we struggle to consider the work of meetings. Both the time spent in meetings, as well as the time preparing for a meeting. We certainly don’t often consider the need to think about the results and action items from a meeting. That’s not to mention the impact of context-switching on our concentration.

    The idea of bunching meetings into a few days or times during the week might be most helpful for me. I like the flexibility to move my creative work around as much as possible. There are times I can code or write, and when those times occur, I want to spend a lot of time in that state of mind. Interruptions are a killer to productivity. I find myself sometimes blocking off sections of days just to prevent meetings from being scheduled. If possible, I prefer a number of back-to-back meetings on one day and nothing on others.

    Meetings are a part of work, but they also are work. You can love or hate them, but finding ways to cope with the impact of meetings is helpful to becoming a more productive worker. It’s also important to ensure your management recognizes the impact of meetings and tries to minimize that impact on any other deliverables on which you are working.

    Steve Jones

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

  • The Digital World Remaking the Analog One

    I got a taxi at Heathrow in the UK recently to go from one terminal to the other. I know, there are buses and trains, but it was late, I had my wife with a lot of luggage and I was worried the restaurant in the hotel would close before we managed another method of transport. As we were making our way over the driver noted there was a £5 charge to drop off at a terminal. That sounds silly, but I saw a billboard noting this and there is a link that this charge applies to almost all vehicles entering the airport terminal areas.

    You might agree or disagree with the charge, or concern yourself with whether the airport authority or local government can (or should) add this as a little tax to those that drive to terminals. That isn’t my focus today. Instead, I thought this was a somewhat amazing, DevOps experiment of how the digital world is remaking the real, analog one.

    Making this decision in the past would require a lot of infrastructure, some gates, people to man them or automated systems to take payment. In this new world there cameras needed, and software that must be built, but this can also re-use payments systems online and take advantage of computing power to assess this charge. The costs might even be lower as the government might absorb some of the camera cost and maintenance as a part of their security concerns.

    Maybe more importantly, adjusting the charge or eliminating this is a decision and a small software or data change. We can remake the way the world works without much effort at all, similar to how we might remake the digital one when we change code. The world of software is only limited by the imagination of developers. That seems to be bleeding into the physical one.

    I find more and more places where software is changing and affecting the physical world. We saw digital menus replace physical ones during the pandemic. While some places have returned to physical ones, others have used hardware tablets to not only present menus, but take orders and payment. In a recent trip to the UK, many places allow complete self service where a patron enters a table number and someone brings their order without any other interaction. I don’t know I think this is better, but it is changing the way the physical world works.

    It’s not just payments and charges, but there are more and more places where software helps manage traffic flows (people or vehicles) without infrastructure. Just directions that people follow, and perhaps get fined when they don’t. I see live translations of text changing the need for producing signage in multiple languages.

    There are plenty of examples, especially as AI/ML systems can help adjust our interactions in the physical world with less hands-on coding from human developers. Something that becomes more important as we are struggling to find developer talent in the modern world.

    Whether you like this or not, the world is changing. We might not like it, and we might try to convince others to build software we prefer, but we will be interacting with software more in ways that change how we interact with the physical world.

    Steve Jones

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

  • Evolving Yourself

    I ran across an interview with Big Boi, a music musician and producer. It’s an interesting look at someone that has had a lot of success and continues to work, mostly because he enjoys it. I’m sure the compensation matters somewhat, but that doesn’t appear to be his driving force. Whether you like his music, it’s an interesting look at someone who lives by his creativity.

    As I read through the interview, a lot of the themes and quotes could be attributed to software developers. We constantly need to learn more and evolve how we write code if we want to be more successful. We have ideas, and often the code we write today isn’t the way we’d write code to accomplish the same task last year. At least, I hope that we would learn, grow, and write new code.

    Certainly, many of us are compensated for what we know now, and often we can write the same code over and over to handle similar situations. This might be more true for people that work in Operations and manage systems more so than developers, but perhaps not. Even if we write similar code as in the past, we often do it more efficiently or incorporate small enhancements that help us. Perhaps better error handling, perhaps anticipating places where our code might fail or falter. These might be changes we hadn’t considered in the last version of this type of code.

    Not everyone wants to be a star or famous, whether a musician or software developer. Lots of us are happy to do a good job, leaning more heavily on past experience than evolving to tackle new challenges and produce a better end result. There is nothing wrong with having a career that accomplishes what is asked of us and nothing more.

    However, the world presents lots of opportunities if you look. Often those come from exploration, experimentation, and making an effort to grow in some way. Having hobby software projects might be akin to writing music and creating new “beats.” Learning from what others have done, studying their techniques and patterns can help us improve our own learning. The more I try to be creative, the more I understand that copying others is an important way to learn. From there I can start to adjust and alter the final product to be my own.

    Study your craft, improve what you know and learn more. Practice and improve, and you might be surprised where your career can go. Plus, it’s more interesting when you’re engaged. Of course, as noted at the end, learn to take breaks, relax, and enjoy life outside of your work. Finding a balance there is important to ensure you work to live, not the other way around.

    Steve Jones

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

  • Code Supply Chain Security

    There have been a number of attacks in the last few years on source code. In fact, I saw a new one this week for an e-commerce WordPress plugin. This time hackers got access to the distribution server for the company, Fishpig, and altered the plug-ins that their customers download.

    A few years ago this was big news, with the SolarWinds exploit. There was also an attack on PyPy, a popular Python package that many people include in their code.  There have been no shortages of problems in npm packages as well. I’m sure this has happened in other software packages, which is scary. In the days of DevOps where we publish code from a repository, an exploit against your developers might go unnoticed. Then again, maybe not.

    Would any of us notice new code in a file share or a folder on our system? We might just compile a large project without realizing it. At least with DevOps, we have the opportunity to include security scans and code analysis checks, some of which could look for known patterns of exploits. I know some companies use these, and often compromised or vulnerable packages are stopped by the automated pipelines.

    In the US, various security agencies have released a set of recommendations, as has the Open Source Security Foundation. Both of these are designed to help developers secure their supply chain against attacks. This is likely going to be a continuous problem for software vendors in the future as it’s much easier to attack one vendor whose software many people use than each individual company. I shudder to think about what happens if someone manages to get a ransomware package into a vendor’s codebase.

    Ultimately, there will still be problems. Many new projects begin with poor practices precisely because they’re experiments and the authors don’t know if others will find the software valuable.  While we can have good templates and security controls, I’m not hopeful. To me, the best solution for stopping code is to have patterns detectable by security checks in the pipeline. Checks that can be expanded and enhanced as new issues are determined.

    Of course, that means the makers of security software need to ensure their supply chain is protected as well.

    Steve Jones

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