Voice of the DBA

Tag: syndicated

  • Powershell Tips–PSEdit

    I got this from watching a session from Jeffrey Snover at TechEd. It was a neat trick, and it’s worked better than what I used to do.

    Editing files

    Suppose I have the ISE open and I want to edit a file. I could easily do this:

    psedit_a

    Click File –> Open, or click the open Folder button, and get a dialog to open a file. I stopped doing that soon after I began playing with PowerShell because I was typing most of the time, and it was easier to do this:

    psedit_b

    Just type notepad and the filename, whether it exists or not, and have notepad open up. However working with notepad isn’t great because you lose intellisense and some of the other nice ISE features.

    However today I saw this. Type psedit and a file (it has to exist).

    psedit  attachdbs.ps1

    And I see the file open above.

    psedit_c

    Very cool.

    Of course, as I mentioned, the file needs to exist. If it doesn’t, then a CTRL+N will get you a new file, which you can save and then easily open from the command line the next time.

  • Quick Tips–SQL Prompt Formatting

    I love SQL Prompt, and think it’s a great productivity tool. Even before I worked at Red Gate, I love the tool and had a copy before Red Gate bought the technology from the original developer. Recently I’ve run into a few people that weren’t aware of some of the ways in which it can help you. This is a quick look at one of the ways I use SQL Prompt.

    Ugly Code

    It’s often that I’ll get code submitted at SQLServerCentral, or it will come in a demo from Red Gate, and it will look something like this:

    prompt_af

    This is actually code from Microsoft in the AdventureWorks 2008 sample database. It’s ugly and hard to read. In fact, I struggle trying to interpret code when I see it like this.

    Reformatting

    One of the things I probably do most often, after SSF, is reformat code so that I can read it. I have a few settings I prefer, but to apply them, I’ll click CTRL+K, then CTRL+Y and my code will get fixed.

    prompt_ag

    If I have invalid SQL, Prompt will throw an error and there will be a squiggle line under the offending sections. If I only want to reformat a portion of code, I can highlight it before hitting the shortcut.

  • Another Shot from The DBA Team photo shoot

    photoshoot

  • T-SQL Tuesday #54–Interviews and Hiring

    TSQL2sDay150x150It’s the May T-SQL Tuesday, and this time it’s a great one. This month the host is Boris Hristov (@BorisHristov) and his topic is one that’s near and dear to me. He’s asking about interviews and hiring, and I have a lot to say on this topic. I could talk about both sides of the table here, and I’ll have to choose one for today, but I’ll give a few more stories over at The Modern Resume.

    This is the monthly blog party in the SQL Server community. The second Tuesday of the month is when you need to publish a post, on GMT time, and then link to the invitation. I’d encourage you to participate.

    I Don’t Know

    I’ve interviewed lots of times in my career. I’m not sure why, because I’ve often gotten great performance reviews, and I think I’ve been well liked at my jobs. Perhaps it’s my own restlessness, but it seems that I’ve often found myself in some situations where I needed to move on for some reason. Quite a few of the times it wasn’t my fauly, but However I’m picky, and so I’ve usually interviewed with lots of companies before deciding to take a job.

    A few years back I was unhappy with my current employer (they’d been acquired) and set up 5 or 6 interviews across a couple months. I often get responses from resumes I submit, and usually secure an interview after a phone screen. A lot of my writing at The Modern Resume is based on my success in getting interviews and job offers.

    The interview I got was at Raytheon Polar Services, the company that manages the infrastructure for the South Pole research station at McMurdo. A developer friend I’d worked with at a previous job had spent a couple years there, including a summer at the South Pole and he helped me get the interview.

    oval-conference-table-wood-southwest-airlines-2

    I walked into a room like the one above. My friend and his boss shook hands with me and we sat down. About 9 or 10 others filed in and took seats around the table. They introduced people and said they would go around the table, allowing the various developers to ask questions.

    The first person to my left looked at me and asked me, “what is ACID?”

    I started to answer. “It’s Atomic, Consistent, …”

    I couldn’t remember. I was sitting there, this great opportunity being offered to me, a friend’s recommendation, and I was stuck on the first question of the afternoon. With a room full of developers watching me.

    “I don’t know what the rest of the acronym stands for, “ I said (if you don’t, look it up), and then I proceeded to explain that the idea of ACID in databases has to do with transactions and ensuring data integrity and consistency. I also explained that I could google the exact terms, and would after the interview.

    I didn’t know, and I admitted it. I try to be honest in interviews, hoping that I can get the company to be honest with me. It’s a joint interview, and I interview the company as much as they interview me.

    However I also know that I don’t know everything. I’ve had multiple questions over the years where I didn’t know the answer, and I just admit I don’t know, explain how I might solve the issue. Someone asked me about a complex networking issue one time and I didn’t know the answer. I admitted it, but also told them I had a friend that was a CCIE and he’d be who I’d ask about networking issues I didn’t understand.

    When you don’t know, admit it. However don’t stop there. Explain what you’d do. Show how you can learn, or solve the problem. Would you ask other developers on the team? You can do this, but not too often. Would you research? How long do you work on it before you ask for help? Do you admit when you’re out of your depth?

    Often I’ve found that showing you can admit faults, can learn, and have plans to drive yourself forward help. Of course, you can’t be woefully under qualified. If I interviewed as an MDX developer, I could talk for days on how I’d learn and the people I could ask for help, but outside of an entry level position, I wouldn’t be qualified to work in that area. Hopefully, however, I’d have made that clear in a phone interview.

    Admitting you don’t know is OK. Just don’t stop there.