Voice of the DBA

Tag: career

  • Better Writing

    Like it or not the majority of the ways we communicate in technology is through the typed word. Email, Twitter, Word, these are the methods by which we argue a point or ask a question. Our communication skills form impressions with our clients and coworkers.

    All too often, however, we also set ourselves apart from others with our writing. Not because we excel at it, but because so often we make mistakes that stand out. Many technical people aren’t good at getting their point across because they either don’t focus on their topic, or they make lots of silly writing mistakes. Grammatical mistakes don’t have much to do with your technical ability, but they seem to give you less credibility.

    I ran across this blog from Brian Kelley that talks about setting himself apart because of his writing skills. As one of our authors here at SQLServerCentral, I concur. I rarely need to edit anything Brian sends in. In this piece, he also links to an article from CopyBlogger on silly mistakes.

    Writing is a skill, and it’s one that you can learn to improve. However it takes practice. It’s one of the main reasons I recommend that technical people blog. You will improve your writing skills (if you work at it), and possibly impress someone else who could offer you a job.

    Learn to write better. It doesn’t take a lot of time or effort, and it will pay off for you throughout your career.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.1MB) podcast or subscribe to the feed at iTunes and Mevio . feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Powershell in a Month Day 10 – Formatting

    This is part of my Powershell Challenge, to learn more about PowerShell (PoSh) using the Learn Windows Powershell 3 in a Month of Lunches book by Don Jones.

    Not an exciting chapter for sure. This chapter deals with the formatting of results, or objects, for display (or saving to a file or printing). It’s mundane, and not the most interesting stuff to learn. As an analogy to the SQL world, it’s like learning the difference between

    select *
    and
    select name, id, status
    We typically don’t deal with a lot of formatting in SQL Server. We let SSMS handle things, and we include, or don’t include, results. This chapter shows how to do that, and builds a little on some of the things from previous chapters.
    The Get-Process and Get-Service items are the main examples. The chapter starts with some theory, looking at Get-WMIObject and how the system knows whether to display things in a list or a table, but for the most part we don’t alter those default formats natively, so that wasn’t very interesting.
    However, the format-table and format-wide items are interesting. I could see those being handy when you are trying to cull through information and want to only deal with certain items. I practiced a bunch of the formatting, playing with the results, and practicing expressions. Especially when we get to the point where we want to do math and calculate the results of something. Like normalizing memory or recompiles, or something else.
    The chapter looks at grouping, choosing columns, breaking into separate tables, and in general a light understanding of formatting capabilities. There isn’t much time spent on format-list or format-wide, and not much on out-GridView, do you have to do those on your own. I think out-gridview will be really handy to try and work with a set of data, resort it on the fly, and without re-running commands.
    Overall an easy chapter, light on content, but handy in that it will teach you things that you’ll want to do at some point and won’t want to figure out on the fly. I did OK with most of the lab, but being in a bit of a hurry, I didn’t want to figure out how to get a list of log files and cheated, looking at the answers. I should have dug into help, but help is annoying at times. I’ll have to get over that.

  • We’re not craftsmen and craftswomen

    We’re just not, we’re not craftspeople, at least not most of us. We do what we need to do at work. We get systems working just enough. We get by. That’s a little sad, and one of my goals is to get as many of you as possible to think of yourselves as craftspeople, not technology workers.

    Jerry Rice was the best at his craft, and yet he continued to put in work on The Hill as though he were trying to catch others rather than the other way around. David Marks and Norm Abram are professionals, and while they need to complete projects to earn money, they also recognize that “just getting it done” is not enough. Doing just enough to complete a job is the sign of a amateur, not a craftsman.

    There are constraints in our business. We never have enough time, money, or all too often, specifications, when we are working with technology. We need to be effective and make things work. However that doesn’t mean doing the bare minimum to be functional.

    We should aim to be professionals, and part of being a professional is continuing to improve our skills over time. Professionals continue to learn; amateurs do not. We should consider new ideas and techniques, dig into new technologies, and avoid shortcuts. Most importantly, we should do the job that we would want someone to do for us.

    We do have lives outside of work, and outside of our careers. However it’s not an either/or, but a balance that we should strive for between work and life. We can include regular education, and consistent improvement over time as we complete work. We balance that by remembering to appreciate and enjoy our lives outside of our chosen profession.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.2MB) podcast or subscribe to the feed at iTunes and Mevio . feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Double Checks

    It’s not the discount double check, but I am a fan of processes that are built to check other processes. When I have a process that runs, or data quality that should be checked, or some other system where I can potentially have a failure, I like to write a separate check, as an independent process, that ensures work is done correctly.

    Why? Because things go wrong. Most of us schedule a process, like an ETL job, and we assign failure notification (and potentially success notification). If the process succeeds or fails, we get notified. However, what happens if the process doesn’t run? In our busy lives, we might not notice that the success email is missing. What if the process runs incorrectly? Do we have some other process that looks for data to be correct, or even present?

    A second (or third) check can make all the difference in the world between operations that appear to run smoothly for our clients, and those processes that always seem to fail. Even if the process fails, if you get notified quickly, you can potentially fix it before your clients notice. That makes you look more professional, but it’s also what should happen. You should ensure things run smoothly.

    An independent check is also a good security check. Brian Kelley wrote a piece about people tampering with your processes. Would you be aware if that happened? Most people would not, unless they have some auditing, or independent processes that looks for potential security issues.

    There are all sorts of mechanisms to perform checks for you, such as GPOs, Policy Based Management, and more, but have you enabled or scheduled them? Anywhere you have automated processes, you should consider writing separate checks and scheduling them to be sure your processes are running correctly.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.4MB) podcast or subscribe to the feed at iTunes and Mevio . feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.