Voice of the DBA

Author: way0utwest

  • Help Your Manager

    Most of us have some sort of review with a manager on a regular basis. It might be once a year, once a quarter, or even monthly. Some of us like these, and some don’t (me), but the review is often a way to assist your manager in evaluating how you are performing in your job. This is quite common, and I’ve gotten used to this, though I never really like the process.

    I do know reviews are important. This is a time when you have an opportunity to shape your career. A good impression here can help you with a raise, a promotion, even the choice of a project or work you want to do in the future. I learned early on in my career that these reviews were important.

    I also learned that my manager often wasn’t up to date on what I’d done across the last time period. I used to have annual reviews, but even with quarterly reviews, managers have their own career (and review) to worry about, other employees to worry about, and they can lose track of your accomplishments.

    I saw a link in the Brent Ozar newsletter listing things that your manager might not know. Not everything on the list would be things that I cover in a review, but these are things to think about as you look to tailor your job to suit you. If you want something fixed or are having issues, make sure you explicitly call these out to your manager. Not imply something is bothering you, but directly state what you want or what is wrong.

    Read the list, but for me, the important things are to track the extra things I’ve done, the things that impact the company, or that help other people. If I save the company money, or better, increase revenue in some way, I want to make a note and bring those notes to my review. If I spend extra time to make someone else’s job easier, bring that up.

    Your manager often doesn’t know the details of what you do across time. Usually, they do track the current tasks, but they often don’t remember at review time what you did 3 or 6 months ago. Often I don’t either.

    That’s why I keep notes about my successes. They help me drive my career forward in the direction I want it to move. It can help you as well but start keeping track of things today, as a way to prep for review time.

    Steve Jones

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

  • Daily Coping 15 Sep 2021

    I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

    Today’s tip is to aim to be good enough, rather than perfect.

    I used to aim for perfection. In the 80s, a lot of writing in business looked at the success of the Japanese manufacturers and their focus on being perfect in many ways. Not that they get there, but they aimed for perfection. This drove me in my career in many ways, helping me to adopt testing, documentation, and re-checking work.

    Over time I realized that this didn’t work well for me in many ways. I could get caught up in making something better than it needed to be and spend more time than necessary. There were also problems and situations where I couldn’t even find perfection, which also drove me crazy.

    I found in my career, that perfection can also vary. What I think as perfect as a developer or sysadmin isn’t what a client might think. I learned to be effective and solve problems. Not just a patch for the moment, but an imperfect patch that could las for some time. A decision that I might have to revisit if things changed, but that was good enough for now.

    I learned to get things done. Today, I continue to do that, especially in speaking. I’m not aiming for the perfect take in presentations. A movie scene may take 10, 20, or more takes to get right. I’ve certainly approached some video recordings like this.

    Now I accept some small mistakes, mis-speaks, stutters, or other imperfections. In the grand scheme of what I’m trying to do, it’s good enough, though certainly not perfect.

    When I coach, I aim to keep improving the athletes. Helping them to grow and become better, but not obsessing over things not being perfect. Instead, we want to be good, and more importantly, be able to adapt and still be successful.

    This isn’t to aim at being half-assed, but more that we find some 侘寂 (wabi sabi).

  • T-SQL Tuesday #142–What is Bicep?

    It’s time for the monthly blog party, and this month the host is Frank Geisler. I was reaching out to various people last year to find hosts, and also (silly-ly) looking for first names to fill out the alphabet on the host page.

    Frank is a fellow MVP and a BI expert. He was gracious enough to agree to host and I thought he picked an interesting topic. This month’s invitation is about scripting to deploy resources. I don’t do a lot of deployments over and over, but I have been interested in one area. It’s actually been a tab in my browser open for a few weeks, so I took this opportunity to dig in.

    Bicep

    I’ve been seeing this term used in various blogs, and in the MVP email list we have. I wasn’t sure what it was, and I kept thinking of this:

    flexing-flex

    That’s not it at all, and I was glad I went through this resource.

    Bicep is a transpiler, meaning it takes one language and translates it into another. In this case, the Bicep language will move code into the ARM JSON templates. JSON is really for machines, not humans, so the idea is to give sysadmins and developers an easy way to describe resources they need to deploy into Azure.

    The language is new, and it’s on Github. This is a DSL (domain specific language), which means it was designed for a specific purpose. With the 0.3 release, the language is built into the Azure CLI and Azure PoSh utilities, so this will do the transpilation for you. There’s also a decompiler to go from an ARM template back to Bicep. It’s also supported by Microsoft, which is always a plus if you need to call for some issue.

    I don’t know a lot about Terraform, but this appears to be another language designed to do the same thing. The FAQ in GH notes this is a revision of ARM, which I guess makes sense. I’m guessing at some point they’ll try to get people to not use ARM (or stop supporting this) and only work with Bicep. Azure supports Terraform, so I’m guessing this is more an attempt to deprecate ARM and the challenges of customers working with JSON.

    A couple things I did like about this. First, there are modules, so you can reuse some code. There is also intellisense, validating and getting you actual resources from Azure that are available. I do worry about deprecation that makes it difficult to deploy a copy of an existing resource when Azure is trying to push you to use some new resource. However, I do think the intellisense and validation in the VS Code extension improve productivity for developers and sysadmins.

    Reuse also helps infrastructure teams assist developers by providing them modules that adhere to good or best practices.

    The language looks like a mix of Python and YAML. Not too hard to understand, and with help, this should be easy to use to create a resource.

    2021-09-14 10_23_36-Bicep language for deploying Azure resources - Azure Resource Manager _ Microsof

    I’m pressed for time today, so I’m not going to experiment or set up an environment, but I need to add this to a list of things to do.

    Why call it Bicep?  No idea. I can’t find an answer, but I did someone say these are “ARMless deployments”. Not sure that fits with Bicep, but I like the logo.

    2021-09-14 10_22_05-Bicep meet Azure Pipelines _ I CAN MAKE THIS WORK

  • Daily Coping 14 Sep 2021

    I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

    Today’s tip is to give yourself permission to say no.

    This is one of the skills I’ve developed in my career. In fact, at my 10 year anniversary with Redgate, our CEO pointed this out. I tend to say “no” unless I’m 100% sure I can deliver. In general, this is how I work.

    I forgot this recently, and agreed to something I wasn’t sure I could fit in. I had to back out, which I hate doing. A good lesson, and this tip was a good reminder for me.

    This doesn’t mean I just always say no to things. Instead, I try to gauge how confident I am, realistically thinking about my schedule and workload and home life. Then if there’s no reason I can think of that will cause issues, I’ll agree. If I have doubt, I say no, but offer to revisit or see if I can move things around.

    I do try to work with and accommodate others, but I’m happy to say no if I can’t, rather than having to back out, or worse, fail to deliver later.