Voice of the DBA

Tag: blogging

  • Due Diligence

    I often talk with people about building their brands and finding a way to ensure they are a highly desirable employee. One of the ways that I think people can do this is with a technical blog about their career. Having a technical blog allows someone to show off their skills in a particular area. The blog doesn’t have to be ground breaking work or extremely innovative solutions to complex problems. While employers need those people, they also need people that do solid work every day on regular problems.

    An interview isn’t a great way to find good employees. Many of us have had experience with either (or both) sides of the interview table and realize that interviews aren’t necessarily that helpful. If we bothered to track the impressions we make of candidates and compare that to the actual work they accomplish over the first year or two, I suspect we’d find that we have no evidence that were making great decisions. The success of employees seems to be a bit hit and miss.

    A blog, however, provides the employer with a bit more confidence that a person can handle the job they are hired for. A blog takes time, and across months (or years), it can show quite a bit about a person’s knowledge and skills. It allows hiring managers, and co-workers that may interview a person, the ability to perform a bit more due diligence and investigation into someone’s skills than an interview provides. It’s much more of a representative look at a person than what they say or write on a resume.

    I know that it isn’t a perfect solution. People plagiarize posts and copy from Books Online and more, but the Internet helps here. Search a few of their paragraphs and you might catch plagiarizers easily. After all, someone that wants to copy posts to avoid work, probably has a few other tricks in their bag to avoid doing other work for you.

    Think about starting a blog today and giving potential employers a way to learn more about you.

    Podcast: http://traffic.libsyn.com/voiceofthedba/duediligence_57_v1062.mp3

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

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

  • Minor Problems

    When I speak to people about blogging to increase the visibility of their brand, one of the questions I often hear from them is “what do I write about?” My advice is to take the every day occurrences, the things that come up in the course of your job, and write about them. It doesn’t matter if everyone else has written about backing up SQL Server databases, or writing a query to find duplicate rows; it matters if you have written about it. A potential employer often your blog as due diligence on your skills, including the way you communicate information to others through your writing.

    However most of us also encounter these seemingly trivial, minor problems that plague our environments. We find creative solutions to the problems, solutions that others might not think of. They don’t seem to be worth sharing. I hear so many SQL Server professionals belittle their work, thinking that anyone could build the same solution. That might be true, but for every problem you solve, there are probably others working with SQL Server that would benefit from hearing about your work.

    New people come into the SQL Server community all the time. There will be people that connect to SQL Server with Management Studio for the first time and back up a database. This week someone is writing their first T-SQL query and executing it. The trivial, simple solutions that you develop for common problems might just help one of these beginners learn something, and solve a problem their first week as an accidental DBA.

    Write about the common things you do. Share the solutions you develop. Pay it forward, since most of us have gotten help already from someone else in the community doing the same thing.

    Steve Jones