I attended Brent Ozar's Building
the Fastest SQL Servers session at Tech Ed last week, and found myself engulfed in a 'perfect storm' of excellent technical and presentational skills coupled with an astute awareness of
the value of promoting one's work. I spend a lot of time at such events talking to developers and DBAs about
the value of blogging and writing articles, and my impression is that some could benefit from a touch less modesty and a little more self-promotion. I sense a reticence in many would-be writers. Is what I have to say important enough? Haven't far more qualified and established commentators, MVPs and so on, already said it? While it's a good idea to pick reasonably fresh and interesting topics, it's more important not to let such fears lead to writer's block. In
the eyes of any future employer, your published writing is an extension of your resume. They will not care that a certain MVP knows how to solve problem x, but they will be very interested to see that you have tackled that same problem, and solved it in your own way, and described
the process in your own voice. In your current job, your writing is one of
the ways you can express to your peers, and to
the organization as a whole,
the value of what you contribute. Many Developers and DBAs seem to rely on
the idea that their work will speak for itself, and that their skill shines out from it. Unfortunately, this isn't always true. Many Development DBAs, for example, will be painfully aware of
the massive effort involved in tuning and adding resilience to rapidly developed applications. However, others in
the organization who are unaware of what's involved in getting an application that is 'done' ready for production may dismiss such efforts as fussiness or conservatism. At
the dark end of
the development cycle, chickens come home to roost, but their droppings tend to land on those trying to clear up
the mess. My advice is this: next time you fix a bug or improve
the resilience or performance of a database or application, make sure that you use team meetings, informal discussions and so on to ensure that people understand what
the problem was and what you had to do to fix it. Use your blog to describe, generally,
the process you adopted,
the resources you used and
the insights that came from your work. Encourage your colleagues to do
the same. By spreading
the art of self-promotion to everyone involved in an IT project, we get a better idea of
the extent of
the work and
the value of
the contribution of all
the team members. As always, we'd love to hear what you think. This very week, Simple-talk launches its new blogging platform. If any of this has moved you to 'throw your hat into
the ring', drop us a mail at
[email protected]. Cheers, Tony.
